前幾天又遇到一次典型的STM32WB5x BLE OTA卡死問題手機(jī)端顯示固件包傳輸?shù)揭话脒M(jìn)度條不再前進(jìn)設(shè)備側(cè)此時(shí)本來應(yīng)該在收包、寫Flash但就是沒有任何回包。等了幾分鐘手機(jī)端BLE連接超時(shí)斷開之后不管怎么掃描都找不到設(shè)備廣播。重新上電也一樣——好像固件升級(jí)把整臺(tái)設(shè)備送進(jìn)了某個(gè)“黑洞”狀態(tài)。這個(gè)問題的標(biāo)題很直接STM32WB5x BLE OTA gets stuck mid-update with no way to reconnect — is a firmware-side timeout/reset the right approach? 我先說結(jié)論不能用一套簡(jiǎn)單的 timeout reset 邏輯去掃尾但也不能完全不處理。關(guān)鍵是要找到卡在哪個(gè)階段、誰在卡、以及復(fù)位后從哪里啟動(dòng)。這篇文章就圍繞這個(gè)思路把 STM32WB5x 上 BLE OTA 卡死的原因、排查手段、分層超時(shí)設(shè)計(jì)和可落地的復(fù)位策略完整拆開聊。1. 卡死現(xiàn)場(chǎng)從“傳輸中”到“徹底失聯(lián)”的三種表現(xiàn)1.1 下載階段卡住數(shù)據(jù)傳著傳著就沒有ACK了第一種卡死最容易被誤判為“藍(lán)牙斷連”?，F(xiàn)象是手機(jī)APP通過 BLE 自定義服務(wù)向設(shè)備持續(xù)發(fā)送固件分片前面幾十個(gè)包都正常設(shè)備也回了 Write Response 或 Notify ACK在某個(gè)分片之后設(shè)備突然不回任何 Confirm 了。手機(jī)端要么等本次 GATT 寫操作超時(shí)要么等到 BLE 連接事件丟失最終報(bào)錯(cuò)斷開。這種卡在下載階段的問題根源幾乎都不在協(xié)議棧而在 M4 應(yīng)用核。STM32WB5x 的雙核架構(gòu)里M0 核負(fù)責(zé) BLE 協(xié)議棧M4 核負(fù)責(zé)用戶的業(yè)務(wù)代碼。GATT 寫請(qǐng)求來了M0 會(huì)把數(shù)據(jù)通過 IPCC 放進(jìn)共享內(nèi)存然后通知 M4 去取。M4 收到數(shù)據(jù)后要做的是把分片寫入目標(biāo) Flash。如果這段 Flash 寫入邏輯寫得很“霸道”——比如在擦寫整個(gè)扇區(qū)時(shí)長時(shí)間關(guān)中斷或者HAL_FLASH_Program一次寫入后再做 CRC 校驗(yàn)?zāi)敲?M4 處理完這個(gè)分片的時(shí)間可能超過 BLE 的連接間隔M0 側(cè)的 ACK 隊(duì)列就會(huì)越積越多。積壓到一定程度M0 的接收緩沖區(qū)滿協(xié)議棧開始丟棄新的 GATT 寫請(qǐng)求。手機(jī)端發(fā)出去的包沒人應(yīng)答連接事件也會(huì)因?yàn)闆]有及時(shí)交換空包而觸發(fā)鏈路監(jiān)督超時(shí)。此時(shí)設(shè)備并沒有死只是 M4 忙到忘記喂 BLE 協(xié)議?？雌饋砭拖癖豢ㄋ懒?。1.2 安裝階段卡住FUS 一張接管設(shè)備直接消失第二種卡死比下載階段更迷惑人。所有固件分片都傳完了校驗(yàn)也通過了然后 APP 端發(fā)送“開始安裝”的命令設(shè)備收到命令后可能回了一幀 ACK然后連接斷開。此后無論怎么掃描設(shè)備再也不會(huì)廣播。重新上電也一樣設(shè)備仿佛人間蒸發(fā)。如果你用 ST-Link 接上芯片很可能會(huì)發(fā)現(xiàn) M4 還在跑但 M0 停在某個(gè) FUS 服務(wù)里——這時(shí)設(shè)備并不是“壞了”而是進(jìn)入了無線棧固件升級(jí)Wireless Stack Update的安裝流程。STM32WB5x 的 FUSFirmware Upgrade Service運(yùn)行在 M0 核上負(fù)責(zé)安全安裝無線棧固件、管理密鑰等。當(dāng) FUS 開始安裝或者擦寫無線棧區(qū)域時(shí)BLE 協(xié)議棧必然停止運(yùn)行所有無線活動(dòng)都會(huì)終止。這個(gè)階段本來就不應(yīng)該期望還能搜索到設(shè)備。問題在于FUS 安裝完成后可能需要幾秒到幾十秒一旦安裝失敗或 FUS 卡在某個(gè)內(nèi)部狀態(tài)設(shè)備就永遠(yuǎn)停留在“沒有無線?？膳堋钡木置孀匀灰膊粫?huì)有廣播。1.3 復(fù)位后卡住看起來是醒了其實(shí)在裸奔第三種情況出現(xiàn)在“timeout/reset 已經(jīng)寫進(jìn)固件”的設(shè)備上。工程師發(fā)現(xiàn) OTA 卡住后在 M4 側(cè)加了一個(gè)看門狗或者收到“開始安裝”后倒計(jì)時(shí) 10 秒強(qiáng)制NVIC_SystemReset()。結(jié)果是設(shè)備確實(shí)能重啟但重啟后既不廣播、也不進(jìn)入正常應(yīng)用調(diào)試器連上去發(fā)現(xiàn)程序跑飛或死在 HardFault。這通常是復(fù)位后的啟動(dòng)入口出了問題。OTA 過程如果已經(jīng)把新的應(yīng)用固件寫入了當(dāng)前運(yùn)行分區(qū)但復(fù)位后 bootloader 沒有做“鏡像有效性檢查”直接跳轉(zhuǎn)到一個(gè)寫了一半或者 CRC 校驗(yàn)失敗的鏡像CPU 就會(huì)取指失敗卡在啟動(dòng)階段。還有更隱蔽的一種OTA 期間使用獨(dú)立看門狗 IWDG但喂狗邏輯放在主循環(huán)里。當(dāng) M4 阻塞等待 FUS 回復(fù)時(shí)主循環(huán)停擺IWDG 超時(shí)復(fù)位。運(yùn)氣好時(shí)復(fù)位后舊應(yīng)用還在但升級(jí)標(biāo)志被寫壞運(yùn)氣不好正趕上 Flash 擦寫中途復(fù)位導(dǎo)致 Flash 內(nèi)容不完整設(shè)備便再也沒能起來。2. 雙核架構(gòu)下的OTA到底是誰在“卡”誰2.1 先理清 M4、M0 和 FUS 的職責(zé)邊界要處理卡死問題首先得把 STM32WB5x 里的三角關(guān)系搞清楚。M4 核跑應(yīng)用邏輯也就是你寫的產(chǎn)品代碼M0 核跑 BLE 協(xié)議棧對(duì)外呈現(xiàn)為“無線核”。兩個(gè)核通過 IPCC 硬件單元和共享內(nèi)存通信。M4 不需要知道 BLE 連接的底層細(xì)節(jié)它只負(fù)責(zé)從共享內(nèi)存里取數(shù)據(jù)和發(fā)送命令。FUS 是 M0 上的一套系統(tǒng)服務(wù)類似一個(gè)運(yùn)行在無線核上的 mini bootloader。M4 可以通過 IPCC 向 FUS 發(fā)送命令比如查詢版本、安裝無線棧、刪除無線棧、管理安全密鑰等。FUS 有自己的安全狀態(tài)和錯(cuò)誤碼。當(dāng)執(zhí)行覆蓋無線棧區(qū)域的寫操作時(shí)FUS 會(huì)暫停當(dāng)前無線棧運(yùn)行因此 BLE 連接一定會(huì)斷。很多第一次做 STM32WB OTA 的人會(huì)以為“BLE OTA”就是把數(shù)據(jù)寫到 Flash 然后跳轉(zhuǎn)但實(shí)際上要區(qū)分升級(jí)對(duì)象升級(jí)用戶應(yīng)用固件數(shù)據(jù)寫入應(yīng)用分區(qū)通常與 FUS 無關(guān)。升級(jí)無線棧固件必須通過 FUS 或類似機(jī)制不僅要寫 M0 的代碼區(qū)域還要更新藍(lán)牙棧版本和配置。同時(shí)升級(jí)兩者先升級(jí)用戶應(yīng)用再升級(jí)無線?；蚍催^來中間需要明確的狀態(tài)管理。如果沒有做這個(gè)區(qū)分就會(huì)在應(yīng)用 OTA 過程中試圖調(diào)用 FUS或者在無線棧 OTA 過程中關(guān)閉了 FUS導(dǎo)致整個(gè)狀態(tài)機(jī)錯(cuò)亂。2.2 應(yīng)用固件OTA和無線棧OTA是兩條完全不同的路應(yīng)用固件 OTA 通常走雙 Bank 方案當(dāng)前從 Bank1 啟動(dòng)新固件寫入 Bank2寫完后置位切換標(biāo)志復(fù)位后 bootloader 檢查標(biāo)志并嘗試從 Bank2 啟動(dòng)如果 Bank2 無效則自動(dòng)回退 Bank1。這種方式的好處是即使新固件寫壞了Bootloader 還能救回來前提是 Bank1 的舊固件仍然可用。無線棧 OTA 就復(fù)雜一點(diǎn)。無線棧代碼和 FUS 安全性綁定不能由 M4 直接寫入只能讓 FUS 去處理。M4 要做的是把無線棧固件包傳給 FUS再由 FUS 完成校驗(yàn)、擦寫、安裝。這個(gè)過程中 M4 與 FUS 通過 IPCC 異步交互不能一邊等 FUS 一邊又把 BLE 協(xié)議棧殺掉。從調(diào)試角度看應(yīng)用 OTA 卡住大多能在 M4 用戶代碼里找到原因無線棧 OTA 卡住則要優(yōu)先查 FUS 返回的錯(cuò)誤碼和 M0 狀態(tài)。兩者排查手段完全不同所以“一堆 timeout 邏輯走天下”在雙核 OTA 里根本行不通。2.3 “無法重連”的深層原因往往不在BLE超參數(shù)而在于狀態(tài)機(jī)遇到設(shè)備不能重新連接時(shí)很多人的第一反應(yīng)是調(diào) BLE 廣播參數(shù)縮短廣播間隔、打開可發(fā)現(xiàn)模式、延長連接超時(shí)。這些參數(shù)調(diào)整可能有效但治標(biāo)不治本。真正的深層原因往往是沒有把 OTA 狀態(tài)持久化。比如OTA 下載了一半設(shè)備復(fù)位舊應(yīng)用還在但 SFlash 里某個(gè)“升級(jí)進(jìn)行中”的標(biāo)志位被誤寫成了“升級(jí)完成”。新固件寫入 Bank2 后由于復(fù)位發(fā)生在標(biāo)志位寫入之后、CRC 校驗(yàn)完成之前Bootloader 檢查標(biāo)志時(shí)認(rèn)為可以切換結(jié)果跳到損壞的 Bank2。FUS 安裝無線棧時(shí)M4 因?yàn)槌瑫r(shí)執(zhí)行了復(fù)位復(fù)位后 FUS 尚未完成安裝M0 沒有任何可運(yùn)行的無線棧設(shè)備自然無法廣播。這些問題不是靠“多等幾秒”或“多復(fù)位幾次”能解決的。你得有一個(gè)“升級(jí)狀態(tài)機(jī) 啟動(dòng)驗(yàn)證 回退路徑”讓設(shè)備無論什么時(shí)候掉電都能從持久化狀態(tài)里判斷該繼續(xù)升級(jí)、該回退舊版本、還是進(jìn)入恢復(fù)模式。3. 排查套路從復(fù)位原因到FUS狀態(tài)都翻一遍3.1 上ST-Link先看芯片還能不能連上調(diào)試口遇到 OTA 卡死別急著改代碼先把芯片接到 ST-Link打開 STM32CubeProgrammer。如果連接成功你能讀出器件 ID、Flash 大小、當(dāng)前 FUS 版本和無線棧版本。這一步能立刻確認(rèn)設(shè)備是否“活”著以及是哪個(gè)核在跑。如果連接失敗優(yōu)先檢查目標(biāo)板電源以及在 CubeProgrammer 連接設(shè)置里選擇正確的接口模式和復(fù)位模式。有時(shí)設(shè)備運(yùn)行在不正常狀態(tài)需要把 BOOT0 拉高進(jìn)入系統(tǒng) Bootloader 再連接。不過 STM32WB5x 的內(nèi)部 Bootloader 走的是 USART/USB不是 SWD所以如果 SWD 連不上通常說明芯片內(nèi)部時(shí)鐘或電源出了大問題或者調(diào)試引腳被 M4 代碼復(fù)用并配置成了模擬輸入。3.2 第二眼看RCC_CSR這臺(tái)設(shè)備是“怎么死的”如果 SWD 能連上下一步我會(huì)讀取復(fù)位原因寄存器RCC_CSR。這個(gè)寄存器能告訴你最后一次復(fù)位是由誰觸發(fā)的上電復(fù)位 / 欠壓復(fù)位外部復(fù)位引腳獨(dú)立看門狗 IWDG 復(fù)位窗口看門狗 WWDG 復(fù)位軟件復(fù)位 NVIC_SystemReset其他原因在項(xiàng)目里用一個(gè)調(diào)試命令把復(fù)位原因打印出來會(huì)非常有價(jià)值。比如你發(fā)現(xiàn)設(shè)備每次 OTA 卡死后的復(fù)位原因是 IWDG那說明問題出在“沒有及時(shí)喂狗”如果復(fù)位原因是軟件復(fù)位說明你的超時(shí)邏輯真的執(zhí)行了NVIC_SystemReset()但顯然它沒有解決問題。讀取代碼如下uint32_t csr RCC-CSR; if (csr RCC_CSR_RMVF_Msk) { RCC-CSR | RCC_CSR_RMVF_Msk; // 清除復(fù)位標(biāo)志 } // 判斷 if (csr RCC_CSR_WDGRSTF_Msk) { // IWDG復(fù)位 } else if (csr RCC_CSR_SFTRSTF_Msk) { // 軟件復(fù)位 }我在實(shí)際項(xiàng)目中遇到過很隱蔽的情況設(shè)備上電后RCC_CSR里的 IWDG 復(fù)位標(biāo)志一直存在而代碼里沒有在啟動(dòng)早期清除它導(dǎo)致 Bootloader 以為上一次 OTA 異常退出不斷觸發(fā)回滾。這種“歷史復(fù)位原因”沒有清理干凈也會(huì)造成奇怪的啟動(dòng)行為。3.3 第三步翻FUS狀態(tài)和無線棧版本STM32CubeProgrammer 有一個(gè)專門的 FUS 頁面打開后能直接看到 FUS 版本、無線棧版本、當(dāng)前運(yùn)行的安全狀態(tài)以及上一次 FUS 命令的執(zhí)行狀態(tài)。如果上位機(jī)顯示無線棧區(qū)域?yàn)榭栈蛘?FUS 狀態(tài)不是 Running那基本可以判斷設(shè)備是卡在無線棧升級(jí)的安裝階段。此時(shí)你要么重新通過腳本刷入一套完整的無線棧固件要么用 Flash 全擦除后重建。注意STM32WB5x 的無線棧區(qū)域有安全校驗(yàn)單純?cè)?MDK 里隨便寫一個(gè)地址是沒用的必須走 FUS 或官方工具鏈。在自定義 OTA 流程中我建議把 FUS 命令的返回碼納入日志系統(tǒng)。比如FUS_ERROR_IMG_NOT_AUTHENTICATED固件包簽名校驗(yàn)失敗。FUS_ERROR_OP_ABORTED操作被中斷。FUS_ERROR_NO_DEVICE_ACCESSM4 沒有對(duì)應(yīng)權(quán)限。這些錯(cuò)誤碼能幫你判斷問題出在 OTA 包的合法性還是出在 FUS 命令交互流程。3.4 如果連SWD都連不上優(yōu)先懷疑Flash被寫花假設(shè)設(shè)備徹底沒反應(yīng)SWD 也連不上這時(shí)不要上來就懷疑芯片壞了。先強(qiáng)制進(jìn)入系統(tǒng) Bootloader把調(diào)試口重新救出來。如果 STM32CubeProgrammer 能連接系統(tǒng) Bootloader再對(duì) Flash 做整片擦除擦除后一般都能通過 SWD 重新連接。這種情況多發(fā)生在 FUS 安裝過程中被 M4 側(cè)硬復(fù)位打斷。雖然 STM32WB5x 在 Flash 擦寫上做了一些保護(hù)但復(fù)位發(fā)生在閃存編程時(shí)序中間仍可能導(dǎo)致無線棧區(qū)域處于不穩(wěn)定狀態(tài)。而一旦無線棧區(qū)域內(nèi)容損壞M0 無法啟動(dòng)協(xié)議棧整顆芯片就表現(xiàn)為“BLE 完全消失”但 M4 可能還在空轉(zhuǎn)。所以從設(shè)計(jì)層面講任何可能中斷 Flash 編程的操作都必須格外小心。尤其是無線棧升級(jí)期間不是萬不得已不要用 M4 側(cè)看門狗去打斷 FUS 流程。4. 固件側(cè)timeout/reset能解決什么不能解決什么4.1 超時(shí)機(jī)制的正確分層傳輸層、安裝層、啟動(dòng)層回到標(biāo)題里的問題firmware-side timeout/reset 到底是不是正確方案我的答案是timeout 是必須的但 reset 要分級(jí)、分層不能一把梭。可以把整個(gè) OTA 流程分成三個(gè)層次層次典型超時(shí)場(chǎng)景正確處理方式是否建議直接復(fù)位傳輸層長時(shí)間沒有收到下一個(gè)固件分片中止本次下載保持廣播等待重連通常不需要復(fù)位安裝層FUS 安裝無線棧超時(shí)查詢 FUS 狀態(tài)記錄錯(cuò)誤再?zèng)Q定復(fù)位謹(jǐn)慎需先保護(hù)標(biāo)志啟動(dòng)層Bootloader 檢測(cè)到鏡像無效回退到上一分區(qū)或進(jìn)入恢復(fù)模式通過跳轉(zhuǎn)邏輯完成不屬于普通復(fù)位4.2 傳輸層超時(shí)該中止但不該急著復(fù)位傳輸層的超時(shí)最簡(jiǎn)單。M4 收到固件分片后維護(hù)一個(gè)last_rx_tick。如果超過某個(gè)閾值比如 5 秒沒有收到新的分片就認(rèn)為本次傳輸已經(jīng)失敗。此時(shí)正確的做法是把 OTA 狀態(tài)機(jī)切到OTA_STATE_FAILED。記錄失敗的偏移量和錯(cuò)誤碼。釋放本次 OTA 占用的緩存。判斷當(dāng)前正在運(yùn)行的應(yīng)用是否有效如果有效繼續(xù)跑舊應(yīng)用同時(shí)繼續(xù)保持 BLE 可連接。如果舊應(yīng)用已經(jīng)被部分覆蓋比如采用了單 Bank 原地升級(jí)則應(yīng)讓設(shè)備停留在“可發(fā)現(xiàn)且可重新下載”的狀態(tài)等待手機(jī)端重連后重新把完整固件包傳一遍。為什么不要立即復(fù)位因?yàn)閭鬏攲映瑫r(shí)往往只是手機(jī)空中的射頻干擾、BLE 連接參數(shù)不匹配、或手機(jī)端 APP 異常此時(shí)設(shè)備本身沒有掛。你復(fù)位自己反而會(huì)讓手機(jī)端徹底丟掉連接不復(fù)位至少手機(jī)端還能通過當(dāng)前連接繼續(xù)補(bǔ)發(fā)幾包。我在實(shí)測(cè)中發(fā)現(xiàn)BLE OTA 傳文件時(shí)如果手機(jī)屏幕熄滅或系統(tǒng)進(jìn)入省電模式連接會(huì)進(jìn)入 dormant 狀態(tài)幾秒鐘沒有數(shù)據(jù)是很正常的。把傳輸超時(shí)設(shè)成 2 秒會(huì)誤傷設(shè)成 10 秒又會(huì)讓卡死恢復(fù)太慢。一般建議根據(jù)實(shí)際數(shù)據(jù)包間隔設(shè)置比如你的 APP 每 20ms 發(fā)一包可以設(shè) 2 秒如果每 100ms 發(fā)一包可以設(shè) 4~5 秒。4.3 安裝層超時(shí)需要“先確認(rèn)狀態(tài)再?zèng)Q定是否復(fù)位”安裝層指的就是“固件傳輸完成開始擦寫/切換”這個(gè)階段。如果是應(yīng)用固件雙 Bank 切換整個(gè)過程很短M4 直接操作 Flash超時(shí)主要關(guān)注擦寫時(shí)間是否異常。如果是 FUS 安裝無線棧過程可能跨越數(shù)秒到幾十秒此時(shí) M4 與 FUS 基于 IPCC 異步交互。這個(gè)階段最忌諱的就是“M4 等不到回復(fù)后直接調(diào)用NVIC_SystemReset()”。為什么因?yàn)?FUS 可能在擦寫無線棧 Flash此時(shí)硬復(fù)位可能會(huì)打斷 FUS 的擦寫流程。STM32WB5x 的 FUS 內(nèi)部有一定恢復(fù)機(jī)制但你在錯(cuò)誤的時(shí)間點(diǎn)打斷它可能讓無線棧區(qū)域處于“存在但校驗(yàn)失敗”的狀態(tài)。與其這樣不如在進(jìn)入安裝前就設(shè)計(jì)好先通過 FUS 查詢當(dāng)前狀態(tài)如果 FUS 還活著讓它繼續(xù)跑或者主動(dòng)發(fā)送一個(gè)放棄命令。如果查詢 FUS 也得不到響應(yīng)才考慮復(fù)位并且復(fù)位后要檢查無線棧版本和 FUS 錯(cuò)誤碼決定是否進(jìn)入“恢復(fù)模式”。4.4 啟動(dòng)層回退把最后一道防線放在bootloaderOTA 中最重要的一道防線不是“超時(shí)復(fù)位”而是“啟動(dòng)時(shí)驗(yàn)證”。無論你采用雙 Bank 還是單 BankBootloader 都要在跳轉(zhuǎn)到應(yīng)用之前驗(yàn)證目標(biāo)鏡像的有效性。STM32WB5x 的雙 Bank 結(jié)構(gòu)非常適合做 A/B 升級(jí)。你可以在 Bootloader 里做以下檢查讀取用戶分區(qū)頭部的鏡像 CRC 或簽名。如果 CRC 有效正常跳轉(zhuǎn)。如果 CRC 無效檢查另一個(gè) Bank 的 CRC。如果另一個(gè) Bank 有效切換啟動(dòng)。如果兩個(gè) Bank 都無效進(jìn)入串口或 BLE 恢復(fù)模式。我在項(xiàng)目里把這條規(guī)則固化為“啟動(dòng)鏈”Bootloader - App A / App B。OTA 寫入只寫非運(yùn)行 Bank寫完置位 “pending” 標(biāo)志復(fù)位后 Bootloader 根據(jù)標(biāo)志和校驗(yàn)結(jié)果決定正式切換還是回滾。這樣一來即使安裝階段復(fù)位時(shí)機(jī)不對(duì)只要舊 Bank 還完整設(shè)備至少能回到舊版本而不是“徹底失聯(lián)”?；赝藱C(jī)制雖然不能替代超時(shí)復(fù)位但它能在超時(shí)復(fù)位做錯(cuò)時(shí)兜底。很多“OTA 卡死無法重連”的最終原因其實(shí)是 Bootloader 沒有做鏡像有效性檢查啟動(dòng)鏈斷了。5. 一套可以落地的OTA超時(shí)復(fù)位參考設(shè)計(jì)5.1 狀態(tài)標(biāo)志和數(shù)據(jù)布局先行在設(shè)計(jì) OTA 邏輯之前先確定狀態(tài)標(biāo)志放在哪。ST 官方的雙 Bank 方案一般會(huì)使用幾個(gè) Flash 字或 Option Byte 作為升級(jí)標(biāo)志。由于 Flash 寫入要擦除不建議頻繁修改同一個(gè)字。更穩(wěn)妥的做法是用一個(gè)獨(dú)立的配置扇區(qū)專門保存 OTA 狀態(tài)。一個(gè)簡(jiǎn)單的狀態(tài)結(jié)構(gòu)體大概長這樣typedef struct { uint32_t magic; uint32_t ota_state; // 0: idle, 1: transferring, 2: pending_switch, 3: failure uint32_t transfer_offset; uint32_t target_bank; // 目標(biāo)啟動(dòng)區(qū)域 uint32_t last_error_code; uint32_t crc32_of_struct; } OtaPersistentStatus;每次更新狀態(tài)后先計(jì)算整個(gè)結(jié)構(gòu)體的 CRC32再寫入保存區(qū)。Bootloader 啟動(dòng)時(shí)先檢查 magic 和 CRC32如果校驗(yàn)失敗就認(rèn)為狀態(tài)不可信強(qiáng)制走安全啟動(dòng)路徑。別小看這一步很多 OTA 卡死就是狀態(tài)標(biāo)志半寫半不寫造成的。5.2 傳輸超時(shí)的計(jì)算和喂狗節(jié)奏傳輸超時(shí)不能拍腦袋定。先量一下你的 BLE 連接實(shí)際帶寬手機(jī)端每隔多少毫秒收到一個(gè) Write Response如果平均間隔是 30ms那 3 秒內(nèi)沒有任何包就說明鏈路已經(jīng)斷了或者對(duì)端已經(jīng)放棄。設(shè)計(jì)喂狗時(shí)也要注意喂狗不能放在while(1)主循環(huán)里因?yàn)?OTA 接收數(shù)據(jù)時(shí)主循環(huán)可能長時(shí)間阻塞。更好的做法是“事件驅(qū)動(dòng) 后臺(tái)任務(wù)輪詢”void OTA_BleOnWrite(uint8_t *pData, uint16_t len) { // 接收更多數(shù)據(jù) OTA_Context.rx_data_happened true; OTA_Context.last_rx_tick HAL_GetTick(); // 寫Flash或者緩存 } void App_MainLoop(void) { uint32_t now HAL_GetTick(); if (OTA_Context.state OTA_STATE_TRANSFERRING) { if (now - OTA_Context.last_rx_tick OTA_TRANSFER_TIMEOUT_MS) { OTA_AbortTransfer(); } } // 其他任務(wù) HAL_IWDG_Refresh(hiwdg); // 不要在Flash擦寫期間長時(shí)間不進(jìn)這里 }如果在接收回調(diào)里直接寫 Flash而且 Flash 擦寫時(shí)間比較長要注意在擦寫前開一個(gè)足夠?qū)捜莸目撮T狗窗口?；蛘吒纱喟呀邮站彌_做深一點(diǎn)數(shù)據(jù)先放進(jìn) RAM后臺(tái)慢慢寫 Flash。這樣 BLE 協(xié)議棧能更及時(shí)地回 ACK連接不容易斷。我在實(shí)測(cè)中比較推薦“RAM 緩沖 后臺(tái) Flash 寫入”的模式。每次 BLE 收滿一個(gè)扇區(qū)大小的數(shù)據(jù)就把數(shù)據(jù)優(yōu)先緩存到內(nèi)部 SRAM 或外部 PSRAM然后在主循環(huán)的批量寫入階段統(tǒng)一寫 Flash。缺點(diǎn)是占用 RAM但能極大降低傳輸層卡死的概率。5.3 安裝階段復(fù)位策略的偽代碼思路當(dāng)所有固件包接收完成進(jìn)入安裝階段時(shí)我會(huì)把流程拆成三步void OTA_StartInstall(void) { // 1. 持久化狀態(tài)進(jìn)入 install 階段 OTA_SaveStatus(OTA_STATE_INSTALLING, target_bank); // 2. 等待FUS或Flash切換完成 uint32_t timeout HAL_GetTick() OTA_INSTALL_TIMEOUT_MS; while (HAL_GetTick() timeout) { HAL_IWDG_Refresh(hiwdg); // 對(duì)FUS安裝流程輪詢FUS查詢命令 FUS_Status_t st FUS_QueryStatus(); if (st FUS_STATUS_READY) { OTA_SaveStatus(OTA_STATE_COMPLETED, target_bank); return; } if (st FUS_STATUS_ERROR) { OTA_HandleFusError(st); return; } } // 3. 超時(shí)處理先記錄錯(cuò)誤再考慮復(fù)位 OTA_SaveStatus(OTA_STATE_FAILURE, OTA_GetCurrentBank()); NVIC_SystemReset(); }注意第 3 步的復(fù)位不是首選項(xiàng)。如果 FUS 查詢命令能響應(yīng)我寧可用 FUS 命令去中止或確認(rèn)而不是直接系統(tǒng)復(fù)位。只有 FUS 已經(jīng)無響應(yīng)、且確認(rèn)繼續(xù)等下去沒有任何進(jìn)展時(shí)才執(zhí)行復(fù)位。復(fù)位后用 Bootloader 的鏡像校驗(yàn)來兜底。5.4 實(shí)測(cè)驗(yàn)證哪些方案能“救回來”哪些會(huì)“越救越死”我實(shí)際測(cè)試過三種策略結(jié)果差別很大策略 A傳輸層超時(shí)后立即NVIC_SystemReset()。結(jié)果設(shè)備重啟后能起來但如果 OTA 有大量緩存沒有落盤導(dǎo)致寫了一半Bootloader 沒有回退邏輯設(shè)備卡死。越救越死。策略 B傳輸層超時(shí)后中止升級(jí)但保持廣告等待重連。結(jié)果設(shè)備能重新被發(fā)現(xiàn)手機(jī)端重新連接后可以重新傳輸雖然浪費(fèi)時(shí)間但可靠。策略 CFUS 安裝階段從HAL_GetTick()到 30 秒超時(shí)后硬復(fù)位。結(jié)果有幾次設(shè)備能恢復(fù)正常有幾次無線棧區(qū)域被寫壞需要用 ST-Link 全擦后重刷。風(fēng)險(xiǎn)很高。綜合來看最可靠的設(shè)計(jì)是傳輸層盡量不重啟安裝層盡量不硬復(fù)位啟動(dòng)層盡量依賴 Bootloader 自動(dòng)回退。6. 幾個(gè)關(guān)鍵決策和給后來者的建議回到最開始的問題firmware-side timeout/reset 是不是正確做法我的看法是timeout 必須放在 OTA 的每一層但 reset 是最后手段不能放在傳輸層“每等不到回包就復(fù)位”。正確姿勢(shì)是把 OTA 設(shè)計(jì)成狀態(tài)機(jī)每個(gè)狀態(tài)都有明確的超時(shí)行為、持久化標(biāo)志和恢復(fù)路徑。復(fù)位只是所有恢復(fù)路徑都不生效時(shí)的最終兜底。我在實(shí)際項(xiàng)目里踩過坑尤其建議注意這幾點(diǎn)第一不要讓 M4 在等待 FUS 回復(fù)時(shí)完全阻塞。哪怕是一個(gè) 5ms 的HAL_Delay也要保證主循環(huán)仍然能喂狗、能處理其他后臺(tái)任務(wù)。第二復(fù)位之前一定要保存錯(cuò)誤信息。你可以把last_error_code和ota_state寫到備份寄存器或者 Flash 的專用區(qū)域這樣復(fù)位后可以通過日志直接看到“上次是為什么復(fù)位”。沒有這一步你只能靠猜。第三升級(jí)無線棧之前先確認(rèn)當(dāng)前 FUS 版本和無線棧版本確保無線棧固件包與 FUS 兼容。版本不匹配導(dǎo)致 FUS 安裝失敗的情況比硬件問題常見得多。使用官方 OTA 例程時(shí)也要看清示例中給的無線棧版本不要隨手拿別的版本刷進(jìn)去。最后再分享一個(gè)排查技巧OTA 卡死時(shí)用 STM32CubeMonitor 或一個(gè)簡(jiǎn)單的串口日志把 M4 側(cè)收到的 BLE 數(shù)據(jù)字節(jié)數(shù)和 FUS 返回的每一條命令狀態(tài)都記錄下來。我靠這招定位過很多“看起來像玄學(xué)”的升級(jí)失敗——其實(shí)只是某個(gè)包在傳輸層丟了但上層一直沒等回來。把日志打印到 Flash 尾巴上掉電也不丟。這樣即使設(shè)備徹底失聯(lián)接上 ST-Link 還能從 Flash 里把最后的現(xiàn)場(chǎng)數(shù)據(jù)讀出來比盲猜高效得多。