簡介面向STM32嵌入式開發(fā)者的OTA升級參考資源特別適配工業(yè)現(xiàn)場通過RS485總線遠程維護設(shè)備的需求。資源包含自制bootloader與App兩套完整Keil工程演示了從固件分包傳輸、存儲到跳轉(zhuǎn)運行的全鏈路實現(xiàn)。包內(nèi)共277個文件以C/H源碼為核心另含axf、bin、hex等編譯輸出文件以及工程配置文檔壓縮包僅2.86MB目錄結(jié)構(gòu)清晰便于對比Bootloader與App的協(xié)作關(guān)系。已有2534人學(xué)習(xí)適合正在規(guī)劃IAP功能或設(shè)備聯(lián)網(wǎng)升級方案的中高級工程師。讀者可獲得串口/485幀協(xié)議解析、Flash擦寫與跳轉(zhuǎn)、固件地址規(guī)劃等關(guān)鍵代碼并可直接在此工程基礎(chǔ)上進行二次開發(fā)。1. 為什么要用串口/485做OTA升級先把場景想清楚做嵌入式這些年我接過不少設(shè)備已經(jīng)量產(chǎn)鋪出去了固件出了Bug要現(xiàn)場改的活兒。早期最痛苦的方式是派個人拎著仿真器跑現(xiàn)場拆殼、接線、燒錄、合殼運氣好半小時運氣不好當(dāng)天都搞不定。后來慢慢把OTA升級通道做進產(chǎn)品里才發(fā)現(xiàn)這個決策能省下大量人力成本也讓我意識到一個問題很多團隊在規(guī)劃OTA方案時一上來就奔著Wi-Fi、4G、以太網(wǎng)這些高級通道去反而忽略了串口/485這種最基礎(chǔ)、最可靠、成本最低的升級方式。1.1 串口/485 OTA的典型應(yīng)用場景先說清楚什么叫串口/485 OTA。在STM32F4這類MCU上OTA一般指IAPIn-Application Programming也就是程序運行過程中通過某種通信接口把新的固件數(shù)據(jù)接收下來寫入Flash然后跳轉(zhuǎn)到新程序執(zhí)行。串口UART是最常用的通道485本質(zhì)上是串口加了一顆收發(fā)器芯片如SP3485、MAX485物理層變成差分信號傳輸距離更遠、抗干擾更強但協(xié)議棧層面的處理邏輯和串口基本一致。哪些場景適合用串口/485 OTA我歸納下來大概是這四類工業(yè)現(xiàn)場設(shè)備比如伺服驅(qū)動器、PLC擴展模塊、儀器儀表很多設(shè)備本身就只有RS485接口沒有網(wǎng)絡(luò)條件有上位機/觸摸屏的產(chǎn)線設(shè)備產(chǎn)線設(shè)備一般都有上位機通過串口或485在通信升級固件時直接復(fù)用這條鏈路就行批量生產(chǎn)環(huán)節(jié)生產(chǎn)時通過串口燒錄固件比用J-Link一個一個插上去快得多配合自動化治具效率翻倍售后維護場景設(shè)備出問題后客服通過遠程指導(dǎo)現(xiàn)場人員接一根USB轉(zhuǎn)485線幾分鐘就能完成升級不用拆殼。1.2 為什么方式1不選網(wǎng)絡(luò)通道很多初學(xué)者問我為什么STM32F4這么強的芯片不直接用以太網(wǎng)或者CAN做OTA其實不是不行而是復(fù)雜度和可靠性的取舍問題。串口/485 OTA有幾個天然優(yōu)勢協(xié)議簡單不需要TCP/IP協(xié)議棧不需要MAC地址、IP配置MCU端代碼量小調(diào)試容易鏈路可控串口是點對點通信速率低、邏輯簡單出錯容易排查不像網(wǎng)絡(luò)環(huán)境有各種不確定性成本極低很多產(chǎn)品MCU上本來就預(yù)留了串口引腳硬件上零成本改動通用性強一臺電腦加一根USB轉(zhuǎn)串口線或USB轉(zhuǎn)485線就能當(dāng)升級工具不需要專門的燒錄器。所以方式1的核心思路是用最簡單可靠的物理鏈路配合一套嚴(yán)謹(jǐn)?shù)耐ㄐ艆f(xié)議和引導(dǎo)程序?qū)崿F(xiàn)固件的分包傳輸、校驗、寫入和跳轉(zhuǎn)。這篇文章我盡量把整個方案的設(shè)計思路、代碼架構(gòu)、踩坑經(jīng)驗都寫清楚讓你看完之后能直接在自己項目里落地。2. STM32F4的Flash分區(qū)與引導(dǎo)程序設(shè)計IAP的地基OTA能不能穩(wěn)定跑起來一半的功夫在引導(dǎo)程序Bootloader的規(guī)劃設(shè)計上。很多人第一次做IAP上來就寫跳轉(zhuǎn)代碼結(jié)果不是跳不過去就是跳過去了跑飛歸根結(jié)底是對STM32F4的Flash布局和中斷向量表機制理解不到位。2.1 Flash空間規(guī)劃給Bootloader和應(yīng)用各分一塊地STM32F4系列Flash容量從256KB到1MB不等以最常見的STM32F407ZGT6為例Flash一共1MB分為12個扇區(qū)Sector 0~11每個扇區(qū)大小不同——前4個扇區(qū)是16KB第5個扇區(qū)是64KB后面全是128KB。這個扇區(qū)結(jié)構(gòu)在規(guī)劃分區(qū)時必須心里有數(shù)因為擦除操作是按扇區(qū)來的。典型的雙區(qū)規(guī)劃是分區(qū)起始地址大小存放內(nèi)容Bootloader區(qū)0x0800000032KB引導(dǎo)程序、升級邏輯App區(qū)0x08008000剩余空間應(yīng)用程序標(biāo)志位區(qū)Flash末尾幾個字節(jié)升級標(biāo)志、固件信息Bootloader放32KB是夠用的如果你用STM32CubeMX生成工程HAL庫加串口驅(qū)動再加Flash驅(qū)動編譯出來一般也就十幾KB余量充足。App起始地址選0x08008000對應(yīng)Sector 2——因為Sector 0和1各16KB加起來正好32KB這樣App區(qū)從Sector 2開始后面都是連續(xù)的128KB大扇區(qū)讀寫在邏輯上也簡單。2.2 引導(dǎo)程序的完整執(zhí)行流程引導(dǎo)程序的工作分兩種情況冷啟動引導(dǎo)和升級模式。冷啟動時Bootloader檢查有沒有升級請求沒有就跳轉(zhuǎn)App有升級請求就進入升級流程接收固件數(shù)據(jù)并寫入Flash。整個流程圖不需要畫出多么復(fù)雜的時序核心邏輯其實就這幾步系統(tǒng)上電Bootloader初始化時鐘、串口、GPIO檢查升級標(biāo)志正常啟動時清除有升級需求時置位若無升級標(biāo)志校驗App區(qū)首地址是否為有效堆棧地址有效則跳轉(zhuǎn)若有升級標(biāo)志或收到上位機的升級指令進入升級狀態(tài)機開始接收固件升級完成后更新標(biāo)志軟件復(fù)位重啟。這里有一個關(guān)鍵細節(jié)跳轉(zhuǎn)前要正確設(shè)置主棧指針和中斷向量表偏移。App程序在編譯時必須把IROM1的起始地址改成0x08008000同時在SystemInit之后調(diào)用SCB-VTOR APP_ADDR;來重定向中斷向量表。如果忽略這個App里的串口中斷、定時器中斷一觸發(fā)就直接跑飛這是最常見的IAP失敗原因。2.3 寫Flash的幾個注意事項STM32F4的Flash編程有幾個硬性要求寫不對不僅會觸發(fā)HardFault嚴(yán)重時甚至?xí)袯ootloader區(qū)都擦掉必須按字32位寫入HAL庫的HAL_FLASH_Program函數(shù)要求傳入的是uint64_t類型數(shù)據(jù)內(nèi)部實際按雙字寫你不能直接傳一個字節(jié)擦除是整扇區(qū)的哪怕你只想改一個字節(jié)也得先把整個扇區(qū)的內(nèi)容讀出來、擦掉、再寫回去寫Flash時不能執(zhí)行Flash里的代碼如果你的代碼在Flash里跑著然后又去寫Flash會觸發(fā)總線錯誤。解決辦法是把寫Flash的函數(shù)放到RAM里執(zhí)行或者用HAL庫HAL庫內(nèi)部已經(jīng)處理了這個問題底層會暫停CPU中斷并處理指令預(yù)取注意看門狗Flash擦寫耗時較長特別是128KB的大扇區(qū)擦除可能要幾百毫秒到1秒如果你的產(chǎn)品開了獨立看門狗IWDG在升級過程中必須及時喂狗否則升級到一半系統(tǒng)復(fù)位App區(qū)處于半寫狀態(tài)設(shè)備就變磚了。關(guān)于變磚的問題后面第4節(jié)我會專門講保護機制。3. 傳輸協(xié)議怎么設(shè)計穩(wěn)定升級的核心不在Flash而在通信說句實在話Flash寫入代碼寫對了其實沒什么技術(shù)含量真正的難點在通信。串口/485這種物理鏈路沒有TCP的擁塞控制、沒有確認(rèn)重傳機制你要自己設(shè)計一套夠用但不復(fù)雜的協(xié)議才能保證大固件比如100KB的App傳輸過程中不出錯。我現(xiàn)在用的這套協(xié)議是從Modbus RTU和YMODEM協(xié)議的思路里提煉出來的兼顧了簡單性和可靠性。3.1 幀格式與通信流程設(shè)計我用的是幀頭命令長度序號數(shù)據(jù)CRC校驗的固定幀格式每個字段的含義如下字段長度說明幀頭2字節(jié)0xAA 0x55用于幀同步命令1字節(jié)0x01握手 0x02傳數(shù)據(jù) 0x03結(jié)束 0x04取消數(shù)據(jù)長度2字節(jié)大端模式指示數(shù)據(jù)字段的長度幀序號2字節(jié)從0開始遞增用于丟幀檢測數(shù)據(jù)N字節(jié)固件數(shù)據(jù)或其他有效載荷CRC162字節(jié)從命令字段到數(shù)據(jù)字段末尾的CRC校驗每次升級的通信流程是三次握手批量傳輸結(jié)束確認(rèn)。上位機先發(fā)握手請求Bootloader收到后回一個帶固件長度和CRC的信息上位機確認(rèn)無誤后開始按每包256字節(jié)或512字節(jié)分包發(fā)送每發(fā)一包Bootloader寫入Flash后回一個ACK上位機收到ACK再發(fā)下一包。如果收到NACK則重發(fā)當(dāng)前包連續(xù)重發(fā)N次失敗就中止升級。3.2 握手階段先談戀愛再結(jié)婚很多人做IAP會把流程做得很糙上位機直接嘩啦嘩啦發(fā)數(shù)據(jù)MCU一邊收一邊寫。這樣在理想環(huán)境下也許能跑通但實際用起來非常脆弱——你根本不知道當(dāng)前設(shè)備里是什么版本的固件、扇區(qū)狀態(tài)怎么樣、能不能支持升級。我的握手邏輯是這樣的上位機發(fā)0xAA 0x55 0x01 0x00 0x00 0x00 0x00即握手請求Bootloader回復(fù)設(shè)備信息Bootloader版本號、App區(qū)起始地址、App區(qū)總?cè)萘俊⒚堪畲箝L度上位機根據(jù)設(shè)備信息構(gòu)造固件頭發(fā)回固件長度、固件CRC32校驗值Bootloader收到后計算升級時間回復(fù)OK或拒絕雙方進入數(shù)據(jù)階段。這個握手過程看起來增加了不少代碼量但帶來的收益非常大升級前你就知道版本是否匹配、空間是否足夠、鏈路是否正常不用等傳了一半才發(fā)現(xiàn)問題。3.3 CRC校驗和ACK/NACK機制我之前偷懶用過求和校驗后來發(fā)現(xiàn)實際傳輸中串口偶爾會出現(xiàn)連續(xù)多位翻轉(zhuǎn)的情況求和校驗根本查不出來固件寫進去之后設(shè)備運行到某個角落就莫名死機。后來換成CRC16-CCITT之后再也沒出過校驗漏檢的問題。數(shù)據(jù)傳輸階段MCU每收到一包數(shù)據(jù)先檢查幀格式、幀序號、長度然后做CRC16校驗。校驗通過就把數(shù)據(jù)寫入Flash置位寫入完成標(biāo)志回ACK校驗失敗或者序號不對就回NACK上位機收到NACK后重發(fā)當(dāng)前包。上位機端還需要一個超時機制——發(fā)出數(shù)據(jù)包后500ms內(nèi)沒收到任何回復(fù)自動重發(fā)連續(xù)3次超時則報錯提示用戶檢查物理連接。這里有個容易被忽略的點MCU寫Flash是耗時的特別是碰到扇區(qū)邊界需要先擦除。如果你每收一包都立刻回ACK可能會因為Flash編程時間過長導(dǎo)致上位機超時誤判。解決辦法是MCU先回ACK再寫Flash或者上位機把超時時間放寬到1秒以上。我用的是先回ACK再寫Flash因為串口波特率一般115200發(fā)512字節(jié)大概也就45ms這個時間內(nèi)回ACK完全來得及。3.4 波特率的選擇不是越快越好很多人一上來就想用921600甚至2Mbps的波特率覺得這樣傳得快。但我要潑一盆冷水OTA升級場景中可靠性永遠優(yōu)于速度。原因有幾個CH340這種常見的USB轉(zhuǎn)串口芯片高波特率下丟包率會明顯上升特別是USB的總線調(diào)度有延遲485鏈路在長距離下波特率越高信號衰減和反射越嚴(yán)重誤碼率急劇上升MCU端如果用中斷接收高波特率下中斷頻率過高會擠壓主循環(huán)時間Flash擦寫時如果被中斷打斷時序就可能出問題。我實測下來115200到256000是比較舒服的范圍。一個256KB的App115200波特率下大概傳250秒其實完全可以接受——畢竟升級不是頻繁操作穩(wěn)定把固件寫進去才是硬道理。4. 485通信模式下要注意的硬件細節(jié)自動收發(fā)電路與方向切換如果你的設(shè)備走的是RS485總線那么軟件層面的協(xié)議設(shè)計基本不變但硬件和驅(qū)動層面有幾個隱藏關(guān)卡處理不好就是升級到一半總線沖突、數(shù)據(jù)亂碼。4.1 收發(fā)切換的三種方案RS485是半雙工通信發(fā)送和接收共用一對差分線所以必須通過DE/RE引腳控制收發(fā)器的方向。實際項目中常見三種做法MCU引腳控制方向發(fā)送前拉高DE延時等數(shù)據(jù)發(fā)完再拉低回接收態(tài)。控制簡單但時序要算準(zhǔn)串口發(fā)送完成中斷或者TC標(biāo)志位要用對自動收發(fā)電路利用三極管或比較器根據(jù)TXD信號自動切換方向硬件自動處理軟件不用操心專用自動收發(fā)芯片比如MAX13487這類芯片內(nèi)置了方向控制邏輯價格略高但最省心。我做量產(chǎn)產(chǎn)品時首選自動收發(fā)電路原因很簡單軟件里少一個切換方向-延時-切換回來的狀態(tài)機升級邏輯更干凈也不容易因為發(fā)送完成標(biāo)志判斷失誤導(dǎo)致尾巴沒發(fā)完就切回接收態(tài)。自動收發(fā)電路的典型做法是在RO和DI信號線上加三極管檢測TXD的起始位硬件層面實現(xiàn)對DE的控制具體的搭建電路網(wǎng)上有大量參考可以查。4.2 自動收發(fā)電路的一個致命坑發(fā)送尾巴被截斷這里必須分享一個我踩過的坑。自動收發(fā)電路有個通病當(dāng)TXD變成空閑高電平后DE延時一小段時間才會拉低如果這個延時不夠長數(shù)據(jù)幀的最后幾個bit還沒完全發(fā)出去方向就切回接收了導(dǎo)致對端收到的是殘缺幀。表現(xiàn)癥狀是偶爾第一包握手成功后面數(shù)據(jù)包全部CRC錯誤或者發(fā)一條指令對端收到的是莫名其妙的亂碼。排查思路是拿示波器看A/B差分波形和DE引腳波形對比數(shù)據(jù)幀結(jié)束時的時序。解決辦法是硬件調(diào)整RC時間常數(shù)或者接收端在協(xié)議層加容錯——幀尾加一個字節(jié)的延時確認(rèn)又或者軟件里在發(fā)送最后一字節(jié)后主動延時1-2個字節(jié)的發(fā)送時間再切換方向。如果你用的是MCU引腳控制的方案記住一個原則不要用發(fā)送寄存器為空作為發(fā)完的標(biāo)志要用USART的TC發(fā)送完成標(biāo)志因為TC標(biāo)志才表示數(shù)據(jù)已經(jīng)全部移出移位寄存器真正送到了線上。4.3 485總線的終端匹配與接地做485通信如果速率和距離上去了終端匹配電阻不是可選項。我們實際測試過100米以上距離、115200波特率不加120歐終端電阻時如果總線上出現(xiàn)阻抗不匹配信號會在末端反射產(chǎn)生振鈴直接導(dǎo)致某一包數(shù)據(jù)的CRC連續(xù)出錯。另一個容易被忽略的問題是地線RS485是差分信號理論上不需要共地也能通信但如果兩端設(shè)備的地電位差太大比如超過7V接收端芯片可能直接燒毀。所以長距離485通信建議用帶隔離的收發(fā)器方案最常用的是在MCU側(cè)加一顆隔離電源和數(shù)字隔離器比如ADI的ADM2483、TI的ISO3082。如果只是短距離實驗USB轉(zhuǎn)485線頭和設(shè)備之間保持共地也能湊合。5. 上位機與MCU聯(lián)調(diào)Keil配置、串口助手和常見坑到這里Bootloader代碼寫好了、協(xié)議設(shè)計完了、硬件也檢查過了接下來就是最考驗?zāi)托牡穆?lián)調(diào)環(huán)節(jié)。這一節(jié)我把實際操作中最關(guān)鍵的幾個配置和最容易遇到的問題挨個說一遍。5.1 Keil工程里必須改的三個地方編譯App程序時如果你用的Keil MDK以下三個配置不修改跳轉(zhuǎn)后必出問題IROM1起始地址在Target選項卡里把IROM1的起始地址從0x08000000改成0x08008000大小改成剩余Flash容量。如果不改生成的hex文件下載時必須燒寫到Bootloader之前但運行在App里時中斷向量表偏移與編譯地址不一致函數(shù)跳轉(zhuǎn)和中斷全亂。中斷向量表偏移App工程里在SystemInit之后或者main函數(shù)最開頭添加SCB-VTOR 0x08008000;有的HAL庫版本會自動從VECT_TAB_OFFSET宏讀取偏移量把這個宏改成0x8000也行看具體工程模板。生成可燒寫的bin文件Keil里配置User選項卡添加一條After Build命令調(diào)用fromelf.exe把axf轉(zhuǎn)成binfromelf --bin --output.\Build\app.bin .\Build\app.axf上位機傳輸固件時一般用bin文件而不是hex因為bin是純二進制數(shù)據(jù)沒有地址信息更便于按包發(fā)送。還有個細節(jié)Debug調(diào)試時注意燒錄范圍。如果你用J-Link調(diào)試App下載算法默認(rèn)會從0x08000000開始擦寫如果不修改Flash Download的起始地址一調(diào)試就把Bootloader沖掉了。建議聯(lián)調(diào)階段先把Bootloader燒好然后App用串口升級方式燒寫順便驗證IAP鏈路。5.2 CH340、FTDI驅(qū)動的坑串口打不開和打開就卡死調(diào)試串口/485升級上位機這邊用的USB轉(zhuǎn)串口線質(zhì)量參差不齊驅(qū)動也各有脾氣。CH340是最常見的國產(chǎn)方案驅(qū)動裝好之后在設(shè)備管理器里識別為COM口兼容性整體不錯但有幾個容易踩的坑買到劣質(zhì)CH340模塊有些小廠模塊用了假的CH340芯片驅(qū)動裝上后識別成未知設(shè)備或者收發(fā)不穩(wěn)定。建議買正規(guī)品牌或者直接選FTDI方案的線FTDI的驅(qū)動穩(wěn)定性和兼容性確實好一點但價格貴了不少串口被占用串口助手打開串口后如果你再用別的軟件嘗試打開同一個COM口要么打不開要么剛打開就卡死。調(diào)試時只開一個串口助手別程序里和工具同時去搶占收發(fā)顯示亂碼確認(rèn)波特率、數(shù)據(jù)位、停止位、校驗位兩邊完全一致。串口調(diào)試助手里常見的是8數(shù)據(jù)位、1停止位、無校驗如果你代碼里配置成了2停止位上位機忘記改大概率就是亂碼串口自動關(guān)閉問題Windows下拔插USB轉(zhuǎn)串口線后COM口號可能變化串口助手軟件如果緩存了舊的句柄重新打開就會報串口打開失敗。把線拔了重插刷新串口號再連。5.3 串口助手的換行陷阱調(diào)試協(xié)議幀時我發(fā)現(xiàn)新手特別喜歡在串口助手里勾選發(fā)送新行選項默認(rèn)發(fā)完數(shù)據(jù)會自動追加\r\n0x0D 0x0A。這在調(diào)試普通AT指令時沒什么問題但在OTA協(xié)議里就是災(zāi)難——MCU端把換行符當(dāng)成幀數(shù)據(jù)長度字段對不上CRC算不對整個鏈路就沒法正常通信。我的做法是代碼里實現(xiàn)一個狀態(tài)機解析器按字節(jié)接收每收到一字節(jié)就判斷當(dāng)前狀態(tài)是找?guī)^、收長度、還是收數(shù)據(jù)。這樣即使上位機不小心多發(fā)了幾字節(jié)MCU也能通過幀頭重新同步。你自己做上位機時也盡量把幀的收發(fā)邏輯做成純數(shù)據(jù)模式不疊加任何文本轉(zhuǎn)義。5.4 升級中途失敗且無法恢復(fù)這是IAP場景中最焦慮的一個問題升級到一半串口意外斷開或者電腦斷電Flash里寫了一半的App區(qū)變成了半殘狀態(tài)設(shè)備重啟后Bootloader發(fā)現(xiàn)App區(qū)的升級標(biāo)志還在于是又進入升級模式繼續(xù)等數(shù)據(jù)但上位機已經(jīng)退出了——這時如果沒有超時退出機制設(shè)備就卡在升級模式里看起來像變磚。解決辦法是雙保險升級標(biāo)志置位后加上超時Bootloader進入升級模式后如果X秒內(nèi)沒收到任何有效數(shù)據(jù)包自動清零升級標(biāo)志并跳轉(zhuǎn)當(dāng)前已有的App簽名驗證機制進階版在App區(qū)末尾寫入固定魔數(shù)固件哈希值Bootloader每次啟動時先校驗App區(qū)是否完整。不完整就強制進入升級模式等待完整才跳轉(zhuǎn)。這樣即使升級中斷設(shè)備也只是停在升級模式等待新固件不會徹底鎖死。我目前用的是魔數(shù)校驗超時退出量產(chǎn)幾年了一直穩(wěn)定。如果追求更嚴(yán)苛的可靠性可以在App的編譯腳本里自動生成CRC32表追加到固件末尾Bootloader啟動時全片校驗大概能覆蓋100%的損壞場景。6. 485雙向通信下主從機同時收發(fā)導(dǎo)致的總線沖突排查前面聊的都是串口點對點場景。如果你的設(shè)備走的是RS485主從總線比如Modbus RTU網(wǎng)絡(luò)里設(shè)備既要用485做主從通信又希望通過同一根總線OTA升級問題就復(fù)雜得多了——最典型的現(xiàn)象是熱詞里提到的那個485 Modbus主機從機分別測試都正常主機連接從機就不正常。6.1 問題本質(zhì)收發(fā)時序的閉環(huán)復(fù)制我分析這類問題的經(jīng)驗是先拋開OTA升級這個高級需求把485通信當(dāng)成一個純粹的總線時序問題來排查。分開測、主機單獨發(fā)、從機單獨回各自都正常一接在一起就不行大概率是這兩個問題之一收發(fā)器方向切換時序不對主機發(fā)完請求后如果方向控制還沒完全切回接收態(tài)就開始等從機應(yīng)答會錯過從機回復(fù)的第一個字節(jié)從機發(fā)的數(shù)據(jù)只有半個字節(jié)能被收到看起來就是從機沒反應(yīng)總線上有第三個收發(fā)器在搗亂比如調(diào)試時你電腦上掛了一個USB轉(zhuǎn)485它雖然沒發(fā)包但它的接收器一直掛在總線上如果它的輸入阻抗不夠高會拉低總線電平導(dǎo)致正常通信的邊沿幅度不足。排查鏈路我建議按這個順序走先用示波器抓A/B兩端波形看數(shù)據(jù)發(fā)送時差分電平是否清晰到達再抓DE/RE引腳波形確認(rèn)方向切換的臨界點最后斷開所有無關(guān)設(shè)備只留主機和從機逐步加回設(shè)備找出正確時序下不該出現(xiàn)的干擾源。6.2 升級過程中和Modbus主從通信怎么共存如果你的設(shè)備平時運行在Modbus從機模式下要在不干擾正常主從輪詢的前提下插入OTA升級必須設(shè)計一個升級模式入口。我常用的方案是定義一個特殊功能碼或者復(fù)用一個保持寄存器作為升級請求標(biāo)志。主機想升級某臺從機時先寫這個寄存器從機置位升級標(biāo)志并回包然后從機不再響應(yīng)普通Modbus請求進入升級模式。升級完成后從機軟復(fù)位重新進入正常主從模式。這樣做的關(guān)鍵是升級期間總線上只有升級交互的雙方其他從機必須進入靜默狀態(tài)。如果你的上位機既要輪詢其他從機又要給目標(biāo)從機傳數(shù)據(jù)就把升級數(shù)據(jù)的幀格式和Modbus的從機地址區(qū)分開比如升級幀里帶目標(biāo)從機地址只有目標(biāo)從機才響應(yīng)該地址的升級命令。總的來說要把OTA升級做成485總線上的一個臨時會話用地址和命令字隔離避免和正常業(yè)務(wù)互相踩踏。6.3 從串口升級到485升級代碼層面到底改了啥從實現(xiàn)角度說串口OTA和485 OTA在MCU端的代碼差異其實很小主要就兩點GPIO配置串口用TXD/RXD兩個引腳直接接USB轉(zhuǎn)串口485要在移植時初始化DE/RE引腳并實現(xiàn)方向切換邏輯發(fā)送函數(shù)要加方向控制普通串口發(fā)送就是往數(shù)據(jù)寄存器寫數(shù)據(jù)485需要先拉高DE發(fā)送完成后再拉低DE。封裝一個RS485_SendBuffer函數(shù)里面先RS485_SetDir(1)發(fā)完再RS485_SetDir(0)其他地方不用動。所以我做方案時一般把通信底層抽象成UART_SendBytes/UART_ReceiveByte485只是在這個接口上多包了一層方向控制。將來產(chǎn)品要改用CAN OTA或者以太網(wǎng)OTA上面的協(xié)議邏輯和Bootloader結(jié)構(gòu)都可以復(fù)用只需要換掉最底層的收發(fā)函數(shù)。這個層次劃分值得一開始就做好不然后面擴展會很痛苦。7. 從一次實際升級事故講起我是怎么定位Flash寫入失敗的最后分享一個實操中比較典型的問題案例是我在給一臺量產(chǎn)的STM32F407設(shè)備做485 OTA時遇到的。現(xiàn)象是傳輸過程中前幾十包都很正常到某一包開始MCU回NACK上位機重發(fā)N次仍然失敗升級終止。把設(shè)備斷電重啟之后能正常進入App但App版本次數(shù)不對說明前面寫進去的數(shù)據(jù)有一部分沒生效。7.1 排查過程從懷疑鏈路到鎖定Flash一開始我懷疑是485鏈路的問題畢竟物理層受干擾的可能性最大。我先用示波器抓了A/B差分信號波形干凈邊沿清晰排除了信號完整性問題。又換了新的USB轉(zhuǎn)485線問題依舊。后來我打印了MCU收到每一包數(shù)據(jù)的序號和CRC結(jié)果發(fā)現(xiàn)一個規(guī)律失敗的位置總是出現(xiàn)在一個固定區(qū)域——64KB扇區(qū)的邊界附近。這就很能說明問題了。STM32F407的Flash扇區(qū)前四個16KB接著是64KB再往后是128KB。如果我的App從0x08008000開始Bootloader占32KB那么App區(qū)前兩個扇區(qū)是16KB16KB接著就是64KB扇區(qū)。數(shù)據(jù)寫到0x0801000064KB扇區(qū)的邊界時Flash控制器要做扇區(qū)切換如果代碼在扇區(qū)切換時沒有正確管理擦除時機很可能出現(xiàn)寫入地址錯位的情況。7.2 根因跨扇區(qū)邊界時的擦除時序我的代碼邏輯是先查當(dāng)前地址所在的扇區(qū)如果跟上一個寫入的扇區(qū)不同就擦除新扇區(qū)再寫。問題在于擦除和寫入沒有做原子操作——某次升級中擦除完成了但是寫入還沒開始此時上位機的超時重發(fā)機制認(rèn)為上一包失敗重發(fā)了相同序號但MCU側(cè)的寫入地址已經(jīng)推進到新扇區(qū)導(dǎo)致接收方狀態(tài)機和發(fā)送方錯位每包序號對不上CRC也全亂。弄清根因后我改了兩處一是讓Bootloader在擦除扇區(qū)時不響應(yīng)任何新數(shù)據(jù)包擦完再繼續(xù)接收二是上位機在MCU回復(fù)擦除中這個狀態(tài)時不重發(fā)當(dāng)前包而是等待固定延時再發(fā)下一包。修改后連續(xù)測試了十幾次跨扇區(qū)邊界再也沒有失敗過。7.3 經(jīng)驗沉淀給正在做OTA的你幾條建議做完這個項目我把自己做OTA的流程沉淀成了一份清單每次新項目都按這個走很少再出大問題先在串口模式下把整個升級鏈路跑通再切換485。485比串口多一個方向控制的變量把變量留到最后加排查起來簡單很多在Bootloader里加詳細日志輸出收到的包序號、CRC結(jié)果、Flash擦寫狀態(tài)通過串口實時打印。調(diào)試完再關(guān)掉日志代碼但要保留一個宏開關(guān)方便現(xiàn)場遠程定位問題升級前把App的版本號放到一個固定地址比如Flash最后一個扇區(qū)的前四個字節(jié)每次升級時校驗新舊版本避免誤刷同版本或者降級刷入導(dǎo)致配置不兼容給上位機做升級進度剩余時間顯示用戶等太久會焦慮進度條能極大提升體驗而且能及時發(fā)現(xiàn)鏈路卡死升級過程中嚴(yán)禁斷電這個必須醒目標(biāo)注在說明書里最好在產(chǎn)品上設(shè)計一個升級指示燈讓操作人員一眼看到狀態(tài)。8. 從串口助手到批量燒錄治具這套方案的下一步擴展做完一次OTA方案后你會發(fā)現(xiàn)這套東西就像打通了任督二脈——它不只是升級固件這么簡單還能往上疊很多生產(chǎn)、測試、維護的工具。我的經(jīng)驗是先把基礎(chǔ)鏈路通然后根據(jù)實際需要逐步開發(fā)周邊工具。最常用的擴展方向有三個。第一是批量燒錄治具產(chǎn)線里用一塊F407的板子當(dāng)燒錄器通過數(shù)組存儲bin文件再用485總線并發(fā)地往多個設(shè)備燒錄比人工一個個插J-Link效率高一個量級。第二是遠程協(xié)助升級設(shè)備的485總線如果接了DTU或串口服務(wù)器上位機通過MQTT或TCP下發(fā)升級指令和固件包DTU把它轉(zhuǎn)成串口數(shù)據(jù)就能實現(xiàn)云端觸發(fā)、鏈路復(fù)用的遠程升級。這個方向很多物聯(lián)網(wǎng)網(wǎng)關(guān)方案已經(jīng)在用協(xié)議設(shè)計思路和我前面講的完全一致。第三是日志回傳設(shè)備運行狀態(tài)、錯誤日志通過485總線定時上報方便遠程診斷排查問題不用再跑現(xiàn)場。如果真的想把OTA這套東西做得更扎實我強烈建議你研究一下YMODEM協(xié)議和STM32官方應(yīng)用筆記AN4657里的IAP實現(xiàn)思路。前者對大數(shù)據(jù)傳輸?shù)耐ㄐ偶毠?jié)處理得非常完善后者對Flash編程、跳轉(zhuǎn)穩(wěn)定性方面有不少成熟的參考代碼。看完之后你會發(fā)現(xiàn)自己設(shè)計的協(xié)議在很多細節(jié)上都能再打磨一輪——比如對最后一包不滿長度時的補零規(guī)則斷線重連后的續(xù)傳機制這些邊角情況的處理工程上差之毫厘成品穩(wěn)定性就謬以千里。本文還有配套的精品資源點擊獲取