簡(jiǎn)介面向STM32F103C8T6開發(fā)者的串口IAP升級(jí)固件源碼包完整解決單片機(jī)通過(guò)串口實(shí)現(xiàn)在線固件升級(jí)與跳轉(zhuǎn)執(zhí)行的需求適合需要掌握Bootloader原理或正在調(diào)試在線升級(jí)方案的嵌入式工程師也適合為儀器儀表、物聯(lián)網(wǎng)節(jié)點(diǎn)等設(shè)備增加遠(yuǎn)程維護(hù)能力的項(xiàng)目參考。資源共430個(gè)文件、2.23MB以86個(gè)C源文件與86個(gè)頭文件構(gòu)成主要邏輯另有匯編啟動(dòng)文件、鏈接腳本以及uvproj、ewp等工程配置覆蓋從源碼修改、編譯鏈接到生成hex/bin固件的完整開發(fā)鏈條匯編入口與鏈接腳本便于分析啟動(dòng)過(guò)程和內(nèi)存布局說(shuō)明文檔則可幫助快速理解代碼結(jié)構(gòu)。包內(nèi)基礎(chǔ)工程直接搭建了IAP升級(jí)環(huán)境按典型流程展示Flash分區(qū)規(guī)劃、串口通信協(xié)議與固件跳轉(zhuǎn)處理且保留較多可配置參數(shù)方便根據(jù)實(shí)際硬件或協(xié)議需求進(jìn)行裁剪移植省去從零構(gòu)建引導(dǎo)程序的繁瑣環(huán)節(jié)。該資源已有5148人學(xué)習(xí)下載對(duì)初學(xué)STM32在線升級(jí)或需要快速?gòu)?fù)現(xiàn)Bootloader方案的中高級(jí)開發(fā)者是一份實(shí)用價(jià)值較高的參考源碼包。1. 串口IAP升級(jí)STM32F103C8T6最反直覺(jué)的一次開發(fā)在 STM32F103C8T6 的項(xiàng)目里做串口 IAP 固件升級(jí)最反直覺(jué)的一點(diǎn)是決定升級(jí)過(guò)程能不能可靠完成的不是那幾行“接收串口數(shù)據(jù)、寫 Flash”的代碼而是 Bootloader 里兩個(gè)看起來(lái)不起眼的瞬間——上電后等多久再跳 App以及“升級(jí)請(qǐng)求”標(biāo)志被放在哪個(gè)地址。這兩處沒(méi)想清楚設(shè)備在產(chǎn)線上燒好第一版時(shí)一切正常發(fā)到現(xiàn)場(chǎng)要通過(guò)串口升級(jí)時(shí)十次里有三次變磚。這個(gè)源碼包做的就是把 C8T6 的 64KB Flash 拆成 16KB Bootloader 和 48KB App用串口協(xié)議把新固件分包寫入 App 區(qū)校驗(yàn)通過(guò)后跳轉(zhuǎn)執(zhí)行。適合剛接觸 IAP 的人照著完整流程手搓一遍也適合正在做量產(chǎn)設(shè)備、被現(xiàn)場(chǎng)升級(jí)穩(wěn)定性反復(fù)折磨的開發(fā)者對(duì)照排查。下面按我從拿到源碼到跑通、再到改出自己一版的順序來(lái)講。2. 整體設(shè)計(jì)與 Flash 分區(qū)Bootloader 和 App 怎么在 64KB Flash 里共存拿到 C8T6 的第一件事是把“Flash 有 64KB”這個(gè)數(shù)字忘掉。實(shí)際應(yīng)用可用的只有 48KB因?yàn)榍懊?16KB 要?jiǎng)澖o Bootloader。很多人的 App 加了協(xié)議棧、日志和狀態(tài)機(jī)之后塞不進(jìn) 48KB十有八九是在選型時(shí)沒(méi)做這個(gè)心理預(yù)期。IAP 不是把兩個(gè)程序隨便丟進(jìn) Flash而是先畫好地盤再寫代碼。2.1 雙區(qū)架構(gòu)與內(nèi)存規(guī)劃16KB Bootloader 48KB App源碼包里的分區(qū)方案很直接一張表就能說(shuō)清區(qū)域起始地址大小存放內(nèi)容Bootloader 區(qū)0x0800000016KBIAP 主程序、串口驅(qū)動(dòng)、Flash 擦寫驅(qū)動(dòng)App 區(qū)0x0800400048KB業(yè)務(wù)固件、App 中斷向量表參數(shù)頁(yè)0x08003C001KB升級(jí)請(qǐng)求標(biāo)志、版本號(hào)記錄為什么要留 16KB 給 Bootloader而不是省到 8KB我用標(biāo)準(zhǔn)外設(shè)庫(kù)編譯過(guò)這個(gè)工程串口加 Flash 驅(qū)動(dòng)加上協(xié)議解析編譯出來(lái)大約 6~9KB留 16KB 是給自己留后路。后面要加 CRC 校驗(yàn)之外的加密、簽名代碼量會(huì)明顯膨脹如果把 Bootloader 壓縮到 4KB純寄存器操作確實(shí)能塞下但可讀性和可維護(hù)性都會(huì)變差。這里有個(gè)繞不開的硬件事實(shí)Cortex-M3 上電后從 Flash 起始地址取兩個(gè)字——第一個(gè)字是初始主堆棧指針 MSP第二個(gè)字是復(fù)位向量。Bootloader 的向量表必須在 0x08000000因?yàn)檫@是硬件固定的。而 App 的向量表本來(lái)也應(yīng)在 0x08000000可那個(gè)位置被 Bootloader 占著App 只能把向量表挪到 0x08004000。麻煩在于 CPU 并不知道這個(gè)偏移必須通過(guò) SCB-VTOR 告訴它。STM32F103 的 VTOR 在 0xE000ED08F1 全系列都有這個(gè)寄存器這點(diǎn)比某些 Cortex-M0 單片機(jī)要省事。2.2 啟動(dòng)流程與跳轉(zhuǎn)條件升級(jí)標(biāo)志位、串口窗口與跳轉(zhuǎn)判定整個(gè)啟動(dòng)流程如果用文字描述是這樣的鏈路上電復(fù)位 → Bootloader 初始化時(shí)鐘和串口 → 讀取參數(shù)頁(yè)的升級(jí)請(qǐng)求標(biāo)志 → 若標(biāo)志有效清標(biāo)志并直接進(jìn)入升級(jí)等待模式 → 若標(biāo)志無(wú)效等待約 300ms 的串口命令窗口 → 窗口內(nèi)收到握手幀進(jìn)入升級(jí)模式 → 窗口結(jié)束仍未收到命令跳轉(zhuǎn)到 App。為什么是“等約 300ms”而不是無(wú)限等現(xiàn)場(chǎng)升級(jí)要求上電盲操作設(shè)備一上電 Bootloader 先開一個(gè)短暫的升級(jí)窗口上位機(jī)只要能在這個(gè)窗口里發(fā)出握手幀就能搶占。窗口太短現(xiàn)場(chǎng)人員來(lái)不及窗口太長(zhǎng)設(shè)備每次開機(jī)都要慢幾秒。300ms 是我在速度和成功率之間試出來(lái)的經(jīng)驗(yàn)值源碼包里也留了宏定義可以自己調(diào)。升級(jí)請(qǐng)求標(biāo)志放在參數(shù)頁(yè)而不是放在 App 區(qū)尾部原因很實(shí)際App 運(yùn)行時(shí)不能擦寫自己正在執(zhí)行的 Flash 頁(yè)。假如把標(biāo)志寫在 App 區(qū)同一頁(yè)程序一邊從 Flash 取指令一邊擦寫那一頁(yè)輕則寫失敗重則 HardFault。所以 App 請(qǐng)求升級(jí)時(shí)是把標(biāo)志寫給 Bootloader 區(qū)里獨(dú)立的一頁(yè)。核心代碼是這樣的#define PARA_FLAG_ADDR 0x08003C00 /* Bootloader區(qū)最后一頁(yè)1KB */ #define FLAG_MAGIC 0x5A5AA5A5 void app_request_upgrade(void) { uint32_t flags FLAG_MAGIC; FLASH_Unlock(); FLASH_ClearFlag(FLASH_FLAG_EOP | FLASH_FLAG_PGERR | FLASH_FLAG_WRPRTERR); FLASH_ErasePage(PARA_FLAG_ADDR); /* 先整頁(yè)擦除 */ FLASH_ProgramWord(PARA_FLAG_ADDR, flags); /* 寫入魔數(shù) */ FLASH_Lock(); NVIC_SystemReset(); /* 軟復(fù)位進(jìn)Bootloader */ }這段代碼關(guān)鍵在兩點(diǎn)擦除后寫入是標(biāo)準(zhǔn)流程不能省掉 ClearFlag寫完魔數(shù)后立刻軟復(fù)位讓 Bootloader 來(lái)決定接下來(lái)是升級(jí)還是正常跳轉(zhuǎn)App 自己不做升級(jí)流程的分發(fā)?，F(xiàn)場(chǎng)人員只要觸發(fā) App 里的這個(gè)函數(shù)設(shè)備重啟后就會(huì)自動(dòng)停在升級(jí)等待狀態(tài)。Bootloader 啟動(dòng)時(shí)的判斷同樣簡(jiǎn)單if (*(volatile uint32_t *)PARA_FLAG_ADDR FLAG_MAGIC) { FLASH_ErasePage(PARA_FLAG_ADDR); /* 清掉請(qǐng)求標(biāo)志防止下次重復(fù)誤入升級(jí) */ iap_state IAP_STATE_UPGRADE; /* 進(jìn)入升級(jí)等待模式 */ }清標(biāo)志必須在跳轉(zhuǎn)升級(jí)邏輯之前完成否則升級(jí)過(guò)程中途斷電再上電會(huì)又一次進(jìn)入升級(jí)模式反而把正常 App 擋住。這個(gè)順序我一開始寫反過(guò)結(jié)果現(xiàn)場(chǎng)出現(xiàn)“設(shè)備永遠(yuǎn)停在升級(jí)等待App 起不來(lái)”的翻車原因就是標(biāo)志沒(méi)被清掉。3. 串口升級(jí)協(xié)議與 Bootloader 核心代碼拆解一幀一幀把固件搬進(jìn) FlashBootloader 的本質(zhì)是一個(gè)串口透?jìng)鲗懭肫魃衔粰C(jī)發(fā)一幀Bootloader 解析一幀、校驗(yàn)一幀、寫一次 Flash。協(xié)議設(shè)計(jì)得不好升級(jí)過(guò)程就會(huì)變成一場(chǎng)對(duì)時(shí)鐘和運(yùn)氣的賭博。這章我把協(xié)議幀、狀態(tài)機(jī)、Flash 操作和跳轉(zhuǎn)邏輯逐一拆開講。3.1 串口協(xié)議幀設(shè)計(jì)幀頭、命令字、長(zhǎng)度與 CRC16 校驗(yàn)源碼包里的協(xié)議幀格式很簡(jiǎn)單但足夠防錯(cuò)字節(jié)序字段長(zhǎng)度說(shuō)明0幀頭2 字節(jié)固定 0xAA 0x552命令字1 字節(jié)0x01 升級(jí)開始0x02 數(shù)據(jù)塊0x03 完成校驗(yàn)0x04 跳轉(zhuǎn) App3數(shù)據(jù)長(zhǎng)度2 字節(jié)小端序payload 字節(jié)數(shù)不含幀頭和 CRC5Payload變長(zhǎng)數(shù)據(jù)塊命令里是 offset(4 字節(jié)) 固件數(shù)據(jù)(最多 256 字節(jié))末尾CRC162 字節(jié)CRC16-MODBUS覆蓋數(shù)據(jù)長(zhǎng)度和 Payload命令字是升級(jí)流程的骨架。0x01 升級(jí)開始命令里上位機(jī)告訴 Bootloader 固件總長(zhǎng)度Bootloader 收到后擦除整個(gè) App 區(qū)并回復(fù) ACK0x02 數(shù)據(jù)塊命令承擔(dān)真正的搬磚工作每幀最多帶 256 字節(jié)數(shù)據(jù)0x03 完成校驗(yàn)命令用于回讀 Flash 算 CRC0x04 才是真正觸發(fā)跳轉(zhuǎn)的那一下。串口接收我建議用狀態(tài)機(jī)而不是直接等一個(gè)“完整幀中斷”因?yàn)?STM32F103 的串口一次中斷只停在一個(gè)字節(jié)上數(shù)據(jù)是碎片化到達(dá)的。狀態(tài)機(jī)在串口中斷里逐字節(jié)喂最穩(wěn)妥typedef enum { ST_WAIT_HEAD1 0, ST_WAIT_HEAD2, ST_WAIT_CMD, ST_WAIT_LEN, ST_WAIT_PAYLOAD, ST_WAIT_CRC } RX_STATE; static RX_STATE rx_state ST_WAIT_HEAD1; static uint16_t payload_len 0; static uint16_t payload_idx 0; static uint16_t crc_idx 0; void IAP_RxHandler(uint8_t byte) { switch (rx_state) { case ST_WAIT_HEAD1: if (byte 0xAA) rx_state ST_WAIT_HEAD2; break; case ST_WAIT_HEAD2: rx_state (byte 0x55) ? ST_WAIT_CMD : ST_WAIT_HEAD1; break; case ST_WAIT_CMD: rx_frame.cmd byte; payload_len 0; payload_idx 0; crc_idx 0; rx_state ST_WAIT_LEN; break; case ST_WAIT_LEN: if (payload_idx 0) { payload_len byte; /* 長(zhǎng)度低字節(jié)先到 */ payload_idx 1; } else { payload_len | (uint16_t)byte 8; /* 高字節(jié)拼出完整長(zhǎng)度 */ payload_idx 0; rx_state ST_WAIT_PAYLOAD; } break; case ST_WAIT_PAYLOAD: rx_frame.payload[payload_idx] byte; if (payload_idx payload_len) { crc_idx 0; rx_state ST_WAIT_CRC; } break; case ST_WAIT_CRC: if (crc_idx 0) { rx_frame.crc byte; /* CRC 低字節(jié) */ crc_idx 1; } else { rx_frame.crc | (uint16_t)byte 8; IAP_OnFrameComplete(rx_frame); /* 一幀收齊 */ rx_state ST_WAIT_HEAD1; /* 回到幀頭狀態(tài) */ } break; default: rx_state ST_WAIT_HEAD1; break; } }狀態(tài)機(jī)的幾個(gè)參數(shù)值得說(shuō)明payload_len 是兩字節(jié)小端所以要先收低字節(jié)再收高字節(jié)payload_idx 在這里實(shí)際是長(zhǎng)度收齊后的數(shù)據(jù)計(jì)數(shù)實(shí)現(xiàn)時(shí)也可以單獨(dú)用一個(gè)計(jì)數(shù)變量邏輯更清楚任何一幀中間字節(jié)出錯(cuò)狀態(tài)機(jī)都會(huì)回到 ST_WAIT_HEAD1下一幀能自動(dòng)恢復(fù)不用重啟設(shè)備。幀收齊后進(jìn)入分發(fā)性處理先把 CRC 校驗(yàn)做掉再按命令字分發(fā)void IAP_OnFrameComplete(IAP_Frame *frame) { uint16_t calc_crc CRC16_Modbus((uint8_t *)frame-cmd, 3 frame-len); if (calc_crc ! frame-crc) { IAP_SendAck(AK_CRC_ERR); return; } switch (frame-cmd) { case CMD_UPGRADE_START: IAP_OnStart(frame); break; case CMD_UPGRADE_DATA: IAP_OnData(frame); break; case CMD_UPGRADE_FINISH: IAP_OnFinish(frame); break; case CMD_UPGRADE_JUMP: IAP_JumpToApp(); break; default: IAP_SendAck(AK_CMD_ERR); break; } }CRC 的覆蓋范圍是命令字 長(zhǎng)度 Payload幀頭不參與計(jì)算。這是有意為之因?yàn)閹^本身有 AA 55 做同步而 CRC 要保護(hù)的是真正影響數(shù)據(jù)的字段。源碼里用的是 CRC16-MODBUS初值 0xFFFF 多項(xiàng)式 0xA001實(shí)現(xiàn)只有幾行uint16_t CRC16_Modbus(uint8_t *buf, uint16_t len) { uint16_t crc 0xFFFF; for (uint16_t i 0; i len; i) { crc ^ buf[i]; for (uint8_t j 0; j 8; j) { if (crc 0x0001) crc (crc 1) ^ 0xA001; else crc 1; } } return crc; }上位機(jī)計(jì)算 CRC 時(shí)必須用同樣的多項(xiàng)式否則聯(lián)調(diào)時(shí)會(huì)出現(xiàn)“每一幀都回 CRC_ERR”的現(xiàn)象。這種問(wèn)題排查起來(lái)特別像玄學(xué)其實(shí)是兩端 CRC 不一致。3.2 Flash 擦寫與存儲(chǔ)邏輯先整片擦除、再半字寫入、最后回讀校驗(yàn)STM32F103 的 Flash 有一個(gè)特性寫入以半字16 位為單位擦除以頁(yè)為單位每頁(yè) 1KB。寫入前目標(biāo)頁(yè)必須處于已擦除狀態(tài)否則寫入結(jié)果不確定。這直接決定了升級(jí)策略收到第一幀命令時(shí)不能邊收邊寫而是先把整個(gè) App 區(qū)擦干凈。#define APP_BASE_ADDR 0x08004000 #define FLASH_PAGE_SIZE 1024 #define APP_TOTAL_SIZE 0xC000 /* 48KB */ static uint32_t write_offset 0; static uint8_t flash_started 0; void IAP_OnStart(IAP_Frame *frame) { uint32_t total_len *(uint32_t *)frame-payload[0]; if (total_len APP_TOTAL_SIZE) { IAP_SendAck(AK_LEN_ERR); return; } FLASH_Unlock(); FLASH_ClearFlag(FLASH_FLAG_EOP | FLASH_FLAG_PGERR | FLASH_FLAG_WRPRTERR); /* 整片擦除App區(qū)防止舊數(shù)據(jù)和殘留頁(yè)干擾 */ for (uint32_t addr APP_BASE_ADDR; addr APP_BASE_ADDR APP_TOTAL_SIZE; addr FLASH_PAGE_SIZE) { FLASH_ErasePage(addr); } write_offset 0; flash_started 1; IAP_SendAck(AK_OK); }整片擦除 48KB 共 48 頁(yè)按 HSI 8MHz 或 PLL 倍頻后的 CPU 時(shí)鐘算大約要幾百毫秒。所以上位機(jī)發(fā)完升級(jí)開始命令后不能立刻發(fā)數(shù)據(jù)必須等 Bootloader 回 ACK。這個(gè)等待關(guān)系在協(xié)議設(shè)計(jì)里要寫清楚否則上位機(jī)發(fā)得快數(shù)據(jù)幀會(huì)因?yàn)?Flash 還沒(méi)擦完而被忽略。數(shù)據(jù)塊寫入是每幀動(dòng)作核心是把 payload 里的偏移量和數(shù)據(jù)取出來(lái)逐個(gè)半字寫入void IAP_OnData(IAP_Frame *frame) { uint32_t offset; uint8_t *data; uint16_t data_len; uint32_t target_addr; if (!flash_started) { IAP_SendAck(AK_NOT_STARTED); /* 沒(méi)收到升級(jí)開始命令直接拒絕 */ return; } offset *(uint32_t *)frame-payload[0]; /* 前4字節(jié)是目標(biāo)偏移 */ data frame-payload[4]; data_len frame-len - 4; target_addr APP_BASE_ADDR offset; /* 越界檢查防住上位機(jī)發(fā)瘋 */ if ((target_addr data_len) (APP_BASE_ADDR APP_TOTAL_SIZE)) { IAP_SendAck(AK_ADDR_ERR); return; } /* 半字寫入data_len 確保是偶數(shù) */ for (uint16_t i 0; i data_len; i 2) { uint16_t half_word data[i] | (data[i 1] 8); FLASH_ProgramHalfWord(target_addr i, half_word); } write_offset offset data_len; IAP_SendAck(AK_OK); }這里有兩個(gè)必須守住的約定offset 必須按 2 字節(jié)對(duì)齊data_len 必須是偶數(shù)。上位機(jī)在發(fā)送數(shù)據(jù)幀之前要把 bin 文件按 2 字節(jié)補(bǔ)齊最后不足 2 字節(jié)補(bǔ) 0xFF。如果上位機(jī)發(fā)來(lái)奇數(shù)長(zhǎng)度的數(shù)據(jù)Bootloader 應(yīng)該直接回錯(cuò)誤而不是硬寫否則最后一次寫入會(huì)踩到未知地址。寫完后回 ACK 表示這一幀落盤上位機(jī)再發(fā)下一幀。升級(jí)完成的校驗(yàn)比“寫入成功”更可靠的是“整片回讀再算 CRC”。FLASH_ProgramHalfWord 返回狀態(tài)位在某些操作異常時(shí)不代表數(shù)據(jù)真寫對(duì)了回讀是最后防線void IAP_OnFinish(IAP_Frame *frame) { uint32_t expect_crc *(uint32_t *)frame-payload[0]; uint32_t real_crc CRC32_Flash(APP_BASE_ADDR, app_total_len); if (real_crc expect_crc) { IAP_SendAck(AK_CRC_OK); } else { IAP_SendAck(AK_CRC_ERR); /* 不跳轉(zhuǎn)保留現(xiàn)場(chǎng)等上位機(jī)重傳 */ } }CRC32_Flash 是源碼包里提供的函數(shù)遍歷 App 區(qū)已寫入的字節(jié)計(jì)算 CRC32。比較失敗時(shí)不擦除、不跳轉(zhuǎn)等上位機(jī)重新發(fā)起升級(jí)。這比直接跳進(jìn)一個(gè)損壞的 App 要安全得多。3.3 跳轉(zhuǎn)到 App 的代碼實(shí)現(xiàn)棧頂檢查、VTOR 切換與中斷屏蔽最后一步跳轉(zhuǎn)是 IAP 里最容易寫翻車的地方。跳轉(zhuǎn)的本質(zhì)不是“跳”而是“把 CPU 的執(zhí)行環(huán)境完整換掉”換中斷向量表、換棧指針、換 PC 指針。typedef void (*IAP_JumpFunc)(void); void IAP_JumpToApp(void) { uint32_t app_sp; uint32_t app_pc; IAP_JumpFunc jump_func; app_sp *(volatile uint32_t *)APP_BASE_ADDR; app_pc *(volatile uint32_t *)(APP_BASE_ADDR 4); /* 棧頂值必須在RAM地址范圍內(nèi)否則App區(qū)是空白或損壞 */ if ((app_sp 0x2FFE0000) ! 0x20000000) { return; } if ((app_pc 0xFFFFF000) 0) { return; } jump_func (IAP_JumpFunc)app_pc; /* 跳轉(zhuǎn)前徹底關(guān)中斷防止VTOR切換瞬間中斷亂入 */ __set_PRIMASK(1); SCB-VTOR APP_BASE_ADDR; /* 讓App找到自己的向量表 */ __set_MSP(app_sp); /* 換成App的初始棧指針 */ jump_func(); /* 跳到App復(fù)位向量 */ /* 如果走到這里說(shuō)明App沒(méi)起來(lái) */ __set_PRIMASK(0); }這個(gè)函數(shù)里有幾處細(xì)節(jié)決定生死。app_sp 是 App 向量表第一個(gè)字也就是 App 初始主堆棧指針跳轉(zhuǎn)前不換棧指針Bootloader 的棧調(diào)用鏈會(huì)繼續(xù)壓棧App 的 main 函數(shù)跑起來(lái)后?？臻g被污染。__set_PRIMASK(1)在切換 VTOR 前關(guān)閉全部可屏蔽中斷避免串口中斷在向量表切換的瞬間來(lái)一下CPU 拿著新向量表去找舊中斷入口直接進(jìn) HardFault。跳轉(zhuǎn)前的兩次檢查能攔掉“App 區(qū)是空白 Flash”的情況空白 Flash 讀出來(lái)是 0xFFFFFFFF通不過(guò) RAM 地址范圍判斷。4. 編譯配置與燒錄避坑讓 Bootloader 和 App 各就各位代碼寫完只是第一步真正讓這個(gè)工程跑起來(lái)的是兩個(gè) Keil 工程的配置。這章講清楚怎么建兩個(gè)工程、怎么生成 bin、怎么用串口助手手搓一次升級(jí)最后給出我踩過(guò)的三個(gè)坑。4.1 兩套 Keil 工程的 IROM 配置與 bin 文件生成源碼包分了兩個(gè) Keil 工程一個(gè) Bootloader一個(gè) App。各自的關(guān)鍵配置用一張表說(shuō)清配置項(xiàng)Bootloader 工程App 工程IROM1 起始地址0x080000000x08004000IROM1 大小0x40000xC000是否設(shè)置 VTOR不需要設(shè)置偏移 0x4000燒錄方式ST-Link 寫入通過(guò) Bootloader 串口升級(jí)App 工程里設(shè)置向量表偏移有兩種方式一種是在 main 函數(shù)里手動(dòng)執(zhí)行SCB-VTOR 0x08004000;另一種是在 system_stm32f10x.c 里宏定義VECT_TAB_OFFSET 0x4000。我推薦用后一種因?yàn)?SystemInit 在 startup 文件里比 main 更早執(zhí)行向量表在 C 環(huán)境初始化之前就切好了更穩(wěn)。如果是手動(dòng)方式注意別放在 main 的后面否則啟動(dòng)早期來(lái)的中斷照樣會(huì)跑飛。生成 bin 文件是升級(jí)的前提Keil 的 After Build 命令行里加一句fromelf --bin -o $LL.bin #L$LL會(huì)自動(dòng)展開成不帶擴(kuò)展名的工程輸出路徑#L是鏈接后的映像文件。生成后把這顆 bin 交給上位機(jī)程序就能用于串口升級(jí)。注意工程路徑不要帶空格否則 fromelf 會(huì)把路徑拆成多個(gè)參數(shù)這是我實(shí)際遇到過(guò)的低級(jí)問(wèn)題。4.2 用 Python 腳本模擬上位機(jī)手搓一遍完整升級(jí)流程在沒(méi)有現(xiàn)成上位機(jī)程序時(shí)用 Python 串口腳本就能聯(lián)調(diào)起來(lái)。核心是構(gòu)造協(xié)議幀import serial import struct def crc16_modbus(data: bytes) - int: crc 0xFFFF for b in data: crc ^ b for _ in range(8): if crc 0x0001: crc (crc 1) ^ 0xA001 else: crc 1 return crc def make_frame(cmd: int, payload: bytes) - bytes: body bytes([cmd]) struct.pack(H, len(payload)) payload crc crc16_modbus(body) return b\xaa\x55 body struct.pack(H, crc)聯(lián)調(diào)時(shí) BOOT0 保持低電平先用 ST-Link 燒 Bootloader然后只接 USB 轉(zhuǎn)串口 TTL打開串口后按這個(gè)順序跑發(fā)送升級(jí)開始幀payload 里是固件總長(zhǎng)度等待 Bootloader 回 ACK分段讀取 bin 文件每段 256 字節(jié)前三字節(jié)是因?yàn)閷?duì)齊要處理發(fā)數(shù)據(jù)幀并逐幀確認(rèn) ACK發(fā)完成校驗(yàn)幀收到 CRC_OK 后發(fā)跳轉(zhuǎn)幀。第一次聯(lián)調(diào)建議用 9600 波特率雖然慢但容錯(cuò)高。波特率越高現(xiàn)場(chǎng)線材和干擾對(duì)幀錯(cuò)誤率的影響越大。源碼包里默認(rèn)配置是 115200如果發(fā)現(xiàn) CRC 錯(cuò)誤率高先把波特率降下來(lái)再排查。4.3 避坑記錄變磚、Flash 寫入 HardFault、App 跑飛的三類排查經(jīng)驗(yàn)這一節(jié)記錄的是我實(shí)際踩過(guò)的三個(gè)坑每條都按現(xiàn)象、原因、解決展開。第一個(gè)坑是“升級(jí)中途斷電再上電設(shè)備變磚”?，F(xiàn)象是升級(jí)到一半現(xiàn)場(chǎng)工人誤拔電源再上電后設(shè)備沒(méi)有任何反應(yīng)App 起不來(lái)Bootloader 也沒(méi)響應(yīng)。原因是寫 Flash 只擦除了一部分頁(yè)App 區(qū)里既有新數(shù)據(jù)又有殘留的舊數(shù)據(jù)程序還嘗試直接跳轉(zhuǎn)。解決方法是跳轉(zhuǎn)前做嚴(yán)格的棧頂檢查和 App 有效魔數(shù)檢查魔數(shù)在 App 工程編譯時(shí)固定在向量表后第 4 個(gè)字節(jié)位置Bootloader 跳轉(zhuǎn)前讀這個(gè)位置不是約定的值就絕不跳轉(zhuǎn)并且等待上位機(jī)重新升級(jí)。第二個(gè)坑是“FLASH_ProgramHalfWord 寫入時(shí)進(jìn) HardFault”?，F(xiàn)象是寫入執(zhí)行到一半卡死調(diào)試器定位到 HardFault_Handler。原因有兩個(gè)目標(biāo)頁(yè)沒(méi)擦除干凈或者寫地址不是半字對(duì)齊。我第一次寫 IAP 時(shí)邊收邊寫收到哪頁(yè)寫哪頁(yè)沒(méi)先整片擦除結(jié)果在舊數(shù)據(jù)頁(yè)上寫入直接觸發(fā)錯(cuò)誤。解決方法是升級(jí)開始命令里整片擦除并在 IAP_OnData 里校驗(yàn) offset 是否為 2 的倍數(shù)、data_len 是否為偶數(shù)兩端約定數(shù)據(jù)補(bǔ)齊策略。第三個(gè)坑是“跳轉(zhuǎn)后 App 跑飛”?，F(xiàn)象是升級(jí)流程全部返回成功設(shè)備串口就是不工作調(diào)試器顯示停在了 HardFault_Handler。原因是 App 向量表偏移沒(méi)設(shè)。跳轉(zhuǎn)成功后App 的 main 還沒(méi)跑起來(lái)一個(gè) SysTick 或串口中斷到達(dá)CPU 從 0x08000000 讀中斷向量讀到的是 Bootloader 的中斷處理函數(shù)地址入口對(duì)不上直接 HardFault。解決方式就是在 App 工程里設(shè)置 VECT_TAB_OFFSET 為 0x4000并在跳轉(zhuǎn)函數(shù)里先__set_PRIMASK(1)再切 VTOR。這類問(wèn)題表現(xiàn)很像玄學(xué)但根因基本都是向量表偏移。5. 二次開發(fā)思路給串口 IAP 加上固件加密、版本回滾和生產(chǎn)驗(yàn)證跑通基礎(chǔ)升級(jí)之后要考慮的是怎么讓這套東西更接近產(chǎn)品級(jí)。Flash 只有 64KB很多雕花功能做不了但有幾件務(wù)實(shí)的事值得做。5.1 固件加密與簽名從裸數(shù)據(jù)幀到加密幀裸 bin 文件被上位機(jī)直接抓走就能逆向出固件所以量產(chǎn)產(chǎn)品通常會(huì)做一層加密。我在二次開發(fā)時(shí)采用的思路是上位機(jī)把 bin 用 AES-128-CBC 加密密鑰硬編碼在 Bootloader 里升級(jí)時(shí)先傳加密數(shù)據(jù)Bootloader 收到一幀后先解密、再寫入 Flash。解密用軟件實(shí)現(xiàn)STM32F103 的主頻跑 AES 會(huì)慢一點(diǎn)但好在數(shù)據(jù)量不大48KB 的固件多花幾百毫秒可以接受。要注意的是密鑰放 Flash 里只能防外行不能防專業(yè)抄板。真要防篡改得上簽名校驗(yàn)上位機(jī)對(duì)固件做 SHA256 摘要再用私鑰簽個(gè)名Bootloader 里放公鑰驗(yàn)簽。驗(yàn)簽通過(guò)才擦寫。這個(gè)項(xiàng)目里我把簽名設(shè)計(jì)成可選的Bootloader 編譯宏打開才啟用節(jié)省了不必要的時(shí)間開銷。5.2 版本回滾、斷點(diǎn)續(xù)傳與 BKP 記錄Flash 小的務(wù)實(shí)方案C8T6 的 64KB 放不下 A/B 雙系統(tǒng)的大回滾方案但可以實(shí)現(xiàn)小成本回滾升級(jí)前把當(dāng)前運(yùn)行中的 App 關(guān)鍵版本號(hào)記錄在備份寄存器里。STM32F103 的 BKP 寄存器在復(fù)位后不會(huì)丟失App 啟動(dòng)時(shí)讀 BKP 里的版本號(hào)和當(dāng)前固件版本比對(duì)如果發(fā)現(xiàn)版本回退或者寫失敗就主動(dòng)請(qǐng)求重寫。斷點(diǎn)續(xù)傳比回滾更實(shí)用。因?yàn)榇谏?jí)最怕斷斷了要從頭傳。Bootloader 里記錄已經(jīng)寫入的偏移量到 BKP再次上電時(shí)上位機(jī)可以直接從斷點(diǎn)續(xù)傳省掉整包重傳的時(shí)間。這個(gè)功能實(shí)現(xiàn)不復(fù)雜但要改協(xié)議在升級(jí)開始命令里帶上“上次寫入偏移”的查詢幀。5.3 出廠驗(yàn)證的習(xí)慣比功能本身更值錢做完這些擴(kuò)展有個(gè)動(dòng)作是每次都必須做的把整個(gè)驗(yàn)證腳本固化成出廠測(cè)試用例。上電不跳 App 的空白 Flash 測(cè)試、升級(jí)到一半斷電再上電的斷電測(cè)試、下載完成后斷電重啟的驗(yàn)收測(cè)試這三條我每做一個(gè) IAP 工程都會(huì)強(qiáng)制走一遍。源碼包能幫你跑通流程但這三次測(cè)試能幫你確定它在現(xiàn)場(chǎng)不會(huì)翻車。從那以后我每次做升級(jí)功能都堅(jiān)持把這三步寫進(jìn)測(cè)試清單一次都沒(méi)漏過(guò)希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取