前幾天整理抽屜翻出一塊吃灰的STM32F103C8T6最小系統(tǒng)板突然想到去年做的一個(gè)很有意思的小項(xiàng)目在這塊不到十塊錢的板子上從零搭出一套完整的AB分區(qū)OTA升級方案。這個(gè)標(biāo)題看起來很技術(shù)其實(shí)拆開就三件事Bootloader怎么寫、App怎么改、上位機(jī)怎么傳。我在踩了一堆坑之后把這個(gè)過程完整復(fù)現(xiàn)了一遍現(xiàn)在把整個(gè)心路歷程和代碼思路整理出來。如果你手里有F103最小系統(tǒng)板會(huì)標(biāo)準(zhǔn)庫開發(fā)又想讓設(shè)備具備升級失敗能自動(dòng)回滾的能力這篇文章應(yīng)該能幫你省下不少試錯(cuò)時(shí)間。很多人可能用過ESP32的OTA那是方案商把一切都封裝好了你只管調(diào)用。但STM32F103上做AB分區(qū)OTA所有邏輯都得自己動(dòng)手寫反而能讓你把OTA的本質(zhì)看得清清楚楚。整個(gè)方案不依賴操作系統(tǒng)不依賴額外芯片就用芯片自帶的內(nèi)部Flash和一組串口能從零開始把Bootloader、雙分區(qū)切換、固件校驗(yàn)、斷點(diǎn)續(xù)傳這些概念逐個(gè)落地。下面我把整個(gè)復(fù)現(xiàn)過程、關(guān)鍵代碼和踩過的坑一次性講透。1. 項(xiàng)目核心拆解AB分區(qū)OTA到底解決什么問題1.1 為什么是STM32F103這個(gè)芯片做OTA的優(yōu)勢選STM32F103作為AB分區(qū)OTA的載體不是因?yàn)樗男阅苡卸鄰?qiáng)而是因?yàn)樗馁Y源結(jié)構(gòu)對OTA學(xué)習(xí)來說剛剛好。C8T6是64KB內(nèi)部Flash20KB SRAMFlash按頁擦除中容量型號每頁1KBRCT6則是256KB Flash每頁2KB。這樣的頁結(jié)構(gòu)非常直觀擦寫邏輯很容易理解不像某些芯片有復(fù)雜的扇區(qū)組合。另外一個(gè)關(guān)鍵點(diǎn)是功耗和成本。F103的價(jià)格低到可以隨便造早期學(xué)習(xí)階段我燒廢過好幾塊板子每次十幾塊錢完全不心疼。它的片上Flash支持1萬次擦寫實(shí)際跑下來通常不止對于搞OTA實(shí)驗(yàn)和日常升級完全夠用。更重要的是F103沒有硬件加密、沒有TrustZone這種情況下做AB分區(qū)所有安全機(jī)制都必須自己設(shè)計(jì)。這個(gè)裸奔的過程反而是最好的學(xué)習(xí)機(jī)會(huì)。等以后切換到帶硬件加密的芯片做車規(guī)級OTA再往里面加簽名驗(yàn)簽也就順理成章了。1.2 AB分區(qū)與傳統(tǒng)方案的區(qū)別一張表看懂傳統(tǒng)的Bootloader加App單分區(qū)方案Flash里只有一個(gè)App區(qū)Bootloader負(fù)責(zé)把新固件下載并寫入這個(gè)區(qū)。這樣做的問題是如果升級過程中途斷電、通信干擾導(dǎo)致寫入損壞或者新固件本身有嚴(yán)重Bug設(shè)備啟動(dòng)后立刻崩潰基本就變磚了必須拿ST-Link重新燒錄。AB雙分區(qū)方案則完全不同。Flash里同時(shí)存在兩個(gè)應(yīng)用分區(qū)分別叫AppA和AppB。Bootloader啟動(dòng)時(shí)只引導(dǎo)兩個(gè)分區(qū)中當(dāng)前標(biāo)記為有效的那一個(gè)。升級時(shí)把新固件寫入非當(dāng)前運(yùn)行的分區(qū)寫入并校驗(yàn)通過后再切換啟動(dòng)目標(biāo)。如果新固件啟動(dòng)后不正常Bootloader還能自動(dòng)回退到另一個(gè)分區(qū)。維度傳統(tǒng)單分區(qū)AB雙分區(qū)Flash占用小需要預(yù)留兩倍應(yīng)用區(qū)升級失敗風(fēng)險(xiǎn)高極易變磚低具備天然回滾能力掉電恢復(fù)需要重新燒錄自動(dòng)切換舊分區(qū)實(shí)現(xiàn)復(fù)雜度低中等遠(yuǎn)程升級安全性弱強(qiáng)這套思路其實(shí)在汽車ECU、智能家電、工業(yè)控制器里很常見Android系統(tǒng)很早就用A/B無縫升級。STM32的Flash資源相對緊張但只要合理規(guī)劃雙分區(qū)完全跑得起來。2. 硬件準(zhǔn)備與Flash分區(qū)規(guī)劃動(dòng)手前先算清楚地址2.1 硬件清單與連接方式先把手頭的硬件理一遍這套項(xiàng)目需要的設(shè)備非常普通STM32F103C8T6最小系統(tǒng)板最好帶板載LED和USB轉(zhuǎn)串口某寶十幾塊錢。一塊ST-Link V2或者任何支持SWD下載的調(diào)試器燒Bootloader和首次燒App用。USB轉(zhuǎn)TTL模塊CP2102或CH340均可如果板子自帶USB轉(zhuǎn)TTL這根線可以省。杜邦線若干。連接方式很簡單USB轉(zhuǎn)TTL的TX接STM32的PA10USART1_RXRX接PA9USART1_TXGND共地。下載器只需要接SWDIO、SWCLK、GND、3V3四根線。我在整個(gè)調(diào)試過程中最常用的是板載USB轉(zhuǎn)串口省了一堆飛線。唯一要注意的是有些板子的USB轉(zhuǎn)串口和STM32的PA9/PA10之間有一個(gè)跳線帽如果發(fā)現(xiàn)串口收不到數(shù)據(jù)先檢查這個(gè)跳線帽有沒有插好。2.2 Flash分區(qū)表和地址計(jì)算動(dòng)手寫代碼之前最重要的一件事就是把Flash分區(qū)表定下來。分區(qū)定不好后面所有地址都會(huì)亂套。STM32F103C8T6的Flash起始地址是0x08000000總?cè)萘?4KB結(jié)束地址0x0800FFFF共64頁每頁1KB。我的分區(qū)表是這么安排的區(qū)域起始地址大小頁范圍Bootloader0x0800000016KB第0~15頁AppA0x0800400022KB第16~37頁AppB0x0800980022KB第38~59頁標(biāo)志區(qū)0x0800F0004KB第60~63頁算一下0x4000 0x5800 0x5800 0x1000 0x10000 64KB正好把整個(gè)Flash占滿沒有浪費(fèi)。Bootloader分配16KB看似奢侈但考慮到后面可能要加串口升級協(xié)議、CRC32校驗(yàn)、甚至日志功能16KB很充裕。App區(qū)給22KB意味著整個(gè)應(yīng)用工程編譯出來的bin文件不能超過22KB。如果你要跑較復(fù)雜的協(xié)議?？梢杂肦CT6或者ZET6加大Flash分區(qū)比例照抄即可。標(biāo)志區(qū)單獨(dú)占最后4KB。為什么單獨(dú)留區(qū)因?yàn)镕lash不能原位修改寫標(biāo)志前必須整頁擦除。把標(biāo)志結(jié)構(gòu)體放在一個(gè)獨(dú)立頁里每次更新都先擦除這頁再寫入邏輯干凈不會(huì)誤傷App代碼。實(shí)際使用中我只用到其中一頁剩余幾頁留著以后做升級日志、版本記錄等擴(kuò)展功能。如果你用的是RCT6256KB Flash可以把分區(qū)調(diào)整成Bootloader 48KB、AppA 96KB、AppB 96KB、標(biāo)志區(qū) 16KB同樣可以做到完全覆蓋。3. Bootloader實(shí)現(xiàn)跳轉(zhuǎn)、擦寫、狀態(tài)機(jī)三大核心3.1 跳轉(zhuǎn)函數(shù)Bootloader最核心的代碼Bootloader的核心任務(wù)之一是能從復(fù)位后引導(dǎo)到AppA或AppB。這部分代碼幾乎每個(gè)做F103升級的人都會(huì)寫但里面有非常多的細(xì)節(jié)坑。先看完整代碼void jump_to_app(uint32_t app_addr) { typedef void (*pFunction)(void); pFunction jump_func; uint32_t app_stack *(volatile uint32_t *)app_addr; if ((app_stack 0xFFF00000) ! 0x20000000) { return; // 棧頂?shù)刂贩欠ㄕf明這個(gè)分區(qū)沒有有效固件 } uint32_t app_reset *(volatile uint32_t *)(app_addr 4); __disable_irq(); SCB-VTOR app_addr; jump_func (pFunction)app_reset; __set_MSP(*(volatile uint32_t *)app_addr); jump_func(); }這里有幾個(gè)理由需要講明白。第一為什么要檢查App起始地址的第一個(gè)32位數(shù)據(jù)因?yàn)镃ortex-M3上電后MSP主棧指針就從Flash起始4字節(jié)加載而App的起始4字節(jié)正好是其棧頂指針。RAM地址范圍在0x20000000到0x20004FFFC8T6是20KB RAM所以一個(gè)合法的棧頂?shù)刂吠ǔ６际?x2000xxxx。用0xFFF00000做掩碼是一個(gè)工程上常見的寬松校驗(yàn)?zāi)苓^濾掉大量因Flash空白或?qū)懭脲e(cuò)亂導(dǎo)致的非法地址。第二為什么要讀App地址加4處的數(shù)據(jù)因?yàn)槟鞘茿pp的Reset_Handler入口地址本質(zhì)上是一個(gè)函數(shù)指針。跳轉(zhuǎn)就是把這個(gè)函數(shù)指針取出來調(diào)用。第三為什么跳轉(zhuǎn)前要設(shè)置SCB-VTOR向量表偏移寄存器決定中斷向量表的位置。App自己跑起來后如果發(fā)生任何中斷CPU都要去向量表找對應(yīng)的中斷處理函數(shù)。不把向量表切到App區(qū)中斷一出現(xiàn)就直接跑飛。第四為什么用__set_MSP因?yàn)槲覀円阎鳁Ｖ羔樓械紸pp的棧頂。如果先調(diào)用函數(shù)再改MSP當(dāng)前函數(shù)棧就亂了。所以標(biāo)準(zhǔn)流程是先把reset地址取到局部變量再用內(nèi)聯(lián)匯編或CMSIS函數(shù)設(shè)置MSP最后直接調(diào)用函數(shù)指針這樣不會(huì)再執(zhí)行Bootloader后面任何代碼。第五__disable_irq(); 這行很多人會(huì)漏掉。如果Bootloader里開了USART中斷跳轉(zhuǎn)到App之前沒關(guān)掉在SCB-VTOR切換的瞬間任何一個(gè)掛起的中斷都可能導(dǎo)致CPU進(jìn)入異常。這個(gè)坑我實(shí)際調(diào)試時(shí)遇到過現(xiàn)象是App啟動(dòng)后隨機(jī)死機(jī)排查了很久才發(fā)現(xiàn)是Bootloader殘留中斷導(dǎo)致。所以跳轉(zhuǎn)前務(wù)必關(guān)中斷然后在App的SystemInit后會(huì)重新開啟自己需要的中斷。3.2 Flash讀寫模塊寫給App數(shù)據(jù)的第一關(guān)OTA接收到的固件最終要寫入內(nèi)部Flash。F103的Flash操作有幾個(gè)硬性規(guī)定寫之前必須擦除整頁擦除操作是按頁進(jìn)行的編程單位是半字16位也就是一次最少寫2個(gè)字節(jié)。標(biāo)準(zhǔn)庫3.5已經(jīng)把這些封裝好了但很多人第一次用還是會(huì)翻車。以C8T6為例頁大小1KB一頁地址范圍是連續(xù)的1KB空間。Flash寫入必須遵循擦除-編程-查驗(yàn)的流程。下面是我在項(xiàng)目中使用的擦除函數(shù)和寫函數(shù)void flash_erase_partition(uint32_t start_addr, uint32_t size) { uint32_t page_count (size 1023) / 1024; uint32_t i; FLASH_Unlock(); FLASH_ClearFlag(FLASH_FLAG_EOP | FLASH_FLAG_PGERR | FLASH_FLAG_WRPRTERR); for (i 0; i page_count; i) { FLASH_ErasePage(start_addr i * 1024); } FLASH_Lock(); } FLASH_Status flash_write_bytes(uint32_t addr, uint8_t *data, uint32_t len) { uint16_t *half_ptr (uint16_t *)data; uint32_t half_count (len 1) / 2; uint32_t i; FLASH_Unlock(); FLASH_ClearFlag(FLASH_FLAG_EOP | FLASH_FLAG_PGERR | FLASH_FLAG_WRPRTERR); for (i 0; i half_count; i) { if (FLASH_ProgramHalfWord(addr i * 2, half_ptr[i]) ! FLASH_COMPLETE) { FLASH_Lock(); return FLASH_BUSY; } } FLASH_Lock(); return FLASH_COMPLETE; }注意幾個(gè)容易出錯(cuò)的地方。第一FLASH_Unlock和FLASH_Lock必須配對而且每做一次擦除或編程操作Standard Peripherals Library要求先ClearFlag否則可能出現(xiàn)誤報(bào)錯(cuò)誤。第二FLASH_ProgramHalfWord的地址必須偶對齊如果傳入的緩沖區(qū)地址不是2字節(jié)對齊的直接強(qiáng)轉(zhuǎn)uint16_t指針可能會(huì)導(dǎo)致HardFault或者產(chǎn)生非對齊訪問。第三數(shù)據(jù)長度如果是奇數(shù)最后一次寫入會(huì)越界1個(gè)字節(jié)這就是我在寫函數(shù)里用(len1)/2計(jì)算半字?jǐn)?shù)并讓調(diào)用方在緩沖區(qū)末尾補(bǔ)0xFF的原因。補(bǔ)0xFF不會(huì)污染數(shù)據(jù)因?yàn)镕lash擦除后本來就是0xFF。有一個(gè)更隱蔽的問題是跨頁寫。如果你的寫函數(shù)只負(fù)責(zé)在某個(gè)地址上寫N個(gè)字節(jié)并不自動(dòng)處理頁邊界那么在OTA固件傳輸時(shí)如果一幀數(shù)據(jù)跨越了兩個(gè)頁的邊界你必須拆分寫入。最簡單的處理方案是設(shè)備端維護(hù)一個(gè)1KB的頁緩存攢滿1KB后一次性擦寫一頁這樣就不會(huì)出現(xiàn)跨頁問題。我實(shí)際使用的OTA接收邏輯就是按這個(gè)思路做的。3.3 AB啟動(dòng)狀態(tài)機(jī)從復(fù)位到跳轉(zhuǎn)的完整流程AB分區(qū)能不能正常工作關(guān)鍵看Bootloader的啟動(dòng)決策邏輯。參考Android的A/B機(jī)制我設(shè)計(jì)了一套精簡狀態(tài)機(jī)把整個(gè)流程固定為以下幾個(gè)步驟Bootloader上電初始化時(shí)鐘、串口、LED。讀取標(biāo)志區(qū)得到當(dāng)前active_slot、兩個(gè)分區(qū)的固件CRC和啟動(dòng)計(jì)數(shù)。進(jìn)入一個(gè)短暫等待窗口默認(rèn)500ms在這期間監(jiān)聽串口升級指令。如果收到升級指令進(jìn)入固件接收模式解析協(xié)議幀寫入非活動(dòng)分區(qū)。如果沒有升級指令則校驗(yàn)active_slot對應(yīng)分區(qū)是否有效。校驗(yàn)通過跳轉(zhuǎn)執(zhí)行該分區(qū)。校驗(yàn)失敗切換到另一個(gè)分區(qū)再次校驗(yàn)。兩個(gè)分區(qū)都無效進(jìn)入錯(cuò)誤處理LED快閃報(bào)錯(cuò)不跳轉(zhuǎn)。標(biāo)志區(qū)結(jié)構(gòu)體我定義成下面這樣typedef struct { uint32_t magic; // 固定為0xA5A5A5A5 uint8_t active_slot; // 0表示AppA1表示AppB uint8_t update_flag; // 0空閑1表示已收到新固件等待重啟切換 uint8_t boot_count; // 當(dāng)前分區(qū)啟動(dòng)計(jì)數(shù)用于看門狗回滾 uint8_t reserved; uint32_t app_a_crc32; uint32_t app_b_crc32; uint32_t header_crc; // 整個(gè)結(jié)構(gòu)體的CRC32 } boot_flags_t;每次需要修改標(biāo)志時(shí)流程都是整頁擦除-寫入新的標(biāo)志結(jié)構(gòu)體-再讀出比對。不能直接往已寫入的Flash地址再寫新值因?yàn)镕lash只能把1寫成0不能把0寫成1。整個(gè)狀態(tài)機(jī)跑起來非常穩(wěn)定。另外我加了一個(gè)簡單的boot_count機(jī)制Bootloader跳轉(zhuǎn)App前先把boot_count加1并寫回標(biāo)志區(qū)App啟動(dòng)成功后會(huì)把boot_count清零。如果App本身崩潰導(dǎo)致系統(tǒng)不斷復(fù)位boot_count會(huì)一直增加超過閾值比如3次后Bootloader判定該分區(qū)不可用自動(dòng)切換分區(qū)并復(fù)位。這相當(dāng)于給AB分區(qū)增加了一道軟件看門狗防線對真實(shí)場景很有價(jià)值。4. App端改造向量表偏移與工程配置4.1 Keil工程配置讓App的編譯地址搬到0x08004000App整個(gè)工程的改動(dòng)非常小但每一項(xiàng)都是致命的。我用的是Keil MDK加標(biāo)準(zhǔn)庫3.5第一步先把工程的IROM1地址改掉。在Options for Target - Target界面里IROM1的Start填0x08004000Size填0x5800這樣鏈接器就會(huì)把所有代碼和只讀數(shù)據(jù)放在0x08004000之后。同理AppB的IROM1 Start改成0x08009800Size也是0x5800。第二步也是新手最容易忽略的是修改向量表偏移。標(biāo)準(zhǔn)庫3.5的system_stm32f10x.c里自帶一段向量表設(shè)置邏輯它默認(rèn)把VECT_TAB_OFFSET定義為0。你可以直接在工程C/C選項(xiàng)卡里的Define一欄加上VECT_TAB_OFFSET0x4000這樣SystemInit執(zhí)行時(shí)SCB-VTOR就會(huì)自動(dòng)變成FLASH_BASE加0x4000也就是0x08004000。這個(gè)方法比我手動(dòng)在main函數(shù)里寫SCB-VTOR要干凈得多也符合官方庫的設(shè)計(jì)思路。第三步檢查啟動(dòng)文件startup_stm32f10x_md.s確認(rèn)中斷向量表前面幾個(gè)向量沒有被人為修改過。正常情況完全不用動(dòng)。用ST-Link把AppA的bin文件燒到0x08004000不是0x08000000上電后Bootloader會(huì)負(fù)責(zé)跳轉(zhuǎn)。如果先燒Bootloader再燒App到指定地址整個(gè)過程是不沖突的。有一點(diǎn)別忘了Bootloader和App雖然是兩個(gè)獨(dú)立工程但都必須使用相同的時(shí)鐘配置。F103默認(rèn)用外部8MHz晶振經(jīng)PLL倍頻到72MHz如果App里故意把主頻設(shè)成48MHzBootloader跳轉(zhuǎn)過去也能跑只是串口波特率、定時(shí)器周期全部都會(huì)偏調(diào)試時(shí)容易一頭霧水。4.2 App端標(biāo)志上報(bào)與升級觸發(fā)讓Bootloader知道我活著AB分區(qū)能夠自動(dòng)回滾依賴的核心概念是當(dāng)前分區(qū)是否啟動(dòng)成功。App啟動(dòng)成功后應(yīng)當(dāng)盡快通知Bootloader。這個(gè)通知?jiǎng)幼髟贏ndroid A/B機(jī)制里叫mark boot successful。在F103上我的實(shí)現(xiàn)方式很直接App進(jìn)入main函數(shù)后先做基礎(chǔ)初始化點(diǎn)亮LED跑2秒自檢如果一切正常就調(diào)用一個(gè)接口把標(biāo)志區(qū)里的boot_count清零。如果App在半路崩了boot_count不會(huì)被清零Bootloader看到計(jì)數(shù)超過閾值就會(huì)自動(dòng)切到另一個(gè)分區(qū)。這套邏輯非常樸素但真實(shí)有效。另一個(gè)思路是用獨(dú)立看門狗IWDG強(qiáng)制回退Bootloader跳轉(zhuǎn)前啟動(dòng)IWDGApp必須在窗口期內(nèi)喂狗否則系統(tǒng)復(fù)位Bootloader發(fā)現(xiàn)boot_count超限切換分區(qū)。這種方式即使App死循環(huán)卡死也能兜住比純軟件標(biāo)志更可靠。App如何觸發(fā)進(jìn)入升級模式同樣寫一個(gè)標(biāo)志。上位機(jī)通過串口給App發(fā)送固定指令例如0x55 0xAA 0x11App收到后把標(biāo)志區(qū)里的update_flag設(shè)為1然后執(zhí)行NVIC_SystemReset()軟復(fù)位。復(fù)位后Bootloader讀取update_flag發(fā)現(xiàn)為1就不跳轉(zhuǎn)直接進(jìn)入固件接收流程。這樣用戶不需要物理按鍵遠(yuǎn)程下發(fā)一條指令就能讓設(shè)備重啟進(jìn)入升級狀態(tài)完全符合真實(shí)OTA場景。5. 固件傳輸協(xié)議設(shè)計(jì)和上位機(jī)對話的規(guī)矩5.1 自定義協(xié)議幀格式與CRC校驗(yàn)STM32的Flash不能像文件系統(tǒng)那樣隨便改寫接收固件時(shí)必須保證每一幀數(shù)據(jù)都正確、不亂序、不丟失。所以我在Bootloader和上位機(jī)之間定義了一個(gè)精簡協(xié)議每一幀固定格式如下字段長度說明幀頭2字節(jié)固定0xAA 0x55幀類型1字節(jié)0x01開始幀0x02數(shù)據(jù)幀0x03結(jié)束幀數(shù)據(jù)區(qū)N字節(jié)不同幀類型攜帶不同參數(shù)CRC162字節(jié)數(shù)據(jù)區(qū)的CRC16幀頭和幀類型不參與開始幀的數(shù)據(jù)區(qū)包含目標(biāo)分區(qū)號1字節(jié)、固件總長度4字節(jié)、固件整體CRC324字節(jié)。數(shù)據(jù)幀的數(shù)據(jù)區(qū)包含幀序號2字節(jié)和最多256字節(jié)的固件數(shù)據(jù)。結(jié)束幀的數(shù)據(jù)區(qū)為空但保留整體CRC字段用于確認(rèn)。CRC16我選用了Modbus CRC16算法網(wǎng)上隨手就能找到查表版速度很快。CRC32則用經(jīng)典的IEEE 802.3多項(xiàng)式作用有兩個(gè)一是上位機(jī)在發(fā)送前整包算一個(gè)CRC放在開始幀里二是Bootloader接收完所有數(shù)據(jù)后對寫入的整個(gè)分區(qū)重新計(jì)算CRC和開始幀聲明的CRC對比一致才把標(biāo)志區(qū)的active_slot切過去。雙保險(xiǎn)設(shè)計(jì)避免每幀都對但整包錯(cuò)的詭異情況。幀序號的作用是讓Bootloader發(fā)現(xiàn)丟幀后能精確請求重傳。我的上位機(jī)邏輯是每發(fā)一幀等ACK收到NAK或者超時(shí)則重發(fā)當(dāng)前幀。Bootloader側(cè)維護(hù)一個(gè)期望序號只有序號匹配的幀才被寫入緩存其他一律返回NAK。這比無腦收數(shù)據(jù)要穩(wěn)得多。5.2 Python上位機(jī)腳本5分鐘寫出一個(gè)升級工具上位機(jī)我直接用Python加pyserial代碼不長但已經(jīng)拿到真實(shí)板子上驗(yàn)證過。核心邏輯就是上面協(xié)議的具體實(shí)現(xiàn)。下面是我項(xiàng)目中使用的核心發(fā)送邏輯import serial import struct import zlib import time def crc16(data): crc 0xFFFF for byte in data: crc ^ byte for _ in range(8): if crc 1: crc (crc 1) ^ 0xA001 else: crc 1 return crc def send_frame(ser, frame_type, payload): frame bytes([0xAA, 0x55, frame_type]) payload crc crc16(payload) frame struct.pack(H, crc) ser.write(frame) time.sleep(0.01) def ota_update(port, bin_path, target_slot, baud115200): with open(bin_path, rb) as f: firmware f.read() ser serial.Serial(port, baud, timeout1) header struct.pack(BI, target_slot, len(firmware)) header struct.pack(I, zlib.crc32(firmware) 0xFFFFFFFF) send_frame(ser, 0x01, header) ack ser.read(1) if ack ! b\x01: print(start transfer rejected) return False seq 0 for offset in range(0, len(firmware), 256): chunk firmware[offset:offset 256] if len(chunk) 256: chunk b\xFF * (256 - len(chunk)) payload struct.pack(H, seq) chunk for retry in range(3): send_frame(ser, 0x02, payload) resp ser.read(1) if resp b\x01: break else: print(frame retry exhausted) return False seq 1 send_frame(ser, 0x03, b) final ser.read(1) if final b\x01: print(OTA done) return True else: print(OTA failed) return False這段腳本有幾個(gè)細(xì)節(jié)值得說明。第一不足256字節(jié)的最后一幀用0xFF補(bǔ)齊正好和Flash擦除后的默認(rèn)值保持一致不會(huì)污染數(shù)據(jù)。第二所有幀都按串口阻塞方式發(fā)送實(shí)際跑115200波特率22KB固件大約2秒傳完非常快。第三上位機(jī)腳本里可以再加進(jìn)度條和錯(cuò)誤統(tǒng)計(jì)但核心鏈路就上面幾行。上位機(jī)腳本在開始幀里自動(dòng)選擇目標(biāo)分區(qū)也非常實(shí)用。最穩(wěn)妥的方式是讓Bootloader在上電后返回當(dāng)前active_slot腳本解析后自動(dòng)選擇另一個(gè)分區(qū)寫入。這樣即使Bootloader多次切換分區(qū)腳本始終不會(huì)寫錯(cuò)地方。6. 從零復(fù)現(xiàn)全流程編譯、燒錄、升級、回滾驗(yàn)證6.1 逐步操作清單從空板到能OTA在正式復(fù)現(xiàn)時(shí)我建議嚴(yán)格按照下面的順序走一遍這樣可以最大程度減少燒完Bootloader但App地址不對之類的混亂情況。先用ST-Link把Bootloader工程燒進(jìn)0x08000000。燒錄時(shí)選擇全片擦除還是只擦除Bootloader區(qū)域都可以我一般選Erase Sectors速度更快。編譯AppA工程。在Keil里配置好IROM1和VECT_TAB_OFFSET之后用User頁的After Build命令生成bin文件。標(biāo)準(zhǔn)寫法是fromelf.exe --bin -o ./Objects/app.bin ./Objects/app.axf用ST-Link把AppA的bin文件下載到0x08004000。如果是用Keil直接下載注意不要選擦除整個(gè)芯片只擦除用到的扇區(qū)。編譯AppB工程。地址改為0x08009800VECT_TAB_OFFSET改為0x9800生成app_b.bin。這次不要用ST-Link下載AppB而是用Python腳本通過串口OTA傳一次驗(yàn)證整個(gè)鏈路通不通。腳本參數(shù)里target_slot寫1因?yàn)楫?dāng)前active_slot是0。串口輸出顯示OTA done之后把板子斷電重新上電觀察Bootloader是否自動(dòng)引導(dǎo)了AppB。再把AppA通過OTA傳回去反復(fù)切換幾次確認(rèn)AB兩個(gè)分區(qū)都在工作。整個(gè)流程跑下來最緊張的其實(shí)不是代碼邏輯而是每次燒錄完第一次上電的那一秒鐘。如果LED正常閃爍心跳踏實(shí)一半如果黑屏接下來就是漫長的排查。用fromelf生成bin文件這一步很多新手會(huì)卡在命令找不到。注意Keil MDK的ARMCC工具鏈里自帶fromelf路徑類似于C:\Keil_v5\ARM\ARMCC\bin。如果你的工程用的ARMClang編譯器fromelf同樣存在只是路徑變成C:\Keil_v5\ARM\ARMCLANG\bin。還有一種更省事的方式直接在Keil的Output頁勾選Create HEX FileBootloader不認(rèn)HEX就轉(zhuǎn)個(gè)格式不過bin文件操作起來更簡單我強(qiáng)烈建議直接生成bin。6.2 回滾場景驗(yàn)證故意整壞一個(gè)分區(qū)OTA方案有沒有效果不能只看升級成功更關(guān)鍵的是看升級失敗時(shí)能不能活下來。有一句話我特別認(rèn)同AB分區(qū)的價(jià)值不體現(xiàn)在平時(shí)而體現(xiàn)在升級失敗的那個(gè)瞬間。我做了兩種故障模擬。第一種人為損壞AppB的分區(qū)頭。用ST-Link的Memory窗口直接往0x08009800寫入全0x00這樣Bootloader讀取AppB棧頂?shù)刂窌r(shí)會(huì)發(fā)現(xiàn)它不在RAM合法范圍內(nèi)判定分區(qū)無效自動(dòng)回退到AppA。實(shí)際效果就是設(shè)備看起來什么都沒發(fā)生繼續(xù)跑著舊固件。這個(gè)動(dòng)作模擬的是寫入固件損壞的最壞情況。第二種讓AppB啟動(dòng)后故意延時(shí)清零標(biāo)志。我在AppB的main函數(shù)里加入一個(gè)3秒延時(shí)在延時(shí)結(jié)束前手動(dòng)斷電再上電。由于boot_count沒有清零Bootloader下次啟動(dòng)時(shí)看到該分區(qū)的boot_count超過閾值自動(dòng)回滾到AppA。這套流程模擬的是新固件能跑但跑一段時(shí)間崩潰的場景。第二種模擬做完我對AB分區(qū)機(jī)制才算真正有了信心。它不再是紙面上的概念而是真真切切能在斷電瞬間保護(hù)設(shè)備的東西。做OTA項(xiàng)目最怕的就是升級失敗后設(shè)備失聯(lián)有了回滾哪怕新固件把自己搞崩了設(shè)備下一次上電依然能回到上一個(gè)穩(wěn)定版本。7. 常見問題與排坑實(shí)錄7.1 問題定位速查表我不是第一次做這類項(xiàng)目時(shí)就一次成功的中間遇到過幾個(gè)典型的坑。下面把常見現(xiàn)象和排查方向整理成一張表供大家直接對照現(xiàn)象可能原因排查與解決方法燒錄App后上電無反應(yīng)App的IROM1地址或VECT_TAB_OFFSET沒改對檢查Target頁面IROM1檢查C/C里是否有VECT_TAB_OFFSET宏跳轉(zhuǎn)后直接HardFault向量表偏移設(shè)置太晚或沒有設(shè)置確認(rèn)App的SystemInit執(zhí)行時(shí)SCB-VTOR已經(jīng)指向App區(qū)域串口收不到Bootloader的升級指令等待窗口太短或者板載USB轉(zhuǎn)TTL跳線帽沒接把等待窗口延長到1秒檢查PA9/PA10與USB轉(zhuǎn)TTL的連通性O(shè)TA傳輸一半卡死幀序號不連續(xù)Bootloader反復(fù)NAK檢查上位機(jī)seq是否按uint16正確遞增查CRC16計(jì)算是否一致升級成功后設(shè)備還是老版本目標(biāo)分區(qū)被固定寫死沒有選擇非活動(dòng)分區(qū)升級前先讀取active_slot動(dòng)態(tài)決定寫入AppA還是AppB第二次升級怎么都失敗第一次升級后活動(dòng)分區(qū)切到B第二次還在寫B(tài)覆蓋了正在運(yùn)行的固件必須寫非活動(dòng)分區(qū)同上一行原因Flash擦寫報(bào)PGERR或WRPRTERR地址越界、Flash被讀保護(hù)、或未按半字對齊寫檢查分區(qū)地址范圍確認(rèn)沒碰Bootloader區(qū)域?qū)懼癠nlock其中最隱蔽的是第二次升級失敗這個(gè)坑。我第一次調(diào)試時(shí)第一次OTA非常順利AppB跑起來了但第二次OTA直接死在半路。后來才發(fā)現(xiàn)我的Bootloader升級邏輯固定寫AppB而當(dāng)前運(yùn)行的是AppB相當(dāng)于邊運(yùn)行邊擦寫自己的代碼區(qū)能成功才怪。正確的AB邏輯永遠(yuǎn)是新固件寫對方的分區(qū)不是自己所在的分區(qū)。7.2 我踩過的幾個(gè)坑一次性說給你聽除了上面表格里的問題還有幾個(gè)小經(jīng)驗(yàn)值得單獨(dú)講。第一個(gè)坑是跳轉(zhuǎn)前的串口中斷殘留。我在Bootloader里開了USART1接收中斷用于檢測升級指令第一次寫完跳轉(zhuǎn)函數(shù)后沒有在跳轉(zhuǎn)前關(guān)中斷。結(jié)果App啟動(dòng)后偶爾會(huì)出現(xiàn)莫名其妙的串口數(shù)據(jù)錯(cuò)亂嚴(yán)重的時(shí)候直接死機(jī)。后來在jump_to_app函數(shù)里加了__disable_irq()問題徹底消失。如果你用的是HAL庫還要注意把UART的DMA、空閑中斷一并停掉。第二個(gè)坑是FLASH_ProgramHalfWord寫入時(shí)緩沖區(qū)對齊。我的OTA接收緩沖區(qū)定義成了一個(gè)uint8_t數(shù)組初始地址是自然對齊的但某些編譯器在結(jié)構(gòu)體嵌套后可能讓指針變得不對齊。一旦用uint16_t指針去訪問非對齊的uint8_t緩沖區(qū)在Cortex-M3上不會(huì)像x86那樣自動(dòng)處理而是直接進(jìn)HardFault。解決辦法是在定義緩沖區(qū)時(shí)用__attribute__((aligned(4)))顯式對齊或者用memcpy拷貝到對齊的臨時(shí)變量再寫入。第三個(gè)坑是外部晶振沒起振導(dǎo)致Bootloader和App頻率不一致。有一次我手頭板子上的8MHz晶振虛焊Bootloader用內(nèi)部HSI跑了跳轉(zhuǎn)到App后App又嘗試用外部HSE結(jié)果整個(gè)系統(tǒng)變慢且串口亂碼。最后發(fā)現(xiàn)是晶振問題換了一塊板子后一切正常。遇到串口波特率不對的情況先查晶振和PLL配置不要急著改上位機(jī)波特率。第四個(gè)坑和Flash頁大小有關(guān)。不同容量的F103頁大小不一樣C8T6是1KB一頁RCT6是2KB一頁。我早期在一份代碼里寫死了1KB擦除后來換到RCT6上跑擦除函數(shù)明顯錯(cuò)亂因?yàn)镕LASH_ErasePage每次實(shí)際擦除的是2KB。如果你的Bootloader要兼容多種容量芯片最好在啟動(dòng)時(shí)根據(jù)芯片型號動(dòng)態(tài)計(jì)算頁大小或者統(tǒng)一用2KB對齊的分區(qū)方案。最后再分享一個(gè)小技巧。我在Bootloader的接收邏輯里加了一個(gè)串口空閑超時(shí)判定當(dāng)連續(xù)50ms沒有收到新數(shù)據(jù)時(shí)認(rèn)為當(dāng)前傳輸結(jié)束。這個(gè)技巧在處理最后一幀不足256字節(jié)時(shí)特別有用不需要額外的結(jié)束標(biāo)記直接在超時(shí)后對緩存數(shù)據(jù)進(jìn)行最后一次Flash寫入即可。實(shí)際調(diào)試節(jié)奏快了很多也少掉了很多協(xié)議狀態(tài)機(jī)的邊界條件。按這套流程完整復(fù)現(xiàn)一遍你會(huì)對STM32的內(nèi)部Flash、Bootloader跳轉(zhuǎn)、AB分區(qū)切換、協(xié)議設(shè)計(jì)都有非常具體的認(rèn)知。以后再去看Android的A/B升級或者汽車ECU的OTA方案腦子里就能浮現(xiàn)出對應(yīng)的硬件行為。如果后續(xù)想把方案做得更安全可以考慮在上位機(jī)和Bootloader之間加入對固件包的簽名用非對稱算法驗(yàn)簽后再寫入這樣即使傳輸通道被監(jiān)聽也無法偽造固件。不過這些都屬于進(jìn)階話題了先把AB分區(qū)這條主鏈路跑通比什么都重要。