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