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