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