嵌入式產(chǎn)品做到后期幾乎躲不開一件事固件升級(jí)。更準(zhǔn)確地說是“怎么讓固件升級(jí)這件事不再讓人提心吊膽”。如果你寫過帶Bootloader的STM32程序大概率經(jīng)歷過這種場景App跑著跑著要升級(jí)結(jié)果升級(jí)過程中串口線被碰了一下、電源抖了一下、或者固件傳輸?shù)揭话刖W(wǎng)絡(luò)斷了。等再上電設(shè)備黑屏變磚了。傳統(tǒng)方案Bootloader 單App區(qū)Bootloader一旦跳轉(zhuǎn)到寫入一半的App整個(gè)產(chǎn)品就廢了。想要救回來多半得返廠或者拿燒錄器重新擦。這篇教程要聊的就是STM32F103上從零復(fù)現(xiàn)一套AB雙分區(qū)OTA方案。不依賴云平臺(tái)、不需要額外上系統(tǒng)、不涉及專門加密芯片純靠MCU內(nèi)部Flash分區(qū)、標(biāo)志位、跳轉(zhuǎn)邏輯和一套簡單的串口通信協(xié)議把“升級(jí)變磚”這個(gè)隱患從根上解決掉。方案原型來自我自己在多個(gè)量產(chǎn)項(xiàng)目里跑過的寫法你完全可以在標(biāo)準(zhǔn)庫V3.5工程里照著復(fù)刻用常用開發(fā)板就能驗(yàn)證。文章會(huì)照顧到兩邊讀者只聽說過AB OTA但沒自己寫過的人可以完整走一遍流程已經(jīng)寫好跳轉(zhuǎn)邏輯但回滾總是不穩(wěn)定的人也能從后面的問題排查部分找到一些沒注意到的細(xì)節(jié)。全程按代碼、配置、實(shí)測三個(gè)維度展開。1. AB OTA整體設(shè)計(jì)與思路拆解1.1 為什么AB分區(qū)比“Bootloader單App區(qū)”更值得做多數(shù)人理解OTA升級(jí)腦子里浮現(xiàn)的是一條線Bootloader接收固件擦掉現(xiàn)有App區(qū)把新固件寫進(jìn)去然后跳轉(zhuǎn)。這條鏈路看著簡單實(shí)際上一旦開始接收數(shù)據(jù)舊固件就已經(jīng)被擦掉或部分覆蓋了。新固件不完整、傳輸中斷、校驗(yàn)出錯(cuò)任何一個(gè)小意外都意味著設(shè)備失去了可運(yùn)行的固件。AB分區(qū)方案把邏輯反過來Flash里始終有兩個(gè)App區(qū)一個(gè)正在運(yùn)行一個(gè)等待寫入。OTA升級(jí)時(shí)Bootloader或者正在運(yùn)行的App把新固件完整寫入空閑區(qū)。只有在完整性校驗(yàn)通過后才通過標(biāo)志位讓設(shè)備重啟切換到新分區(qū)。萬一校驗(yàn)失敗或者新固件跑不起來另一邊的舊固件還在系統(tǒng)隨時(shí)可以回滾。這就像寫字樓的雙路供電。一路電源突然出問題另一路立刻頂上用戶幾乎無感知。AB分區(qū)的核心價(jià)值不是“升級(jí)更快”而是“任何時(shí)候都保證有一塊能啟動(dòng)的固件”。1.2 Flash分區(qū)規(guī)劃與技術(shù)要點(diǎn)STM32F103的Flash從0x08000000開始容量從64KB到512KB不等。為了讓AB分區(qū)有實(shí)際意義建議至少選256KB以上的型號(hào)。給個(gè)我常用的512KB布局型號(hào)對(duì)應(yīng)STM32F103ZET6或RCT6都適用。區(qū)域起始地址大小用途Bootloader0x0800000064KB啟動(dòng)引導(dǎo)、OTA接收、擦寫、回滾App區(qū)A0x08010000224KB正式版本固件App區(qū)B0x08048000224KB備用版本固件標(biāo)志區(qū)0x0807F8002KB分區(qū)有效性標(biāo)志、升級(jí)狀態(tài)Bootloader單獨(dú)占一段是因?yàn)樗袚?dān)了最關(guān)鍵的啟動(dòng)決策和刷寫邏輯不能讓升級(jí)過程中任何意外波及到它。A/B兩個(gè)App區(qū)各224KB對(duì)大部分STM32F103應(yīng)用來說很寬裕。如果你想做產(chǎn)品化可以再預(yù)留一些富余量避免后期功能膨脹導(dǎo)致裝不下。標(biāo)志區(qū)單獨(dú)放在最后2KB不用跟任何App區(qū)混在一起。這樣設(shè)計(jì)的好處是刷寫App區(qū)的時(shí)候即使把地址算錯(cuò)了一點(diǎn)點(diǎn)也只會(huì)碰到相鄰的App區(qū)不會(huì)把標(biāo)志數(shù)據(jù)沖掉。訪問Flash時(shí)一定要注意STM32F103寫Flash是以半字為單位頁擦除是1KB一頁。所以標(biāo)志區(qū)哪怕只用幾個(gè)字節(jié)也會(huì)占用整整兩頁Flash。1.3 升級(jí)與回滾的核心機(jī)制正常升級(jí)流程可以拆成下面幾步設(shè)備運(yùn)行在App區(qū)A。用戶觸發(fā)升級(jí)App區(qū)A將新固件分包寫入App區(qū)B。全部寫入完成對(duì)固件做整體CRC校驗(yàn)。校驗(yàn)通過在標(biāo)志區(qū)寫入“B區(qū)有效”標(biāo)志。系統(tǒng)軟復(fù)位Bootloader讀取標(biāo)志后跳轉(zhuǎn)到App區(qū)B。App區(qū)B啟動(dòng)后運(yùn)行一段時(shí)間比如30秒確認(rèn)功能正常再寫入“運(yùn)行確認(rèn)”標(biāo)志?；貪L的過程發(fā)生在第5步之后。如果App區(qū)B在上電后起不來——跑飛、HardFault、看門狗沒喂——Bootloader會(huì)在下一次復(fù)位時(shí)發(fā)現(xiàn)B區(qū)沒有“運(yùn)行確認(rèn)”標(biāo)志自動(dòng)跳回App區(qū)A。這個(gè)設(shè)計(jì)里最關(guān)鍵的一個(gè)理念是新固件在“試用期”內(nèi)還不算正式生效經(jīng)過確認(rèn)后才轉(zhuǎn)正。很多OTA方案只做了前4步丟掉了第6步的確認(rèn)機(jī)制回滾等于形同虛設(shè)。后面實(shí)現(xiàn)代碼時(shí)會(huì)看到這個(gè)確認(rèn)步驟其實(shí)非常簡單但對(duì)穩(wěn)定性的提升是質(zhì)變。2. 環(huán)境準(zhǔn)備與工程搭建2.1 軟硬件準(zhǔn)備清單硬件方面一塊STM32F103最小系統(tǒng)板或者正點(diǎn)原子/野火開發(fā)板都行因?yàn)锳B方案用到的就是片上資源跟具體板子關(guān)系不大。核心要求有幾個(gè)STM32F103Flash容量256KB以上一個(gè)USB轉(zhuǎn)TTL模塊用于串口OTA傳輸一個(gè)LED接在某個(gè)GPIO上作為狀態(tài)指示一個(gè)按鍵用于強(qiáng)制進(jìn)入升級(jí)模式軟件環(huán)境我用的是Keil MDK 5 ST標(biāo)準(zhǔn)外設(shè)庫V3.5.0。標(biāo)準(zhǔn)庫雖然老但STM32F103的生態(tài)資料最全的就是它網(wǎng)上搜問題能快速找到答案。串口調(diào)試助手用XCOM或者SSCOM都行這里建議帶文件發(fā)送功能的方便后面直接發(fā)送OTA固件包。2.2 Bootloader工程配置Bootloader的工程需求很明確跳轉(zhuǎn)、燒錄、串口通信。新建工程以后需要開啟的模塊是GPIO、USART1、FLASH和看門狗如果做超時(shí)回滾。編譯地址設(shè)置在這里格外重要。打開Options for Target Target把IROM1的起始地址設(shè)為0x08000000大小設(shè)為0x10000也就是64KB。這一步?jīng)Q定了Bootloader程序會(huì)被編譯到固定起始地址的Flash區(qū)域。不修改這個(gè)值后面跳轉(zhuǎn)時(shí)地址全對(duì)不上。編譯設(shè)置和普通工程一樣勾選Create HEX File方便生成可以直接燒錄的HEX文件。串口用USART1波特率建議115200數(shù)據(jù)位8停止位1無校驗(yàn)。這個(gè)波特率在STM32F103上配合外部8MHz晶振很好算不容易出頻率誤差。2.3 APP工程配置與中斷向量偏移APP工程要管理兩件事編譯地址改到App區(qū)A的起始地址中斷向量表也要跟著偏移。先說編譯地址。假設(shè)用App區(qū)A起始地址就是0x08010000大小是0x38000。Keil的IROM1里按這個(gè)范圍填。RAM不用動(dòng)STM32F103的SRAM是統(tǒng)一編址的從0x20000000開始。再說中斷向量表偏移。單片機(jī)復(fù)位后CPU從0x08000000讀取棧頂指針和復(fù)位向量這是Bootloader的區(qū)域。當(dāng)Bootloader把控制權(quán)交給App后App里所有的中斷請求比如串口接收中斷、定時(shí)器中斷都還指向0x08000000的中斷向量表。如果不把向量表重定位到App區(qū)一進(jìn)中斷就跳去執(zhí)行Bootloader的代碼直接跑飛。標(biāo)準(zhǔn)庫V3.5的做法是在系統(tǒng)初始化后調(diào)用NVIC_SetVectorTable(NVIC_VectTab_FLASH, 0x10000);或者直接操作寄存器SCB-VTOR 0x08010000;注意這句必須在啟動(dòng)早期執(zhí)行最好放在main函數(shù)最開始的位置。晚了的話在設(shè)置之前來的中斷就已經(jīng)出問題了。另一個(gè)容易忽略的點(diǎn)是鏈接腳本里要確保App的起始地址跟VTOR的偏移量是同一個(gè)值否則程序一進(jìn)中斷就不知道跑哪去了。3. Bootloader功能實(shí)現(xiàn)3.1 啟動(dòng)流程與版本標(biāo)志判斷Bootloader的main函數(shù)是所有AB OTA方案的決策中心。上電后第一步是初始化時(shí)鐘和必要的GPIO然后讀取標(biāo)志區(qū)。根據(jù)標(biāo)志區(qū)的狀態(tài)決定是正常跳轉(zhuǎn)App還是進(jìn)入升級(jí)模式。流程可以抽象成三層判斷讀升級(jí)模式觸發(fā)源按鍵是否被按住、串口是否收到升級(jí)命令。讀分區(qū)標(biāo)志A區(qū)和B區(qū)哪個(gè)有效。檢查運(yùn)行確認(rèn)狀態(tài)有效分區(qū)是否被確認(rèn)過能正常工作。APP工程要管理兩件事編譯地址改到App區(qū)A的起始地址中斷向量表也要跟著偏移。先說編譯地址。假設(shè)用App區(qū)A起始地址就是0x08010000大小是0x38000。Keil的IROM1里按這個(gè)范圍填。RAM不用動(dòng)STM32F103的SRAM是統(tǒng)一編址的從0x20000000開始。再說中斷向量表偏移。單片機(jī)復(fù)位后CPU從0x08000000讀取棧頂指針和復(fù)位向量這是Bootloader的區(qū)域。當(dāng)Bootloader把控制權(quán)交給App后App里所有的中斷請求比如串口接收中斷、定時(shí)器中斷都還指向0x08000000的中斷向量表。如果不把向量表重定位到App區(qū)一進(jìn)中斷就跳去執(zhí)行Bootloader的代碼直接跑飛。標(biāo)準(zhǔn)庫V3.5的做法是在系統(tǒng)初始化后調(diào)用NVIC_SetVectorTable(NVIC_VectTab_FLASH, 0x10000);或者直接操作寄存器SCB-VTOR 0x08010000;注意這句必須在啟動(dòng)早期執(zhí)行最好放在main函數(shù)最開始的位置。晚了的話在設(shè)置之前來的中斷就已經(jīng)出問題了。另一個(gè)容易忽略的點(diǎn)是鏈接腳本里要確保App的起始地址跟VTOR的偏移量是同一個(gè)值否則程序一進(jìn)中斷就不知道跑哪去了。3.1 啟動(dòng)流程與版本標(biāo)志判斷Bootloader的main函數(shù)是所有AB OTA方案的決策中心。上電后第一步是初始化時(shí)鐘和必要的GPIO然后讀取標(biāo)志區(qū)。根據(jù)標(biāo)志區(qū)的狀態(tài)決定是正常跳轉(zhuǎn)App還是進(jìn)入升級(jí)模式。流程可以抽象成三層判斷讀升級(jí)模式觸發(fā)源按鍵是否被按住、串口是否收到升級(jí)命令。讀分區(qū)標(biāo)志A區(qū)和B區(qū)哪個(gè)有效。檢查運(yùn)行確認(rèn)狀態(tài)有效分區(qū)是否被確認(rèn)過能正常工作。標(biāo)志區(qū)的數(shù)據(jù)結(jié)構(gòu)我用了一個(gè)結(jié)構(gòu)體在Flash末地址2KB范圍內(nèi)偏移存儲(chǔ)#define FLAG_BASE_ADDR 0x0807F800UL typedef struct { uint32_t magic; // 固定值0xA5A5A5A5表示標(biāo)志區(qū)已被正確寫入 uint32_t active_slot; // 1表示引導(dǎo)A區(qū)2表示引導(dǎo)B區(qū) uint32_t boot_confirm; // 當(dāng)前分區(qū)是否已確認(rèn)運(yùn)行成功 uint32_t boot_count; // 連續(xù)啟動(dòng)計(jì)數(shù)用于異?；貪L保護(hù) } ota_flag_t;active_slot就是Bootloader決定跳哪個(gè)區(qū)的依據(jù)。boot_confirm是整個(gè)回滾機(jī)制的核心它由App運(yùn)行一段時(shí)間后主動(dòng)寫入。boot_count則是用來處理“新分區(qū)能啟動(dòng)但馬上崩潰”這種情況。每次Bootloader跳轉(zhuǎn)到未確認(rèn)分區(qū)時(shí)boot_count加一超過設(shè)定次數(shù)就強(qiáng)制切回舊分區(qū)防止系統(tǒng)無限重啟。3.2 跳轉(zhuǎn)APP的實(shí)現(xiàn)細(xì)節(jié)跳轉(zhuǎn)是整個(gè)方案技術(shù)上最關(guān)鍵的部分。網(wǎng)上能搜到很多版本但核心就幾行代碼typedef void (*pFunction)(void); void JumpToApp(uint32_t app_addr) { uint32_t app_sp *(volatile uint32_t *)app_addr; uint32_t app_pc *(volatile uint32_t *)(app_addr 4); pFunction app_reset; // 簡單合法性校驗(yàn)防止跳到一個(gè)空的Flash區(qū)域 if ((app_sp 0xFFF00000) ! 0x20000000) { return; } if ((app_pc 0xFFF00000) ! 0x08000000) { return; } app_reset (pFunction)app_pc; // 跳轉(zhuǎn)前關(guān)閉全局中斷把外設(shè)清干凈 __disable_irq(); SysTick-CTRL 0; SysTick-LOAD 0; SysTick-VAL 0; __set_MSP(app_sp); app_reset(); }為什么要重新設(shè)置MSP因?yàn)閺?fù)位后MSP一直指向Bootloader的棧頂。App程序在編譯鏈接時(shí)棧頂?shù)刂肥前碅pp自己的起始地址計(jì)算的。如果沿用Bootloader的棧一旦App調(diào)用函數(shù)壓棧數(shù)據(jù)可能會(huì)寫進(jìn)Bootloader的工作變量區(qū)輕則變量被覆蓋重則棧溢出直接HardFault。跳轉(zhuǎn)前關(guān)閉全局中斷這一點(diǎn)也有講究。如果在跳轉(zhuǎn)瞬間還有中斷進(jìn)來中斷向量表指向的還是Bootloader區(qū)域跳轉(zhuǎn)動(dòng)作會(huì)被打斷。加上__disable_irq()之后等App自己初始化完中斷再打開才能保證第一次進(jìn)中斷時(shí)的環(huán)境是干凈的。3.3 Bootloader進(jìn)入升級(jí)模式的策略Bootloader不能只會(huì)“跳”還得會(huì)“接”。產(chǎn)品實(shí)際使用中用戶不一定按得住按鍵所以升級(jí)觸發(fā)方式得做兩手準(zhǔn)備上電時(shí)檢測升級(jí)按鍵按鍵按住3秒以上進(jìn)入升級(jí)模式。運(yùn)行中的App收到升級(jí)指令后主動(dòng)在標(biāo)志區(qū)寫入“進(jìn)入升級(jí)模式”標(biāo)記然后軟復(fù)位。Bootloader看到這個(gè)標(biāo)記就不跳轉(zhuǎn)而是停留等待OTA。進(jìn)入升級(jí)模式后Bootloader需要跟發(fā)送端進(jìn)行簡單的握手。握手成功后才開始接收固件。使用串口中斷接收每收到一幀解析一幀寫入臨時(shí)緩沖區(qū)。這里有一個(gè)經(jīng)驗(yàn)不要在串口中斷里直接做Flash擦寫因?yàn)镕lash寫入會(huì)阻塞較長時(shí)間容易造成丟幀。正確做法是中斷里只收數(shù)據(jù)放到FIFO主循環(huán)里解析和寫Flash。4. APP端OTA功能實(shí)現(xiàn)4.1 升級(jí)觸發(fā)與接收協(xié)議實(shí)現(xiàn)App端的OTA功能本質(zhì)上是把Bootloader的一部分能力復(fù)制過來它知道自己要往“對(duì)面那個(gè)分區(qū)”寫數(shù)據(jù)。觸發(fā)方式可以根據(jù)產(chǎn)品形態(tài)自由發(fā)揮。按鍵觸發(fā)、上位機(jī)命令、服務(wù)器下發(fā)指令都可以。核心動(dòng)作是設(shè)置標(biāo)志區(qū)中的升級(jí)標(biāo)記然后調(diào)用NVIC_SystemReset()復(fù)位進(jìn)Bootloader。我在項(xiàng)目里常用串口命令比如收到“OTA_B”就表示要升級(jí)到B區(qū)。接收協(xié)議按我實(shí)踐的簡潔幀格式來字段長度說明幀頭2字節(jié)0xAA 0x55命令字1字節(jié)0x01握手0x02數(shù)據(jù)幀0x03結(jié)束幀數(shù)據(jù)長度2字節(jié)小端模式數(shù)據(jù)區(qū)0~256字節(jié)固件內(nèi)容或其他數(shù)據(jù)CRC162字節(jié)從命令字到數(shù)據(jù)區(qū)的CRC校驗(yàn)每幀最大256字節(jié)是因?yàn)镾TM32F103的RAM有限緩沖區(qū)開太大不劃算太小又導(dǎo)致發(fā)送端頻繁等待確認(rèn)。256字節(jié)在中速串口下效率算平衡點(diǎn)實(shí)測115200波特率下傳輸速度很理想。握手流程也很簡單App復(fù)位進(jìn)Bootloader后Bootloader向上位機(jī)發(fā)送0x01 0x01上位機(jī)回相同幀雙方確認(rèn)后就進(jìn)入數(shù)據(jù)傳輸階段。數(shù)據(jù)幀按序號(hào)排列Bootloader收到后回復(fù)ACK發(fā)送端收到ACK后發(fā)下一幀。這個(gè)簡單停等協(xié)議雖然效率不高但勝在邏輯簡單、調(diào)試容易在串口這種可靠鏈路上完全夠用。4.2 Flash擦除與寫入關(guān)鍵代碼寫入Flash的代碼是整個(gè)方案最容易出差錯(cuò)的地方。STM32F103的標(biāo)準(zhǔn)庫已經(jīng)把封裝做得很好了關(guān)鍵是要理解它背后的限制。代碼層面是這樣uint8_t OTA_WriteFlash(uint32_t addr, uint16_t *buf, uint32_t halfword_count) { uint32_t page_base; uint32_t i; // Flash寫入前必須解鎖、擦除 FLASH_Unlock(); // 計(jì)算目標(biāo)地址所在頁并擦除 page_base addr 0xFFFFFC00; FLASH_ErasePage(page_base); // 按半字寫入 for (i 0; i halfword_count; i) { if (FLASH_ProgramHalfWord(addr i * 2, buf[i]) ! FLASH_COMPLETE) { FLASH_Lock(); return 1; } } FLASH_Lock(); return 0; }這里有個(gè)關(guān)鍵點(diǎn)一個(gè)地址只能被擦除后寫入一次。換句話說不能對(duì)一個(gè)已寫入過的地址再次寫入除非擦掉整頁。所以接收固件時(shí)不能每收到一幀直接寫對(duì)應(yīng)地址而應(yīng)該先把整頁數(shù)據(jù)收齊攢在RAM緩沖區(qū)里再一次性擦除、寫入。否則就會(huì)出現(xiàn)局部數(shù)據(jù)覆蓋導(dǎo)致的Flash寫入錯(cuò)誤。實(shí)際操作中我是把接收緩沖區(qū)設(shè)成1KB正好對(duì)齊一頁攢滿一頁就擦寫一頁。最后一頁不足1KB也沒關(guān)系補(bǔ)0xFF填充成整頁再寫。擦除頁的計(jì)算要注意地址對(duì)齊。STM32F103的頁大小是1KB所以頁起始地址就是地址去掉低10位。直接用addr 0xFFFFFC00來算頁基址簡單又正確。4.3 固件校驗(yàn)與標(biāo)志位設(shè)置固件寫完不等于升級(jí)成功完整性和正確性校驗(yàn)是最后一道防線。我用的校驗(yàn)分兩層第一層是每幀CRC16這個(gè)在傳輸過程中就會(huì)做確保每一幀都沒有被串口噪聲破壞。第二層是整體CRC32在全部幀寫完后對(duì)整片固件區(qū)重新讀取計(jì)算CRC32跟固件包頭里攜帶的CRC32值比對(duì)。只有兩者一致才允許設(shè)置“B區(qū)有效”標(biāo)志。固件包頭我單獨(dú)定義了一個(gè)結(jié)構(gòu)體放在升級(jí)包最前面typedef struct { uint32_t magic; // 0x544F4142標(biāo)識(shí)這是一個(gè)OTA升級(jí)包 uint32_t total_len; // 固件總長度 uint32_t crc32; // 固件內(nèi)容的CRC32 uint32_t version; // 版本號(hào) } ota_header_t;這樣做的好處是定位問題快。如果傳輸中斷了包頭里的magic不對(duì)Bootloader一看就知道不是合法升級(jí)包直接忽略并跳回老分區(qū)。如果CRC32不對(duì)就說明固件在傳輸過程中被破壞了同樣回跳。設(shè)置標(biāo)志位時(shí)由于Flash寫入必須先擦后寫而標(biāo)志區(qū)只有2KB擦寫次數(shù)有限所以不能每次升級(jí)都寫。我寫了一個(gè)擦寫次數(shù)保護(hù)邏輯只有標(biāo)志區(qū)里沒有任何有效標(biāo)志時(shí)才執(zhí)行擦除操作有標(biāo)志時(shí)直接把對(duì)應(yīng)位置寫0x00更新。這樣能顯著降低標(biāo)志區(qū)Flash的磨損。5. 完整復(fù)現(xiàn)流程與實(shí)測記錄5.1 編譯燒錄Bootloader與APP按前面配置編譯兩個(gè)工程會(huì)得到Bootloader.hex和AppA.hex。編譯完成后先用ST-Link或者J-Link把Bootloader燒到0x08000000再把AppA燒到0x08010000。燒錄完成后接上串口打開串口助手按下復(fù)位鍵。如果一切正常串口會(huì)收到App的打印信息LED按App里的邏輯跑起來。這一步驗(yàn)證了Bootloader跳轉(zhuǎn)成功是后面所有OTA操作的基礎(chǔ)。接下來用Python腳本把AppA.hex轉(zhuǎn)成AppB.bin升級(jí)包加上包頭和CRC32。這里我再提一個(gè)實(shí)戰(zhàn)建議升級(jí)包最好在構(gòu)建服務(wù)器上自動(dòng)生成別用圖形化工具手工轉(zhuǎn)否則版本多了很難追溯。5.2 開始第一次OTA升級(jí)打開串口助手的文件發(fā)送功能選擇生成的AppB升級(jí)包。我的升級(jí)包做成了特定格式所以也可以自己寫個(gè)小工具來發(fā)送目前項(xiàng)目里用Python腳本直接打包發(fā)送。實(shí)際操作順序是當(dāng)前運(yùn)行AppA串口發(fā)送OTA_B命令。AppA收到命令設(shè)置“進(jìn)入升級(jí)模式”標(biāo)志軟復(fù)位。Bootloader檢測到升級(jí)標(biāo)志停留等待OTA。發(fā)送端等500ms后先發(fā)握手幀跟Bootloader建立連接。Bootloader回ACK后發(fā)送端開始按256字節(jié)一幀發(fā)數(shù)據(jù)。全部發(fā)完后Bootloader對(duì)整片B區(qū)做CRC32校驗(yàn)。校驗(yàn)通過Bootloader設(shè)置“B區(qū)有效”標(biāo)志復(fù)位。Bootloader引導(dǎo)到B區(qū)運(yùn)行AppB。實(shí)測在115200波特率下224KB的升級(jí)包大約耗時(shí)50秒左右。這個(gè)速度對(duì)大多數(shù)應(yīng)用來說完全能接受。升級(jí)過程中LED按特定頻率閃爍表示處于OTA狀態(tài)升級(jí)成功后就切換成新的呼吸燈模式。5.3 制造故障驗(yàn)證回滾驗(yàn)證回滾是AB OTA方案里最重要的一步。測試時(shí)不能只看“升級(jí)成功”這半邊更要驗(yàn)證“升級(jí)失敗能回來”。我常用的故障注入方法有兩個(gè)第一個(gè)直接改錯(cuò)CRC32。腳本生成升級(jí)包時(shí)故意把CRC32字段改成錯(cuò)值。正常升級(jí)流程走完Bootloader在最后CRC校驗(yàn)?zāi)且徊綍?huì)失敗然后自動(dòng)跳回A區(qū)。A區(qū)固件照常運(yùn)行就像什么都沒發(fā)生一樣。第二個(gè)把新固件改成會(huì)在啟動(dòng)后主動(dòng)觸發(fā)HardFault的版本。Bootloader正常引導(dǎo)到B區(qū)但B區(qū)代碼一跑就崩系統(tǒng)復(fù)位。Bootloader發(fā)現(xiàn)B區(qū)boot_confirm沒有置位經(jīng)過幾次復(fù)位后強(qiáng)制跳回A區(qū)。這個(gè)過程用戶完全無感最多看到設(shè)備多閃了兩下燈。這兩個(gè)測試跑通了AB OTA才算是真正閉環(huán)。我遇到過不少項(xiàng)目只測了升級(jí)成功鏈路回滾鏈路沒測結(jié)果上生產(chǎn)后第一批設(shè)備就出問題原因基本都是新固件啟動(dòng)異常又回不去。6. 常見問題與排查技巧實(shí)錄6.1 問題速查表實(shí)際操作中積累了一些高頻問題整理成速查表方便對(duì)照現(xiàn)象可能原因解決思路跳轉(zhuǎn)后白屏/全無反應(yīng)MSP設(shè)置錯(cuò)誤、App向量表沒偏移檢查設(shè)置MSP的地址是否是0x08010000開頭檢查SCB-VTOR升級(jí)過程中掉線串口波特率誤差大、FIFO溢出確認(rèn)晶振頻率計(jì)算波特率誤差增大接收緩沖區(qū)或改用16位FIFOFlash寫入HardFault未解鎖、地址越界、已寫入地址重復(fù)寫入檢查FLASH_Unlock是否配對(duì)確認(rèn)地址在有效Flash范圍內(nèi)CRC32總是不一致固件長度包含尾填充、CRC計(jì)算范圍不對(duì)計(jì)算CRC時(shí)嚴(yán)格限制在固件實(shí)際長度不含包頭和填充字節(jié)回滾后仍引導(dǎo)到壞分區(qū)boot_confirm標(biāo)志沒清除在切換分區(qū)前把boot_confirm清零防止舊標(biāo)志干擾判斷升級(jí)到一半按鍵復(fù)位后變磚Bootloader不完整或標(biāo)志區(qū)被覆蓋升級(jí)硬件前必須驗(yàn)證Bootloader能獨(dú)立跳轉(zhuǎn)標(biāo)志區(qū)地址避開App區(qū)終點(diǎn)6.2 踩坑記錄第一個(gè)坑是跳轉(zhuǎn)前的時(shí)鐘初始化問題。Bootloader里用SystemInit()初始化了系統(tǒng)時(shí)鐘跳轉(zhuǎn)后App的SystemInit()會(huì)再次設(shè)置時(shí)鐘。正常情況沒問題但如果Bootloader和App用的主頻配置不同比如Bootloader是72MHz、App是36MHz就會(huì)出現(xiàn)跳轉(zhuǎn)后外設(shè)工作不正常的情況。解決方法是統(tǒng)一時(shí)鐘頻率或者App啟動(dòng)后徹底重新初始化時(shí)鐘。第二個(gè)坑是串口中斷和Flash擦寫的沖突。一開始我把Flash擦寫放在了串口中斷處理函數(shù)里。串口每收滿一頁數(shù)據(jù)就在中斷里擦寫一次整整阻塞了大約幾十毫秒。這個(gè)時(shí)間足夠串口硬件FIFO溢出好幾次導(dǎo)致丟幀。后來改成“中斷收數(shù)據(jù)主循環(huán)寫Flash”的模式才徹底解決。第三個(gè)坑比較隱蔽App里的看門狗。如果App程序里開了獨(dú)立看門狗OTA寫Flash期間看門狗沒有被及時(shí)喂狗寫了一半MCU就復(fù)位了。升級(jí)操作雖然還在繼續(xù)但Bootloader可能已經(jīng)收到被剪斷的固件最后CRC校驗(yàn)失敗。這個(gè)問題的處理方式是在進(jìn)入升級(jí)模式之前把看門狗關(guān)掉或者保證Bootloader在OTA期間能夠喂狗。6.3 可靠性的幾個(gè)細(xì)節(jié)補(bǔ)充除了解決問題還有幾個(gè)提升可靠性的細(xì)節(jié)值得加上。Flash操作期間盡量關(guān)掉電源的中斷源尤其是那些有低頻外部中斷的模塊比如RTC鬧鐘、外部按鍵中斷。STM32F103的Flash控制器在擦寫時(shí)如果被頻繁打斷雖然不一定出錯(cuò)但會(huì)降低操作的確定性。升級(jí)包傳輸時(shí)最好做斷點(diǎn)續(xù)傳雖然串口鏈路下實(shí)現(xiàn)起來麻煩但可以從幀序號(hào)下手。Bootloader記錄當(dāng)前已正確寫入的幀號(hào)復(fù)位后從最后一幀重新開始。我實(shí)際項(xiàng)目里的簡化解法是復(fù)位后直接放棄本次升級(jí)等待發(fā)送端重新發(fā)起完整升級(jí)。因?yàn)樯?jí)耗時(shí)也就幾十秒沒必要為了斷點(diǎn)續(xù)傳增加很多復(fù)雜性。最后是量產(chǎn)階段的考慮。產(chǎn)品出貨時(shí)Bootloader和App區(qū)A都要燒錄工廠固件。App區(qū)B可以先留空也可以跟A區(qū)燒一樣的內(nèi)容。留空的做法更干凈因?yàn)锽區(qū)在出廠時(shí)沒有有效標(biāo)志Bootloader不會(huì)引導(dǎo)到空區(qū)。有的團(tuán)隊(duì)為了出廠時(shí)雙備份兩個(gè)區(qū)都燒入固件這樣雖然也可以但要注意首次OTA時(shí)目標(biāo)區(qū)的舊標(biāo)志必須提前清掉。寫在最后的一個(gè)經(jīng)驗(yàn)我在最初做這套AB OTA方案時(shí)花了很多時(shí)間在“跳轉(zhuǎn)代碼怎么寫”上后來發(fā)現(xiàn)跳轉(zhuǎn)反而最簡單真正讓方案穩(wěn)定落地的是那套狀態(tài)機(jī)和異?；謴?fù)邏輯。你現(xiàn)在照著這個(gè)教程復(fù)現(xiàn)如果做完后測試“升級(jí)成功”和“升級(jí)失敗能回滾”兩條鏈路都跑通再去想怎么優(yōu)化就已經(jīng)比很多只做了升級(jí)流程的產(chǎn)品靠譜了。還有一個(gè)小技巧可以后續(xù)擴(kuò)展在AB分區(qū)之外再規(guī)劃一個(gè)1KB的出廠區(qū)存放一個(gè)最小可運(yùn)行固件。日常升級(jí)就算把AB兩個(gè)區(qū)都搞壞了用戶按住某個(gè)按鍵3秒以上Bootloader就會(huì)從出廠區(qū)啟動(dòng)。這個(gè)區(qū)平時(shí)永遠(yuǎn)不參與OTA是徹徹底底的保命后手。做完這套你對(duì)STM32F103的資源掌控和系統(tǒng)可靠性設(shè)計(jì)都會(huì)有跟以前不一樣的體會(huì)。