做過帶片外Flash的OTA升級的朋友應(yīng)該都有體會Bootloader、App、下載區(qū)、備份區(qū)再多一個W25Q128這類SPI NOR Flash整個分區(qū)和升級流程一下就復(fù)雜起來。RT-Thread Studio自帶的YModem例程默認用的是片內(nèi)Flash一旦固件超過片內(nèi)容量或者你想把下載區(qū)放到外部Flash來節(jié)省內(nèi)部空間就必須自己動手改造。這篇筆記就是記錄我在STM32F411平臺上基于RT-Thread Studio用W25Q128做下載分區(qū)、走YModem協(xié)議完成OTA升級的完整過程和踩坑記錄。先說結(jié)論這套方案做出來的效果非常穩(wěn)定。Bootloader放在片內(nèi)Flash開頭App放在片內(nèi)Flash后續(xù)區(qū)域兩個App備份區(qū)和一個下載區(qū)放在W25Q128里通過YModem把固件先傳到外部Flash再搬運到App分區(qū)執(zhí)行。整個思路不復(fù)雜但細節(jié)很多尤其是分區(qū)表規(guī)劃、FAL抽象層的配置、以及YModem傳輸完成后的校驗和搬運邏輯每一步都容易出問題。這篇文章適合正在用RT-Thread做產(chǎn)品、需要OTA能力或者被片內(nèi)Flash容量逼到必須外掛Flash的開發(fā)者參考。1. 整體方案設(shè)計與分區(qū)規(guī)劃1.1 為什么要把下載區(qū)放在片外FlashSTM32F411的片內(nèi)Flash通常是512KB或1MB如果固件本身就有兩三百KB片內(nèi)空間其實很緊張。OTA升級至少要兩個區(qū)一個跑當前固件的App區(qū)一個臨時存放新固件的下載區(qū)。如果這兩個區(qū)都放在片內(nèi)512KB的芯片基本就沒法用了。把下載區(qū)放到外部W25Q128是個非常合理的折中方案W25Q128有16MB空間存固件綽綽有余而片內(nèi)Flash只需要留給Bootloader和App本身。還有一層考慮是安全性和穩(wěn)定性。YModem走串口傳輸波特率通常115200一個300KB的固件大概要傳30秒左右這期間如果斷電最多損壞下載區(qū)跑在片內(nèi)Flash里的正式固件完全不受影響。等到整個固件包接收完整、校驗通過之后才一次性搬運到App區(qū)。這個“先緩存、后搬運”的設(shè)計能最大程度避免升級失敗變磚的風險。1.2 方案選型為什么選YModem而不是XModem或自定義協(xié)議YModem在嵌入式領(lǐng)域之所以經(jīng)久不衰核心原因是它解決了XModem最大的痛點文件名和文件大小傳輸。XModem只傳裸數(shù)據(jù)接收端根本不知道這次收到的固件是誰、多大、版本多少。YModem在起始階段會先傳一個包含文件名和大小信息的數(shù)據(jù)包接收端可以在校驗前就把這些元數(shù)據(jù)解析出來做版本判斷避免傳了一半才發(fā)現(xiàn)版本不對的尷尬。而且YModem的“逐個文件批量傳輸”能力也很實用。雖說OTA一般一次只傳一個固件但有時候你需要在同一次升級里同時更新Bootloader和App這時候YModem可以順序傳兩個文件接收端按順序?qū)懭氩煌謪^(qū)就行。這套機制成熟、實現(xiàn)簡單、工具鏈齊全——PC端隨便一個SecureCRT或者ExtraPuTTY都原生支持YModem不需要額外開發(fā)上位機這也是我選它的一個重要原因。1.3 分區(qū)規(guī)劃片內(nèi)和片外各管哪一塊分區(qū)規(guī)劃是整個OTA方案的基石我強烈建議在一張紙上先畫清楚再寫代碼。我的布局是這樣的區(qū)域存儲介質(zhì)起始地址大小用途Bootloader片內(nèi)Flash0x0800000064KB引導(dǎo)、YModem接收、固件搬運App區(qū)片內(nèi)Flash0x08010000448KB當前運行的應(yīng)用程序下載區(qū)W25Q1280x000000001MB暫存YModem上傳的新固件備份區(qū)AW25Q1280x001000001MB預(yù)留用于App備份或雙備份升級備份區(qū)BW25Q1280x002000001MB預(yù)留用于App備份或雙備份升級這里有幾個關(guān)鍵點要解釋一下。Bootloader給64KB是保守的RT-Thread最小配置跑YModem大概在40-50KB左右留64KB是給自己加日志和調(diào)試功能留余地。App區(qū)從0x08010000開始意味著App的鏈接腳本里ROM起始地址必須是這個值不能錯。片外Flash的1MB下載區(qū)看起來很大其實是為了支持將來更大固件預(yù)留的W25Q128一共16MB用1MB完全沒壓力。提示片內(nèi)Flash的扇區(qū)大小因芯片而異STM32F411是128KB一個扇區(qū)。Bootloader占64KB意味著它只占半個物理扇區(qū)所以App區(qū)起始地址必須是128KB對齊否則扇區(qū)擦除會把Bootloader尾部擦掉。這一點務(wù)必檢查芯片參考手冊。2. RT-Thread Studio工程配置與W25Q128驅(qū)動接入2.1 創(chuàng)建工程與使能必要組件在RT-Thread Studio里新建一個基于STM32F411的裸機工程然后在RT-Thread Settings里勾選需要的組件。我這邊的清單是內(nèi)核必選、FALFlash抽象層、SFUD串行Flash通用驅(qū)動、YModem在FinSH組件里、OTART-Thread的OTA組件。有個容易漏掉的地方是YModem組件依賴POSIX層的文件操作接口所以還要在組件配置里打開libc和posix相關(guān)的選項否則編譯會報一堆open、read、close未定義的錯。FAL和SFUD這兩個組件是配合使用的。SFUD負責把W25Q128初始化為一個塊設(shè)備FAL負責把這個塊設(shè)備按起始地址和大小切成邏輯分區(qū)。在RT-Thread Studio的配置界面里FAL可以配置分區(qū)表我上面那張表就是填在這里的。配置完成后fal probe命令能直接看到所有分區(qū)。2.2 W25Q128接線與驅(qū)動配置W25Q128是標準的SPI NOR Flash四線制CS、CLK、MOSI、MISO。我在F411開發(fā)板上用的是SPI1引腳分配是PA5接CLKPA6接MISOPA7接MOSIPA4接CS。這個接法比較常規(guī)如果你的板子引腳不同記得在Board Configuration里改。SFUD對W25Q128的支持非常完善型號直接在它內(nèi)置的Flash設(shè)備表里。所以驅(qū)動這塊基本不用寫代碼關(guān)鍵是SPI設(shè)備的初始化要在應(yīng)用代碼里手動調(diào)用。我之前犯過一個低級錯誤只勾選了SPI驅(qū)動和SFUD但沒在代碼里rt_hw_spi_device_attach把CS引腳和SPI總線綁定結(jié)果SFUD一直枚舉不到Flash設(shè)備。#include rtthread.h #include spi.h #include sfud.h #include drv_spi.h static int spi_flash_init(void) { /* 將SPI1總線上掛載的W25Q128設(shè)備片選為SPI1_CS_1 */ rt_hw_spi_device_attach(spi1, spi10, GPIOA, GPIO_PIN_4); /* 使用SFUD探測并注冊 */ if (rt_sfud_flash_probe(w25q128, spi10) RT_NULL) { rt_kprintf(W25Q128 probe failed.\n); return -RT_ERROR; } return RT_EOK; } INIT_APP_EXPORT(spi_flash_init);rt_hw_spi_device_attach的最后一個參數(shù)是CS引腳我用的GPIOA的Pin4。rt_sfud_flash_probe執(zhí)行完之后FAL就能看到這個Flash塊設(shè)備了。運行sfud probe spi10命令如果能正確打印出W25Q128的型號和容量說明驅(qū)動這一層已經(jīng)通了。2.3 FAL分區(qū)表配置的坑FAL分區(qū)表在RT-Thread Studio里有兩種配置方式一種是圖形化界面里直接填另一種是在fal_cfg.h里手寫。我建議用fal_cfg.h手寫理由很簡單圖形界面生成的代碼有時候分區(qū)起始地址會意外被修改而且版本管理的時候手寫文件更容易diff。#ifndef _FAL_CFG_H_ #define _FAL_CFG_H_ #include rtconfig.h #include board.h #define NOR_FLASH_DEV_NAME w25q128 /* Flash設(shè)備表 */ extern struct fal_flash_dev nor_flash0; extern struct fal_flash_dev stm32f4_onchip_flash; /* Flash設(shè)備表 */ #define FAL_FLASH_DEV_TABLE \ { \ stm32f4_onchip_flash, \ nor_flash0, \ } /* 分區(qū)表 */ #define FAL_PART_TABLE \ { \ {FAL_PART_MAGIC_WORD, bootloader, stm32f4_onchip_flash, 0, 64*1024, 0}, \ {FAL_PART_MAGIC_WORD, app, stm32f4_onchip_flash, 64*1024, 448*1024, 0}, \ {FAL_PART_MAGIC_WORD, download, nor_flash0, 0, 1024*1024, 0}, \ {FAL_PART_MAGIC_WORD, backup_a, nor_flash0, 1024*1024, 1024*1024, 0}, \ {FAL_PART_MAGIC_WORD, backup_b, nor_flash0, 2048*1024, 1024*1024, 0}, \ } #endif /* _FAL_CFG_H_ */這里有個特別容易踩的坑stm32f4_onchip_flash這個設(shè)備在FAL里默認的起始地址是0x08000000大小是芯片的全部Flash。如果分區(qū)表里bootloader的起始地址填0FAL會自動映射到0x08000000這是對的。但App分區(qū)的地址必須自己算好64KB偏移對應(yīng)的是0x08010000這在代碼里隱含在了“64*1024”這個偏移量里所以App鏈接腳本里的ROM地址也必須和這個偏移嚴格一致。3. YModem協(xié)議與OTA組件的工作機制3.1 YModem協(xié)議關(guān)鍵細節(jié)回顧YModem協(xié)議看著簡單實際寫代碼的時候坑不少。它的基本流程是發(fā)送方先發(fā)一個包含文件名和文件大小的數(shù)據(jù)包133字節(jié)128字節(jié)數(shù)據(jù)加5字節(jié)頭接收方確認后發(fā)送方再按128字節(jié)或1024字節(jié)的分塊發(fā)送文件數(shù)據(jù)。全部發(fā)完后發(fā)送方發(fā)一個結(jié)束包接收方回應(yīng)ACK整個傳輸結(jié)束。在嵌入式端最容易出問題的是這幾個點第一塊號溢出。YModem的塊號是8位最大255超過255會回繞到0。如果固件超過32KB128字節(jié)塊的情況下塊號就會回繞。我的處理方式是直接忽略塊號校驗只校驗數(shù)據(jù)CRC因為塊號在文件傳輸場景下本來就不太有意義。第二取消機制。YModem協(xié)議里接收方連續(xù)發(fā)送兩個CAN0x18表示取消傳輸。這個機制一定要留好接口否則串口調(diào)試助手誤觸發(fā)了什么字符傳輸狀態(tài)就卡死了。我一般會在接收循環(huán)里判斷如果連續(xù)兩次收到0x18就強制退出并擦除下載區(qū)。第三超時與重傳。YModem規(guī)定了3秒超時重傳機制發(fā)送方發(fā)一個包后如果3秒內(nèi)沒收到應(yīng)答就會重發(fā)。嵌入式接收端必須在這個時間內(nèi)響應(yīng)否則體驗很不好。我實測下來SecureCRT的YModem發(fā)送一個1024字節(jié)塊后的等待時間是3秒這要求接收端的擦除Flash、寫入Flash操作不能超過這個時間閾值否則就必須把擦寫操作拆分或者用雙緩沖。提示片外SPI Flash頁寫入通常是256字節(jié)所以在接收循環(huán)里每收到一個1024字節(jié)塊要拆成4次頁寫入。每次頁寫入前還要確保目標地址是空閑狀態(tài)。我建議在寫之前先判斷當前塊是否需要擦除用SFUD的sfud_erase_write接口一次搞定省得自己處理擦寫邊界。3.2 RT-Thread OTA組件的分層設(shè)計RT-Thread的OTA升級組件其實是做了分層設(shè)計的理解這個分層對后續(xù)調(diào)試很有幫助。最底層是FAL提供的分區(qū)讀寫接口中間層是OTA組件自己的管理邏輯包括固件頭解析、版本校驗、拷貝執(zhí)行等最上層才是YModem這樣的傳輸協(xié)議。用YModem做OTA時固件數(shù)據(jù)流的完整路徑是串口 - YModem接收循環(huán) - 下載區(qū)分區(qū)寫入 - 固件頭校驗 - 拷貝到App分區(qū) - 設(shè)置Boot標志 - 復(fù)位重啟。這個流程里最容易忽略的是固件頭。如果不做固件頭Bootloader拿到一堆裸二進制數(shù)據(jù)根本不知道這是不是個合法固件版本號對不對長度是否超出App分區(qū)。所以我在生成升級包的時候會在二進制數(shù)據(jù)最前面拼一個自定義頭部結(jié)構(gòu)體。3.3 固件包格式與版本校驗設(shè)計固件包格式這塊我踩過不少坑。起初直接裸傳bin文件Bootloader收到后直接搬運后來發(fā)現(xiàn)如果傳了個損壞文件App區(qū)就被覆蓋成磚了。所以后來引入了自定義包頭typedef struct { uint32_t magic; /* 魔數(shù)固定為0x544F4131即TOA1 */ uint32_t firmware_size; /* 固件實際大小不含包頭 */ uint32_t firmware_crc; /* 固件數(shù)據(jù)的CRC32 */ uint32_t version; /* 版本號單調(diào)遞增 */ uint32_t reserved[3]; /* 保留 */ } firmware_header_t;這個頭部一共32字節(jié)放在固件文件的最前面。生成升級包時先算原始bin的CRC32和大小填好頭然后把頭部原始bin拼接成一個新的升級文件。Bootloader收到文件后第一步檢查魔數(shù)第二步檢查CRC第三步檢查版本號是否大于當前運行固件版本。全部通過才允許搬運否則直接丟棄并報錯。版本號用單調(diào)遞增的uint32避免用字符串版本號在比較時出幺蛾子。我第一次用v1.2.3這種字符串版本號比較邏輯寫起來麻煩不說還容易把v1.10.0和v1.9.0比較錯。改成數(shù)字版本號之后清爽很多。4. 實操過程Bootloader與App的完整實現(xiàn)4.1 Bootloader端代碼結(jié)構(gòu)Bootloader的代碼結(jié)構(gòu)不算復(fù)雜核心就是一個主循環(huán)加狀態(tài)機。我把它分成四個模塊平臺初始化模塊、YModem接收模塊、固件搬運模塊、啟動跳轉(zhuǎn)模塊。主程序的邏輯用狀態(tài)機來表達清晰且不容易亂typedef enum { STATE_CHECK_APP_VALID, /* 檢查App分區(qū)是否有合法固件 */ STATE_WAIT_FIRMWARE, /* 等待YModem上傳新固件 */ STATE_RECEIVING, /* 正在接收固件數(shù)據(jù) */ STATE_VERIFY_FIRMWARE, /* 校驗固件頭和CRC */ STATE_COPY_FIRMWARE, /* 搬運固件到App分區(qū) */ STATE_BOOT_APP, /* 跳轉(zhuǎn)到App執(zhí)行 */ STATE_ERROR /* 錯誤狀態(tài)打印日志并停止 */ } boot_state_t;這里有個細節(jié)值得展開啟動時檢查App區(qū)是否有合法固件是OTA系統(tǒng)里最容易被忽略的一環(huán)。如果App區(qū)是空的或者已經(jīng)被擦除了Bootloader不能直接跳轉(zhuǎn)否則就是死機。我的檢查方式是讀App區(qū)起始地址存放的兩個值一個是棧指針必須是有效的RAM地址在0x20000000到0x20020000范圍內(nèi)另一個是復(fù)位向量必須是有效的Flash地址。兩個都滿足才跳轉(zhuǎn)。4.2 Bootloader跳轉(zhuǎn)App的實現(xiàn)跳轉(zhuǎn)邏輯是Bootloader里最敏感的代碼。網(wǎng)上流傳的跳轉(zhuǎn)代碼很多但很多都有個小問題。標準寫法是typedef void (*app_entry_t)(void); void jump_to_app(uint32_t app_addr) { uint32_t app_sp *(volatile uint32_t *)app_addr; uint32_t app_pc *(volatile uint32_t *)(app_addr 4); app_entry_t app_entry (app_entry_t)app_pc; /* 關(guān)閉全局中斷 */ __disable_irq(); /* 設(shè)置主棧指針 */ __set_MSP(app_sp); /* 清空中斷表防止舊中斷響應(yīng) */ for (int i 0; i 8; i) { NVIC-ICER[i] 0xFFFFFFFF; NVIC-ICPR[i] 0xFFFFFFFF; } /* 跳轉(zhuǎn) */ app_entry(); }這里有兩個關(guān)鍵點。第一__disable_irq()必須在跳轉(zhuǎn)前執(zhí)行否則App啟動過程中如果來了中斷而中斷向量表還沒切換好就會進HardFault。第二__set_MSP不只是設(shè)置一個寄存器那么簡單它還涉及流水線狀態(tài)所以跳轉(zhuǎn)前最好用__DSB()和__ISB()做一下指令屏障。嚴謹一點的寫法是這樣__disable_irq(); __DSB(); __ISB(); __set_MSP(app_sp); __DSB(); __ISB(); app_entry();不要小看這兩個屏障我在調(diào)試時遇到過一種詭異現(xiàn)象跳轉(zhuǎn)后App偶爾能跑偶爾跑飛時好時壞。查了很久最后發(fā)現(xiàn)就是少了ISB指令屏障導(dǎo)致處理器流水線里還有老的指令沒沖刷干凈跳過去后執(zhí)行了舊的指令序列。4.3 App端的接收配合與分區(qū)寫入App端的邏輯就相對簡單了它只需要把YModem收到的數(shù)據(jù)寫入下載分區(qū)即可。這里我用RT-Thread的YModem組件它已經(jīng)把協(xié)議細節(jié)封裝好了我們只需要注冊一個接收回調(diào)static rt_err_t ymodem_recv_callback(ymodem_ctx_t *ctx, uint8_t *buffer, rt_size_t size) { struct fal_part *download_part fal_part_find(download); if (download_part RT_NULL) { return -RT_ERROR; } /* 從下載區(qū)當前偏移位置寫入數(shù)據(jù) */ rt_size_t written fal_part_write(download_part, ctx-file_offset, buffer, size); if (written ! size) { return -RT_ERROR; } return RT_EOK; }整個接收流程調(diào)用ymodem_ota_start(ymodem_recv_callback)就行。YModem組件會在每次收到完整數(shù)據(jù)塊后回調(diào)一次我們把數(shù)據(jù)寫入download分區(qū)。因為YModem最終傳完會把偏移量停在文件末尾所以可以在回調(diào)里記錄一下最終文件大小方便后續(xù)校驗。固件頭校驗和版本檢查放在接收完成后執(zhí)行。注意順序先校驗再搬運任何一個環(huán)節(jié)出錯都要停止不要嘗試“繼續(xù)傳半個包”。我遇到過有人圖省事在接收過程中邊收邊校驗最后發(fā)現(xiàn)前面的數(shù)據(jù)塊在傳輸過程中出錯但后面的塊已經(jīng)覆蓋了。所以正確的姿勢一定是“整包收完 - 統(tǒng)一校驗 - 成功才搬運”。4.4 生成YModem升級包并執(zhí)行升級生成升級包這塊我用的是Python腳本在編譯完成后自動處理。腳本做的事很簡單讀入編譯出的bin文件計算CRC32和大小填充頭部再拼接輸出一個新的bin。之后在SecureCRT里選擇YModem發(fā)送這個新bin即可。import struct import zlib import sys import os def make_ota_package(input_bin, output_bin, version): with open(input_bin, rb) as f: firmware f.read() firmware_size len(firmware) firmware_crc zlib.crc32(firmware) 0xFFFFFFFF magic 0x544F4131 header struct.pack(IIIII, magic, firmware_size, firmware_crc, version, 0) header b\x00 * 12 # reserved with open(output_bin, wb) as f: f.write(header) f.write(firmware) print(fOTA package generated: {output_bin}) print(fFirmware size: {firmware_size} bytes, CRC32: 0x{firmware_crc:08X}) if __name__ __main__: make_ota_package(sys.argv[1], sys.argv[2], int(sys.argv[3]))執(zhí)行升級時SecureCRT的連接協(xié)議要選YModem。這里有一個實用小技巧SecureCRT的逐文件傳輸劇本功能可以自動完成“發(fā)送YModem包-等待完成”的流程不需要手動點。把升級流程腳本化之后產(chǎn)線升級效率能提升很多也不用教工人點那些復(fù)雜的界面。4.5 從Bootloader到App的完整啟動流程最后把所有環(huán)節(jié)串起來看一次完整的啟動流程是什么樣的芯片上電Bootloader開始執(zhí)行。Bootloader檢查App區(qū)頭部合法性和CRC。如果App合法等待2秒或通過按鍵進入升級模式超時后跳轉(zhuǎn)App。如果進入升級模式初始化W25Q128清除下載區(qū)開始YModem接收。接收完成校驗固件頭、校驗CRC、比較版本號。校驗通過后擦除App分區(qū)將下載區(qū)固件搬運到App分區(qū)。設(shè)置升級標志復(fù)位重啟。Bootloader啟動檢查App合法跳轉(zhuǎn)執(zhí)行新固件。這個流程里第5步的版本號比較是防止重復(fù)升級的第2步的合法性檢查是防止App區(qū)損壞時變磚的第6步的搬運是存在FW搬遷失敗可能性的所以搬運完之后Bootloader要再次校驗App區(qū)的CRC。我在這個位置犯過一個錯誤搬運完成后沒有重新校驗結(jié)果有次Flash擦寫不穩(wěn)定App區(qū)拷了一半就跳轉(zhuǎn)了直接變磚最后還是靠JTAG救回來的。從那之后我在拷貝完成后再做一次CRC校驗穩(wěn)了很多。5. 常見問題與排查技巧實錄5.1 典型問題速查表下面這個表是我在這套方案上踩過的坑里最有代表性的幾個整理出來供排查時參考問題現(xiàn)象可能原因解決方案YModem傳輸一直超時重傳無法開始SPI Flash未初始化或設(shè)備名不對先執(zhí)行sfud probe spi10確認Flash設(shè)備存在傳輸完成但校驗失敗固件頭里的CRC計算方式與接收端不一致確認雙方都用CRC32多項式相同初始值與最終異或值一致傳輸完成后跳轉(zhuǎn)App啟動即HardFaultApp鏈接腳本的ROM起始地址與分區(qū)表不一致檢查App工程的鏈接腳本確保ROM起始地址是0x08010000跳轉(zhuǎn)后PC跑飛時好時壞缺少指令屏障或中斷表沒有清理干凈在跳轉(zhuǎn)前增加__DSB()和__ISB()清空NVIC掛起中斷YModem傳輸很慢只有每秒幾十KB波特率設(shè)置過低或Flash頁寫入效率低把波特率從115200提升到460800或921600用SFUD的整塊寫入接口Bootloader能收到數(shù)據(jù)但下載區(qū)沒數(shù)據(jù)回調(diào)函數(shù)寫入的偏移量未按實際接收長度增加檢查回調(diào)里是否使用了ctx-file_offset作為寫入偏移固件包能傳但版本號比較邏輯混亂版本號用字符串表示統(tǒng)一改為uint32遞增數(shù)字版本號5.2 兩個容易忽略的深坑上面表格里列的方案都能解決但有兩個深坑我想單獨拿出來詳細說。第一個是關(guān)于SPI Flash擦除的耗時問題。W25Q128一個扇區(qū)4KB擦除時間典型是45ms如果你的固件有300KB下載區(qū)1MB分成256個扇區(qū)全片擦除一次大概要12秒。這個時間必須在YModem開始傳輸之前完成不能在接收過程中邊擦邊寫。我一開始沒注意這個問題把擦除放在第一次寫入回調(diào)里執(zhí)行結(jié)果收到第一個塊之后一直在擦片擦區(qū)YModem超時重傳了好幾輪整個傳輸過程非常不穩(wěn)定。后來我把擦除操作移到Y(jié)Modem接收之前一次性擦完整個下載區(qū)問題徹底消失。第二個是關(guān)于邊界對齊的寫操作。W25Q128的最小可編程單位是1字節(jié)但實際寫入最小單位是頁256字節(jié)。當你用SFUD的sfud_write寫數(shù)據(jù)時如果起始地址或結(jié)束地址沒有按頁邊界對齊SFUD內(nèi)部會做處理但處理邏輯是先讀回整頁數(shù)據(jù)再改寫部分字節(jié)再整頁寫回。這個邏輯本身沒問題問題在于它會對未擦除的區(qū)域做讀改寫而如果你之前沒有先擦除讀到的是0xFF以外的數(shù)據(jù)那你寫入的數(shù)據(jù)就會被舊數(shù)據(jù)污染。所以正確的操作順序一定是先擦除整個目標區(qū)域再分區(qū)按塊寫入。5.3 調(diào)試技巧如何快速定位問題調(diào)試OTA這種功能最痛苦的是“現(xiàn)象在Bootloader和App之間切換分不清哪邊的問題”。我習慣在Bootloader里加完整的日志輸出所有關(guān)鍵節(jié)點都打一行。特別是YModem接收過程中每收到一個塊就打印一個進度條這樣能直觀看到傳輸是否卡住。另一個技巧是給Bootloader和App分別配置獨立的串口日志前綴。Bootloader的日志統(tǒng)一以[BOOT]開頭App的日志以[APP]開頭。跳轉(zhuǎn)后如果還能看到[BOOT]的日志說明跳轉(zhuǎn)失敗了如果只能看到[APP]的日志說明App已經(jīng)正常運行。別小看這個簡單的約定在調(diào)試時它幫我省了大量時間。還有一個小技巧是專門針對“下載區(qū)搬運到App區(qū)失敗”這種問題的。如果搬運完后CRC校驗失敗但下載區(qū)數(shù)據(jù)本身是好的大概率是搬運過程中的Flash寫入問題。我會在Bootloader里留一個“從下載區(qū)重新搬運”的命令行入口這樣不需要重新通過YModem傳文件直接在命令行觸發(fā)一次搬運就行調(diào)試效率高很多。6. 這套方案的局限與后續(xù)擴展說句實在話YModem 串口這套OTA方案雖然穩(wěn)定可靠但也有它的天花板。最明顯的一點是必須靠人工介入沒法遠程觸發(fā)。如果產(chǎn)品部署在客戶現(xiàn)場想要遠程升級固件那YModem這套就不合適了必須換HTTP或者MQTT這類網(wǎng)絡(luò)傳輸方式。我現(xiàn)在這個方案里其實已經(jīng)預(yù)留了升級接口后續(xù)如果要做網(wǎng)絡(luò)OTA基本上只需要做兩件事一是把YModem接收模塊替換成HTTP下載模塊App在運行時可以通過網(wǎng)絡(luò)下載固件包到下載區(qū)二是下載完之后的校驗、搬運、跳轉(zhuǎn)邏輯完全不用動因為它們本來就和傳輸協(xié)議解耦了。還有一點是關(guān)于雙備份升級。我計劃在W25Q128的backup_a和backup_b分區(qū)做雙備份。思路是新固件先寫到backup_a然后從backup_a搬運到App區(qū)這樣即使App區(qū)寫入失敗還可以從backup_a重新搬運甚至Bootloader可以支持從上一次備份的backup_b引導(dǎo)。這種設(shè)計能進一步降低變磚概率但現(xiàn)階段對大多數(shù)場景來說下載區(qū)加單備份已經(jīng)夠用了雙備份等有需求再加。根據(jù)我的測試這套方案在115200波特率下傳一個300KB的固件包大約需要35秒加上校驗和搬運的時間總體升級時間在40秒左右。如果波特率提高到460800時間能壓到10秒以內(nèi)。不過要提高波特率前提是你的串口芯片和線材質(zhì)量足夠好不然誤碼率上來了反而更慢。這篇文章寫到的所有關(guān)鍵點都是我在這塊板子上實實在在跑通了的。從分區(qū)規(guī)劃到Y(jié)Modem接收從Bootloader跳轉(zhuǎn)到固件校驗每一步都踩過坑、填過坑。如果你正在做類似的事情希望這些記錄能幫你少走一些彎路。尤其是分區(qū)表、鏈接腳本、跳轉(zhuǎn)屏障這幾個位置一次配好后面就非常省心了。