IAP不是一個新話題但真正要把它做到穩(wěn)定可靠能踩的坑絕不比開發(fā)一個新功能少。很多人第一次接觸STM32在線IAP升級都是從一張Bootloader原理圖、一段跳轉(zhuǎn)代碼開始的結(jié)果燒進(jìn)去要么跑飛要么一進(jìn)中斷就死機(jī)調(diào)了一整天發(fā)現(xiàn)只是向量表偏移沒設(shè)置對。這篇文章我就圍繞STM32在線IAP升級從方案選型、Flash分區(qū)、協(xié)議設(shè)計、代碼實(shí)現(xiàn)到實(shí)測排障把它完整講清楚。適合正在做Bootloader開發(fā)的嵌入式工程師也想給手里的小項目加上遠(yuǎn)程升級能力卻不知道從何下手的開發(fā)者。1. 什么是STM32在線IAP升級它到底在解決什么問題1.1 IAP、ISP、OTA三者不能搞混先講清楚概念。IAP全稱是In-Application Programming意思是應(yīng)用程序在運(yùn)行過程中自己對自己所在的Flash進(jìn)行編程。聽上去有點(diǎn)繞但本質(zhì)上是把固件更新能力做成應(yīng)用的一部分設(shè)備出廠前燒一版Bootloader引導(dǎo)程序之后用戶通過串口、CAN、以太網(wǎng)甚至無線通道把新固件傳給BootloaderBootloader再把固件寫到App區(qū)最后跳轉(zhuǎn)到App運(yùn)行。ISP是In-System Programming利用芯片出廠時固化的系統(tǒng)引導(dǎo)程序通過串口、USB或JTAG/SWD把程序燒到Flash里。ISP不需要自己寫引導(dǎo)程序但它的升級工具和下載器流程依然依賴外部主機(jī)屬于“離線燒寫”。OTA本來是Over-The-Air指的是通過無線網(wǎng)絡(luò)升級固件比如Wi-Fi、藍(lán)牙、4G。把OTA的傳輸通道換成有線串口或CAN本質(zhì)上就是IAP。所以我經(jīng)常跟同事說IAP是一種機(jī)制OTA是它的一種傳輸場景。做IAP核心是把“接收固件→寫Flash→跳轉(zhuǎn)”這套流程打通至于數(shù)據(jù)用什么方式傳過來反而可以后選。為什么非要折騰IAP三個字省成本。設(shè)備裝到現(xiàn)場、封進(jìn)殼子之后還想改程序傳統(tǒng)做法是拆機(jī)、接下載器、重?zé)淮蝺纱芜€行產(chǎn)品量大了誰受得了。IAP讓設(shè)備在網(wǎng)絡(luò)可達(dá)的地方就能自己更新這才是它最大的價值。1.2 Bootloader App雙區(qū)架構(gòu)IAP系統(tǒng)的基本盤IAP系統(tǒng)的軟件架構(gòu)通常分成兩個部分Bootloader和App。Bootloader放在Flash起始地址也就是0x08000000芯片上電后CPU從那里開始執(zhí)行。Bootloader的任務(wù)很簡單初始化基礎(chǔ)外設(shè)串口、CAN、定時器等檢查要不要升級如果要升級就進(jìn)入接收和寫Flash流程如果不需要就跳轉(zhuǎn)到App首地址。App存放在Flash的其他區(qū)域比如0x08008000。App就是你的真正業(yè)務(wù)程序它編譯時要把起始地址改成所在區(qū)域同時在運(yùn)行時把中斷向量表重映射到對應(yīng)位置。這兩個工程在開發(fā)時是獨(dú)立的最終燒錄時Bootloader一次性燒到Flash開頭App可以通過Bootloader升級也可以先用下載器臨時放到App區(qū)。雙區(qū)架構(gòu)有幾個明顯好處第一Bootloader和App互不干擾App崩了只要Bootloader還健康設(shè)備就能恢復(fù)第二升級邏輯集中在Bootloader里App側(cè)只需要配合一點(diǎn)代碼第三同一塊板子可以通過更換App實(shí)現(xiàn)不同的功能硬件完全不用動。我個人的建議是哪怕你現(xiàn)在用不到遠(yuǎn)程升級也盡量在產(chǎn)品開發(fā)初期就把Boot和App的分區(qū)模型搭好。后期再加Bootloader會遇到App需要挪位置、中斷向量表要重設(shè)、鏈接腳本要改一堆東西工作量只會更大。1.3 在線升級該走哪條傳輸通道在線升級的“在線”體現(xiàn)在傳輸通道上。項目里最常見的幾種通道選型我列個表供參考通道典型速率適用場景注意事項串口UART115200bps調(diào)試、現(xiàn)場本地升級實(shí)現(xiàn)最簡單線纜距離短CAN總線500kbps/1Mbps工業(yè)設(shè)備、車載設(shè)備需要CAN收發(fā)器距離遠(yuǎn)抗干擾強(qiáng)以太網(wǎng)10/100Mbps網(wǎng)關(guān)、工控、服務(wù)器類設(shè)備可通過HTTP/TFTP拉取固件包4G/Wi-Fi視模塊而定物聯(lián)網(wǎng)、遠(yuǎn)程運(yùn)維需要模組介入?yún)f(xié)議較復(fù)雜適合OTAUSBFull Speed消費(fèi)類電子、調(diào)試工具需要USB協(xié)議棧常用于DFU做項目選通道時不要只看快慢。串口雖然慢但最穩(wěn)定調(diào)試時打日志也方便CAN在工業(yè)現(xiàn)場比串口可靠得多抗干擾強(qiáng)以太網(wǎng)適合固化在內(nèi)部網(wǎng)絡(luò)的設(shè)備配合TFTP協(xié)議幾乎不用自己設(shè)計傳輸協(xié)議。對大多數(shù)學(xué)習(xí)者和中小項目我建議先用串口跑通整個IAP流程后面再換通道因?yàn)锽ootloader側(cè)的編程邏輯和通道無關(guān)換通道只需要改收發(fā)函數(shù)。2. 升級方案設(shè)計Flash分區(qū)與固件協(xié)議2.1 Flash分區(qū)怎么規(guī)劃才安全Flash分區(qū)是IAP設(shè)計的第一個關(guān)鍵決策。分區(qū)沒做好后面所有代碼都會別扭。以STM32F103ZET6為例它有512KB的Flash起始地址0x08000000結(jié)尾0x0807FFFF。我常用的劃分方式Bootloader區(qū)域0x08000000 ~ 0x08007FFF占32KBApp區(qū)域0x08008000 ~ 0x0807BFFF共480KB參數(shù)區(qū)域0x0807C000 ~ 0x0807FFFF占16KB用于存放升級標(biāo)志、固件版本、CRC校驗(yàn)結(jié)果等Bootloader為什么不能用滿因?yàn)楹罄m(xù)加功能、升級協(xié)議版本都要空間留一點(diǎn)余量總沒壞處。F1系列的Flash頁大小是1KB其他系列可能不同F(xiàn)4有的是2KB一個扇區(qū)所以App起始地址必須按頁對齊否則擦寫Flash時會出現(xiàn)覆蓋Bootloader區(qū)域的嚴(yán)重事故。參數(shù)區(qū)域在IAP系統(tǒng)里很容易被忽略但它的價值很大。升級標(biāo)志、版本號、校驗(yàn)結(jié)果這些數(shù)據(jù)如果放在App里面每次升級App都要改風(fēng)險高單獨(dú)劃一塊參數(shù)區(qū)Bootloader啟動時先讀這里再決定下一步動作整個流程就清晰了。Flash容量小怎么辦比如只有64KB的芯片Bootloader占16KBApp只能占不到48KB這時候就別想著A/B備份了。把參數(shù)區(qū)壓到一頁App區(qū)盡量大回滾方案用“失敗后重新升級”而不是“自動回滾舊版”。容量緊張時的取舍優(yōu)先級是Bootloader穩(wěn)定性 App可用空間 回滾能力。2.2 自定義固件幀結(jié)構(gòu)在線升級的本質(zhì)是數(shù)據(jù)傳輸而數(shù)據(jù)在總線上傳輸必須有協(xié)議。很多項目用現(xiàn)成的Ymodem協(xié)議簡單方便但我想說的是自己定義一套輕量協(xié)議往往更貼合項目需求排查問題時也更直觀。我常用的一套幀結(jié)構(gòu)長這樣幀頭(2B) | 命令字(1B) | 包序號(2B) | 數(shù)據(jù)長度(2B) | 數(shù)據(jù)段(N B) | CRC16(2B) | 幀尾(2B) 0xAA 0x55 | 0x01 | 0x0001 | 0x0100 | 256字節(jié)數(shù)據(jù) | 0x3A2B | 0x0D 0x0A命令字定義了升級流程的交互命令字方向含義0x00主機(jī)→Boot開始升級附帶固件總長度、固件CRC32、版本號0x01主機(jī)→Boot數(shù)據(jù)幀附帶一段固件數(shù)據(jù)和該段序號0x02主機(jī)→Boot升級結(jié)束Boot確認(rèn)整體校驗(yàn)0x03Boot→主機(jī)應(yīng)答幀ACK表示成功NAK表示失敗并附原因0x04主機(jī)→Boot查詢狀態(tài)用于重連場景數(shù)據(jù)長度字段我覺得設(shè)成兩字節(jié)比較穩(wěn)妥一字節(jié)最多255不夠用。數(shù)據(jù)段大小要結(jié)合Flash編程方式定我一般用256字節(jié)原因后面說。CRC16只對命令字、包序號、數(shù)據(jù)長度和數(shù)據(jù)段做計算幀頭和幀尾不參與這樣接收端可以先找?guī)^、再做CRC校驗(yàn)邏輯清晰。這套協(xié)議還有一個細(xì)節(jié)包序號一定不能省略。沒有序號一旦某一包在傳輸中丟失接收端無法通知對端重傳哪一包。串口偶爾丟一個字節(jié)總線通信偶爾丟一包都是正?，F(xiàn)象協(xié)議里必須有序號機(jī)制兜底。2.3 升級主狀態(tài)機(jī)Bootloader的升級流程不建議用一大坨if-else硬堆最好設(shè)計成狀態(tài)機(jī)。我實(shí)際項目里的狀態(tài)枚舉大致是這樣typedef enum { ST_IDLE, // 空閑等待開始幀 ST_START, // 收到開始幀校驗(yàn)固件信息 ST_DATA, // 正在接收數(shù)據(jù)幀 ST_FINISH, // 收到結(jié)束幀整體校驗(yàn) ST_ERROR, // 錯誤狀態(tài)記錄錯誤碼 ST_JUMP // 升級成功跳轉(zhuǎn)App } UpgradeState_t;狀態(tài)轉(zhuǎn)移的核心邏輯IDLE態(tài)收到0x00命令字校驗(yàn)固件總長度是否超過App區(qū)容量通過后進(jìn)入STARTSTART態(tài)擦除App區(qū)全部頁面發(fā)送ACK進(jìn)入DATA態(tài)。注意擦除動作放在這里而不是放在第一包數(shù)據(jù)到來時是為了避免過程中掉電導(dǎo)致部分App區(qū)被覆蓋但Boot又沒收到完整數(shù)據(jù)DATA態(tài)收到0x01按序號寫入FlashCRC或者序號不對就回NAK并請求重傳DATA態(tài)收到0x02Boot把已收到的字節(jié)數(shù)、CRC32和開始幀里聲明的內(nèi)容對比一致則寫入“App有效”標(biāo)志進(jìn)入JUMP不一致進(jìn)入ERRORERROR態(tài)會打印錯誤碼并等待主機(jī)重新發(fā)送開始幀這個狀態(tài)機(jī)看起來簡單但實(shí)際執(zhí)行時對邊界條件的要求很高超時怎么算、重傳多少次、掉電后怎么恢復(fù)都要在設(shè)計時想清楚。我把每個狀態(tài)都加了一個超時計時比如DATA態(tài)超過500ms沒有收到新包就強(qiáng)制回到IDLE態(tài)避免設(shè)備卡死在升級模式里出不來。3. 實(shí)操核心Bootloader與App側(cè)代碼實(shí)現(xiàn)3.1 Bootloader入口判斷要不要升級Bootloader的main函數(shù)邏輯是所有IAP工程的起點(diǎn)代碼風(fēng)格大同小異int main(void) { // 基礎(chǔ)時鐘、串口初始化打開指示燈 SystemClock_Config(); MX_USART2_UART_Init(); // 判斷是否需要進(jìn)入升級模式 if (CheckUpdateFlag() 1) { // 進(jìn)入升級流程 UpgradeProcess(); } else { // 直接跳轉(zhuǎn)App JumpToApp(); } }CheckUpdateFlag的實(shí)現(xiàn)有幾種方式。最原始的是檢測一個GPIO按鍵電平按住按鍵上電就進(jìn)升級更通用的做法是查參數(shù)區(qū)的Magic標(biāo)志字比如某地址存儲了0xA5A5A5A5就進(jìn)升級模式。App在收到“升級指令”時可以先把這個標(biāo)志寫到參數(shù)區(qū)然后調(diào)用軟復(fù)位等Bootloader起來后一查標(biāo)志自然就進(jìn)入升級流程了。這里有個細(xì)節(jié)升級標(biāo)志一旦寫入就要確保在升級成功或失敗的流程里把它清除否則會出現(xiàn)一種情況——用戶明明升級完了Bootloader一上電又進(jìn)升級模式卡在等待主機(jī)連接。我遇到過好幾次最后發(fā)現(xiàn)就是標(biāo)志沒清干凈。3.2 Flash擦寫與數(shù)據(jù)接收的實(shí)現(xiàn)要點(diǎn)Flash寫入是IAP的核心動作代碼不復(fù)雜但細(xì)節(jié)多。以F1系列和HAL庫為例擦除一個頁1KB的典型寫法FLASH_EraseInitTypeDef eraseCfg {0}; uint32_t pageError 0; HAL_FLASH_Unlock(); eraseCfg.TypeErase FLASH_TYPEERASE_PAGES; eraseCfg.PageAddress app_addr; eraseCfg.NbPages 1; HAL_FLASHEx_Erase(eraseCfg, pageError); HAL_FLASH_Lock();寫入一個半字F1必須按半字16位寫入F4可以按字32位或雙字64位寫入HAL_FLASH_Unlock(); HAL_FLASH_Program(FLASH_TYPEPROGRAM_HALFWORD, app_addr, (uint16_t)data); HAL_FLASH_Lock();寫Flash之前必須確保目標(biāo)區(qū)域已經(jīng)擦除Flash只能把1寫成0不能把0寫成1。這就是為什么擦除要在寫數(shù)據(jù)之前整體做完而不是邊擦邊寫。如果上一版固件沒擦干凈新數(shù)據(jù)寫進(jìn)去就會出現(xiàn)隨機(jī)錯誤App跑起來各種怪問題。數(shù)據(jù)接收這塊我強(qiáng)烈建議給串口加DMA至少用中斷接收。Bootloader在擦除Flash的時候CPU是卡住的擦一頁雖然只要幾十毫秒但如果有串口數(shù)據(jù)在這個窗口到達(dá)查詢接收方式就丟了。解決方法是用DMA接收把數(shù)據(jù)先緩存到RAM里擦除完成后再從緩存寫入Flash。如果用的還是查詢接收建議把串口緩沖區(qū)加大到至少兩包的大小并用環(huán)形緩沖。3.3 從Bootloader跳轉(zhuǎn)到App的注意事項跳轉(zhuǎn)是所有IAP項目里最容易被問到的部分看網(wǎng)上代碼可能十個人有十種寫法但核心只有幾件事校驗(yàn)App區(qū)合法性、關(guān)閉中斷和外設(shè)、設(shè)置棧指針、跳轉(zhuǎn)到Reset Handler。我常用的跳轉(zhuǎn)函數(shù)#define APP_START_ADDR 0x08008000 typedef void (*pFunction)(void); void JumpToApp(void) { uint32_t sp *(volatile uint32_t *)APP_START_ADDR; uint32_t reset *(volatile uint32_t *)(APP_START_ADDR 4); pFunction appEntry; // 棧指針必須落在RAM范圍內(nèi)Reset Handler必須在Flash范圍內(nèi) if ((sp 0xFFF00000) ! 0x20000000) { // 非法App區(qū)停在Bootloader等待重新升級 while (1); } // 關(guān)閉全局中斷 __disable_irq(); // 復(fù)位外設(shè)避免將Bootloader的外設(shè)狀態(tài)帶到App里 HAL_RCC_DeInit(); SysTick-CTRL 0; SysTick-LOAD 0; SysTick-VAL 0; // 設(shè)置App的棧頂指針 __set_MSP(sp); // 取App的Reset Handler地址并跳轉(zhuǎn) appEntry (pFunction)reset; appEntry(); while (1); }這段代碼有幾個點(diǎn)要解釋清楚。為什么跳轉(zhuǎn)前要關(guān)中斷因?yàn)橹袛嘞蛄勘砟J(rèn)還指向Bootloader區(qū)域跳轉(zhuǎn)瞬間如果來了一個中斷CPU會從Bootloader的向量表里取中斷服務(wù)函數(shù)地址但此時棧指針已經(jīng)切到App的棧了棧上下文對不上極容易死機(jī)。更安全的方法是先關(guān)所有外設(shè)中斷并清掉NVIC里pending的中斷標(biāo)志。為什么HAL_RCC_DeInit()Bootloader初始化過串口、定時器等外設(shè)跳轉(zhuǎn)后App會重新初始化這些外設(shè)。如果外設(shè)的時鐘配置還停留在Bootloader的狀態(tài)App初始化時可能讀到錯誤的狀態(tài)寄存器導(dǎo)致配置混亂。這條我在實(shí)際項目里驗(yàn)證過很多“跳轉(zhuǎn)到App后能跑但串口打印亂碼”的詭異問題根源就在外設(shè)時鐘沒復(fù)位。為什么那行if ((sp 0xFFF00000) ! 0x20000000)這是App合法性的第一個檢查。如果App區(qū)是空的或者數(shù)據(jù)不對跳轉(zhuǎn)進(jìn)去就是死機(jī)。檢查時只判斷高位是否需要落在RAM范圍內(nèi)是因?yàn)椴煌腟TM32型號RAM大小不同但片內(nèi)RAM的基地址都是0x20000000用這個判斷足以過濾掉大量非法地址。3.4 App側(cè)必須做的三件事VTOR、編譯地址、固件標(biāo)志App側(cè)的代碼改動比很多人想象的要少但漏掉任何一個都會出問題。第一件事中斷向量表重映射。Cortex-M3/M4內(nèi)核里有一個VTOR寄存器專門存放當(dāng)前使用的中斷向量表基地址。芯片默認(rèn)值是0x08000000也就是Flash基地址。App被鏈接到0x08008000之后它的中斷服務(wù)函數(shù)向量表也跟著到了0x08008000但CPU還傻乎乎地按默認(rèn)地址取向量于是一觸發(fā)中斷就取到了Bootloader代碼區(qū)的地址跑飛了。解決辦法是在App的main函數(shù)開頭加上一行int main(void) { // 必須在HAL_Init之前設(shè)置否則初始化過程一旦發(fā)生中斷就會出問題 SCB-VTOR 0x08008000; HAL_Init(); ... }注意地址的低幾位必須是0VTOR要求128字節(jié)對齊你的App起始地址只要是頁對齊的天然滿足要求。第二件事編譯地址。App的鏈接腳本或IDE的ROM起始地址必須改成0x08008000。Keil里在Options for Target的IROM1里把Start改成0x08008000Size改成0x00078000對應(yīng)480KB如果用STM32CubeIDE需要在鏈接腳本里修改FLASH的ORIGIN和LENGTH。這一步漏掉的話編譯出來的固件向量表還鏈在0x08000000即使VTOR設(shè)置了向量表本身放的位置也不對App的中斷依然會亂。第三件事固件標(biāo)志。App在正常運(yùn)行之后可以把參數(shù)區(qū)里的“App有效”標(biāo)志寫掉表示新固件已經(jīng)穩(wěn)定運(yùn)行。有些方案還會在App啟動后通過串口上報自己的版本號讓Bootloader或上位機(jī)確認(rèn)當(dāng)前運(yùn)行的固件版本方便排查。4. 可靠性設(shè)計校驗(yàn)、回滾、掉電保護(hù)4.1 CRC校驗(yàn)與固件完整性固件在傳輸過程中可能被干擾、被截斷所以完整性校驗(yàn)不能只靠數(shù)據(jù)幀的CRC16必須有整體校驗(yàn)。我通常在協(xié)議的開始幀里帶上整個固件文件的CRC32Bootloader收完所有數(shù)據(jù)幀后對寫入Flash的App區(qū)從頭到尾算一個CRC32兩個值相同才允許跳轉(zhuǎn)。HAL庫里可以直接用硬件CRC外設(shè)uint32_t crc32_calc(uint32_t *data, uint32_t len) { __HAL_RCC_CRC_CLK_ENABLE(); HAL_CRC_Init(hcrc); return HAL_CRC_Calculate(hcrc, data, len); }但要注意不同平臺對CRC32的初始值、位序、結(jié)果異或等參數(shù)定義可能不同上位機(jī)計算固件CRC的算法必須和單片機(jī)側(cè)保持一致否則兩邊算出來的結(jié)果永遠(yuǎn)對不上。我自己踩過這個坑最后老老實(shí)實(shí)把上位機(jī)和Bootloader的CRC算法統(tǒng)一成同樣的參數(shù)才解決。4.2 回滾策略對比升級最怕的是新固件有Bug寫入成功了、也能跳轉(zhuǎn)但跑起來就死機(jī)。這時候如果Bootloader沒有回滾機(jī)制設(shè)備就徹底變成磚了。業(yè)界常見的兩種回滾策略各有取舍。A/B升級是最內(nèi)涵的方案Flash里放兩個App區(qū)A區(qū)跑舊固件新固件寫入B區(qū)校驗(yàn)通過后再更新啟動標(biāo)志下次啟動運(yùn)行B區(qū)。如果B區(qū)運(yùn)行不穩(wěn)定由Bootloader或App把標(biāo)志切回A區(qū)。這個方案最穩(wěn)但代價是Flash容量直接翻倍只適合大容量芯片比如F4/F7/H7系列。小容量芯片比如只有128KB甚至64KB更適合做“故障重刷”方案App區(qū)只有一份升級失敗后Bootloader不跳轉(zhuǎn)停留在等待接收固件的狀態(tài)上位機(jī)可以重新發(fā)送固件包。代價是設(shè)備在修復(fù)前處于不可用狀態(tài)但至少不會變磚現(xiàn)場維護(hù)人員拿著升級工具重新刷一遍即可。回滾方案的另一個細(xì)節(jié)是版本號策略升級前先記錄舊固件版本升級完成后如果App側(cè)檢測到自身運(yùn)行異?？梢栽趨?shù)區(qū)標(biāo)記回滾請求。這屬于較高級的設(shè)計常規(guī)項目可以先不做。我建議第一步先把A/B或故障重刷的框架搭好再考慮自動回滾。4.3 掉電保護(hù)參數(shù)標(biāo)志與寫入順序升級過程中掉電是最糟糕的場景處理不好設(shè)備會白屏、死機(jī)甚至損壞Flash。保護(hù)方案的核心是“寫入順序”。我習(xí)慣在參數(shù)區(qū)維護(hù)這樣的標(biāo)志#define APP_VALID_MAGIC 0xA5A5A5A5 // App是健康的 #define APP_INVALID_MAGIC 0xAAAAAAAA // App不可用/正在升級 #define UPDATE_REQUEST_MAGIC 0x5A5A5A5A // 請求進(jìn)入升級模式升級流程是這樣的收到開始幀先寫UPDATE_REQUEST_MAGIC表示要進(jìn)入升級流程擦除App區(qū)逐包寫入新固件全部寫入完成且CRC32整體校驗(yàn)通過再寫APP_VALID_MAGICBootloader下一次啟動發(fā)現(xiàn)APP_VALID_MAGIC有效直接跳轉(zhuǎn)App如果在“逐包寫入”階段掉電啟動時Bootloader看到的App區(qū)無效或CRC不對不會跳轉(zhuǎn)而是停留在等待升級的狀態(tài)。因?yàn)樯墭?biāo)志和App有效性標(biāo)志是分步更新的App區(qū)數(shù)據(jù)不完整時有效標(biāo)志不會被寫入安全邊界就清晰了。另外一個容易忽略的點(diǎn)寫標(biāo)志位置不要固定一個地址建議放在參數(shù)區(qū)末尾一個單獨(dú)的頁里。如果標(biāo)志和App的末尾數(shù)據(jù)在同一個頁App區(qū)重新擦除時會連帶把標(biāo)志也擦掉那就麻煩了。5. 實(shí)測中的常見問題與排查技巧5.1 跳轉(zhuǎn)后卡死或跑飛這類問題排在IAP故障第一位現(xiàn)象是Bootloader那行跳轉(zhuǎn)執(zhí)行完設(shè)備就卡死了。排查順序我一般按下面這個來先查App起始地址的前8個字節(jié)前4字節(jié)是初始棧指針必須落在RAM地址范圍0x20000000開頭后4字節(jié)是Reset Handler地址必須落在Flash范圍。打印這兩個值基本能排除App區(qū)為空、燒錄地址錯誤、鏈接腳本沒改的問題。再查跳轉(zhuǎn)前的中斷處理。SysTick在Bootloader里被初始化過如果跳轉(zhuǎn)時不關(guān)閉SysTickApp啟動時又會初始化一次SysTick容易出問題。記得把SysTick的CTRL、LOAD、VAL全部清零同時調(diào)用__disable_irq()關(guān)閉全局中斷。最后查App側(cè)的VTOR。很多App代碼是在HAL_Init之后才設(shè)置VTOR這其實(shí)存在風(fēng)險窗口。我的建議是App的main第一行就寫SCB-VTOR然后才是HAL_Init。我還遇到過一種特殊情況跳轉(zhuǎn)前Bootloader把串口中斷掛在NVIC里沒清跳轉(zhuǎn)后App初始化串口時一使能中斷CPU立刻進(jìn)入一個中斷服務(wù)函數(shù)而那個函數(shù)地址是Bootloader的遺留值直接HardFault。解決辦法是在跳轉(zhuǎn)前調(diào)用HAL_NVIC_DisableAllIRQs()并把NVIC的pending位清掉。5.2 升級中斷、Flash擦寫失敗升級到一半斷連最常見的原因是串口緩沖溢出。Bootloader一邊擦Flash一邊用查詢方式收串口擦除期間進(jìn)來的數(shù)據(jù)全丟了。我在3.2里已經(jīng)提過這里再強(qiáng)調(diào)一次用DMA接收或者把串口接收中斷優(yōu)先級調(diào)高讓數(shù)據(jù)先落到RAM緩沖區(qū)擦寫完成后再處理。Flash寫入失敗則優(yōu)先檢查三件事有沒有先調(diào)用HAL_FLASH_Unlock()目標(biāo)地址是不是頁對齊的App區(qū)容量是不是不夠了。F1的頁是1KBF4的低密度扇區(qū)有的只有16KB不同芯片差異很大寫之前一定要查參考手冊里的Flash內(nèi)存映射表。另一個隱蔽問題芯片開了讀保護(hù)RDP等級為1或2Flash寫保護(hù)生效時擦除和編程都會被拒絕。這種情況在量產(chǎn)板上比較常見通過SWD重新設(shè)RDP等級才能恢復(fù)。如果項目有量產(chǎn)燒錄步驟一定要在燒錄流程里把讀保護(hù)狀態(tài)統(tǒng)一規(guī)劃好。5.3 升級完成后App功能異常能跳轉(zhuǎn)、能跑但外設(shè)不正常十有八九是外設(shè)狀態(tài)被Bootloader污染了。典型現(xiàn)象是App啟動后串口打印亂碼、GPIO電平不對。原因就是跳轉(zhuǎn)前沒有復(fù)位外設(shè)Bootloader把串口波特率改過、把某個GPIO配置成了輸出App重新初始化時配置寄存器里還殘留著之前的狀態(tài)。處理手段就是HAL_RCC_DeInit()把所有外設(shè)時鐘關(guān)掉再把SysTick歸零。這里有個細(xì)節(jié)要注意HAL_RCC_DeInit會影響Flash預(yù)取緩沖和時鐘樹跳轉(zhuǎn)后App的SystemClock_Config會重新配置這沒問題。但如果JumpToApp里在HAL_RCC_DeInit之后又調(diào)用任何HAL庫函數(shù)那些函數(shù)會因?yàn)樗鼉?nèi)部依賴HAL狀態(tài)而出現(xiàn)異常所以跳轉(zhuǎn)函數(shù)的最后一段盡量只做裸寄存器操作。還有一類問題出在App本身App里用了某個外設(shè)中斷但沒有初始化對應(yīng)的NVIC使能或者中斷優(yōu)先級分組和Bootloader不一致。升級后死機(jī)不一定都是Flash的問題有時候就是兩個工程的中斷配置互相打架。開發(fā)時建議把Boot和App的中斷優(yōu)先級分組設(shè)為同一個值比如都是HAL_NVIC_SetPriorityGrouping(NVIC_PRIORITYGROUP_4)。6. 實(shí)測中的常見問題速查表故障現(xiàn)象可能原因排查方法跳轉(zhuǎn)后死機(jī)App首地址數(shù)據(jù)非法打印棧指針和Reset Handler地址檢查是否在合法范圍跳轉(zhuǎn)后死機(jī)中斷向量表偏移未設(shè)置App main第一行設(shè)置SCB-VTOR確認(rèn)地址等于App起始地址跳轉(zhuǎn)后死機(jī)跳轉(zhuǎn)前中斷未關(guān)閉干凈__disable_irq() 清NVIC pending SysTick歸零升級中途斷連串口緩沖溢出啟用DMA接收或加大環(huán)形緩沖Flash寫入失敗Flash未解鎖HAL_FLASH_Unlock()后再操作Flash寫入失敗地址未按頁/扇區(qū)對齊查閱參考手冊確認(rèn)頁大小Flash寫入失敗讀保護(hù)開啟檢查RDP等級量產(chǎn)時統(tǒng)一規(guī)劃App能跑但功能異常外設(shè)狀態(tài)被Boot污染跳轉(zhuǎn)前HAL_RCC_DeInit復(fù)位所有外設(shè)重復(fù)進(jìn)入升級模式升級標(biāo)志未清除升級成功或失敗流程里清除標(biāo)志CRC校驗(yàn)總失敗上位機(jī)和設(shè)備算法不一致統(tǒng)一CRC參數(shù)初始值、位序、輸出異或這張表我建議直接打印出來貼在工位旁邊很多問題其實(shí)看一眼就知道方向了。7. 最后再分享幾點(diǎn)個人經(jīng)驗(yàn)做IAP項目這幾年我最大的體會是讓系統(tǒng)跑起來只需要半天讓它穩(wěn)定跑一年才是真正的難點(diǎn)。代碼里那些看起來不起眼的細(xì)節(jié)比如跳轉(zhuǎn)前關(guān)中斷、App區(qū)合法性檢查、升級標(biāo)志的寫入順序才是防住線上事故的關(guān)鍵屏障。這里補(bǔ)充三個我習(xí)慣用的小技巧算是壓箱底的東西。第一在Bootloader和App兩條分支里都留一個串口打印的入口。Bootloader啟動時打印自己的版本和“upgrade mode”或“app mode”狀態(tài)App啟動時打印自己的版本。這樣設(shè)備到手插上串口一看日志就知道它停在哪一步排查效率能翻倍。第二升級固件建議用bin文件而不要用hex文件。hex是Intel格式的文本文件包含地址信息和校驗(yàn)段Bootloader解析起來要額外處理分段、字節(jié)數(shù)、地址對齊等問題復(fù)雜度高。bin文件就是純代碼數(shù)據(jù)從起始地址開始連續(xù)排列Bootloader按順序?qū)慒lash就行簡單直接。生成bin文件的辦法是在IDE里配置一個后處理命令比如Keil的fromelf命令網(wǎng)上資料一搜就有。第三給每個固件包加一個版本字段放在開始幀里。Bootloader可以檢查新版本和當(dāng)前版本是否一致一致就直接拒絕升級。這個功能看起來小但在現(xiàn)場批量維護(hù)時特別有用省得運(yùn)維人員一遍遍刷同一個版本還看不出效果。IAP這套東西看起來是幾段代碼的拼湊但實(shí)際牽扯到芯片架構(gòu)、編譯器、協(xié)議、存儲布局多個層面。這篇文章講的是我踩過的坑和驗(yàn)證過的方案如果你正準(zhǔn)備做集成建議先拿一塊開發(fā)板把串口IAP從Boot到App完整跑通再去考慮CAN、以太網(wǎng)、OTA的改造?；A(chǔ)鏈路穩(wěn)了剩下的都是錦上添花。