簡(jiǎn)介面向華大HC32F460系列微控制器的通用Bootloader設(shè)計(jì)源碼主要服務(wù)于需要實(shí)現(xiàn)固件升級(jí)、程序更新或啟動(dòng)引導(dǎo)的嵌入式開(kāi)發(fā)者既適合產(chǎn)品量產(chǎn)階段的Bootloader移植也適合學(xué)習(xí)MCU底層啟動(dòng)原理。資源包共172個(gè)文件除C源文件和H頭文件外還包含F(xiàn)LM燒錄文件、Keil工程配置文件uvprojx/uvoptx、分散加載文件sct及匯編啟動(dòng)文件等整體壓縮為1.47MB的RAR包文件類型覆蓋編譯、燒錄、調(diào)試各環(huán)節(jié)。目前已有282人學(xué)習(xí)下載代碼結(jié)構(gòu)按模塊劃分便于直接對(duì)照原理圖與數(shù)據(jù)手冊(cè)進(jìn)行二次開(kāi)發(fā)。源碼完整覆蓋Bootloader的兩個(gè)核心階段第一階段完成時(shí)鐘、內(nèi)存映射、中斷向量表等硬件初始化使MCU進(jìn)入穩(wěn)定工作狀態(tài)第二階段通過(guò)UART、SPI或I2C等接口接收固件數(shù)據(jù)并配合CRC校驗(yàn)保證傳輸可靠性再執(zhí)行Flash擦寫與編程操作最終寫入片內(nèi)Flash或片外EEPROM。源碼中還提供了靈活的宏配置選項(xiàng)可通過(guò)修改定義適配不同型號(hào)HC32F460的閃存大小與地址空間并包含初始化、數(shù)據(jù)傳輸、Flash編程等核心函數(shù)可幫助開(kāi)發(fā)者快速理解Bootloader的工作流程縮短產(chǎn)品開(kāi)發(fā)與調(diào)試周期。 我最早被問(wèn)到“HC32F460能不能像STM32那樣做遠(yuǎn)程升級(jí)”時(shí)第一反應(yīng)是直接告訴他去參考AN手冊(cè)。等自己真正在HC32F460上把bootloader跑通之后才意識(shí)到這里面有不少文檔里不會(huì)寫、只有動(dòng)過(guò)手才知道的坑。尤其當(dāng)你面對(duì)的是“通用bootloader”這個(gè)需求——不是給某一個(gè)產(chǎn)品定制而是要能套到后續(xù)多個(gè)項(xiàng)目里——那設(shè)計(jì)思路和臨時(shí)湊一個(gè)方案完全不一樣。這篇內(nèi)容就圍繞我最近整理的一套HC32F460通用bootloader源碼來(lái)寫。它解決的核心問(wèn)題很簡(jiǎn)單串口/其他通信接口升級(jí)固件、上電引導(dǎo)、異常兜底、擦寫保護(hù)。適合正在做HC32F460產(chǎn)品開(kāi)發(fā)、準(zhǔn)備給設(shè)備加升級(jí)功能、或者想把ST項(xiàng)目遷到華大平臺(tái)上的人參考。我會(huì)把設(shè)計(jì)思路、存儲(chǔ)分區(qū)、協(xié)議幀、Flash驅(qū)動(dòng)和跳轉(zhuǎn)細(xì)節(jié)全部拆開(kāi)講尤其是那些你不跑一遍絕對(duì)發(fā)現(xiàn)不了的問(wèn)題。1. 為什么需要一套“通用”bootloader而不是臨時(shí)湊一個(gè)1.1 網(wǎng)上bootloader教程的現(xiàn)狀與ST思維慣性先說(shuō)實(shí)話網(wǎng)上的bootloader教程十篇有八篇是STM32的。STM32的Flash地址從0x08000000開(kāi)始向量表偏移、IAP跳轉(zhuǎn)方案都被講爛了照抄基本能跑。但換成HC32F460之后情況不太一樣它的Flash起始地址是0x00000000SRAM起始地址是0x20000000Flash控制器叫EF模塊讀寫擦除都要走驅(qū)動(dòng)庫(kù)接口而不是直接寄存器一寫就完事。很多人做華大bootloader時(shí)最容易踩的坑就是把STM32那套“設(shè)VTOR、改鏈接腳本、跳轉(zhuǎn)”直接搬過(guò)來(lái)。搬過(guò)來(lái)之后發(fā)現(xiàn)要么App能下載進(jìn)去但一跑就HardFault要么連擦除都失敗。這兩類問(wèn)題的根源往往不是跳轉(zhuǎn)代碼本身而是你在移植時(shí)忽略了兩顆芯片在Flash控制器和啟動(dòng)細(xì)節(jié)上的差異。ST思維里另一個(gè)坑是先用一個(gè)能用的bootloader跑通后面每個(gè)項(xiàng)目都復(fù)制一份改改地址就上。真遇到量產(chǎn)維護(hù)時(shí)就會(huì)很痛——協(xié)議不統(tǒng)一、校驗(yàn)策略不同、入口判定代碼散落各個(gè)工程。所謂“通用”bootloader就是把這些公共邏輯抽出來(lái)做一次沉淀后續(xù)項(xiàng)目只需要改配置頭文件而不是改代碼邏輯。1.2 通用bootloader的職責(zé)邊界引導(dǎo)、傳輸、升級(jí)、校驗(yàn)我在設(shè)計(jì)這套源碼時(shí)先給自己劃了一條邊界bootloader不處理任何業(yè)務(wù)邏輯不關(guān)心App具體是做什么的只負(fù)責(zé)四件事——引導(dǎo)、傳輸、升級(jí)、校驗(yàn)。引導(dǎo)上電后判斷App區(qū)是否有效有效就跳轉(zhuǎn)無(wú)效就等待升級(jí)命令。傳輸定義一套健壯的通信協(xié)議負(fù)責(zé)收固件數(shù)據(jù)。升級(jí)把收到的數(shù)據(jù)按扇區(qū)擦除、按單元寫入刷進(jìn)App區(qū)。校驗(yàn)整個(gè)固件包傳輸完成后做完整性校驗(yàn)通過(guò)才允許跳轉(zhuǎn)。這四個(gè)模塊之間是解耦的。底層通信接口可以是串口也可以換成CAN、USB只要對(duì)上層的“接收一幀、發(fā)送一幀”接口就行。這套源碼里我把串口作為默認(rèn)實(shí)現(xiàn)同時(shí)把傳輸層抽象成一組回調(diào)想換通道只需要實(shí)現(xiàn)read/write兩個(gè)函數(shù)。這樣后續(xù)項(xiàng)目就算換了通信介質(zhì)bootloader主體一行都不用動(dòng)。1.3 HC32F460的硬件特性決定了哪些設(shè)計(jì)決策HC32F460這顆芯片的基本盤是Cortex-M4F最高主頻200MHzFlash最大1MBSRAM最大192KB。對(duì)于跑bootloader來(lái)說(shuō)這些資源非常充裕。但有幾個(gè)硬件特性直接影響設(shè)計(jì)決策。首先是Flash擦寫機(jī)制。HC32F460的Flash不支持按字節(jié)擦除最小擦除單位是扇區(qū)不同地址區(qū)域的扇區(qū)大小不一樣。編程操作可以按字32bit寫入但要求寫入前對(duì)應(yīng)地址已經(jīng)被擦除。這意味著bootloader接收固件數(shù)據(jù)時(shí)不能邊收邊寫必須先把一個(gè)完整扇區(qū)的數(shù)據(jù)緩沖到RAM等收滿后一次擦除、一次寫入。這套源碼里我用了一個(gè)可配置的緩沖區(qū)默認(rèn)支持8KB的扇區(qū)緩沖。其次是中斷向量表。Cortex-M4內(nèi)核提供了SCB-VTOR寄存器用于重定向向量表地址。App區(qū)起始地址一旦確定App工程的鏈接腳本ROM入口地址和向量表偏移必須保持一致否則中斷全部跑飛。這屬于兩個(gè)工程要配合的事后面第5章我會(huì)詳細(xì)說(shuō)。還有一個(gè)容易被忽略的是硬件CRC模塊。HC32F460的CRC單元可以算CRC32省去了軟件查表的時(shí)間和代碼量。固件校驗(yàn)用它來(lái)做速度很快整包1MB數(shù)據(jù)校驗(yàn)時(shí)間可以忽略不計(jì)。2. 存儲(chǔ)分區(qū)方案與升級(jí)流程設(shè)計(jì)2.1 Flash分區(qū)布局Boot區(qū)、App區(qū)、參數(shù)區(qū)的劃分分區(qū)是整個(gè)bootloader設(shè)計(jì)的地基分區(qū)定了后面所有邏輯才有依據(jù)。我在這套源碼里采用的是三段式布局Bootloader區(qū)、Application區(qū)、Parameter區(qū)。以HC32F460最大1MB Flash為例推薦劃分如下區(qū)域起始地址大小說(shuō)明Bootloader區(qū)0x0000000064KB存放bootloader固件上電從該區(qū)域啟動(dòng)Application區(qū)0x00010000896KB或按需存放App固件入口地址和向量表偏移都基于此Parameter區(qū)0x000F000064KB存放升級(jí)標(biāo)志、版本信息、CRC校驗(yàn)值、斷點(diǎn)續(xù)傳記錄這個(gè)劃分不是拍腦袋定的。64KB的Bootloader區(qū)對(duì)HC32F460來(lái)說(shuō)非常充裕因?yàn)閎ootloader全功能編譯下來(lái)一般也就二三十KB留一倍余量是為了以后加加密升級(jí)、日志記錄擴(kuò)展時(shí)不至于推翻重來(lái)。App區(qū)起始地址0x00010000正好處于64KB邊界處對(duì)不同F(xiàn)lash容量的型號(hào)都友好。Parameter區(qū)單獨(dú)劃出來(lái)非常關(guān)鍵。它用來(lái)保存“升級(jí)狀態(tài)標(biāo)志”。舉例來(lái)說(shuō)App啟動(dòng)時(shí)會(huì)把一個(gè)特殊標(biāo)志字寫入Parameter區(qū)下次復(fù)位bootloader啟動(dòng)時(shí)讀到這個(gè)標(biāo)志就知道“上次App已經(jīng)跑起來(lái)了不需要進(jìn)入升級(jí)模式”。反過(guò)來(lái)如果固件下載了一半就掉電Parameter區(qū)里的標(biāo)志不會(huì)被清理bootloader上電后能識(shí)別出“上次升級(jí)沒(méi)完成”從而不跳轉(zhuǎn)、繼續(xù)等待升級(jí)。這個(gè)小設(shè)計(jì)能大幅降低現(xiàn)場(chǎng)變磚的概率。2.2 升級(jí)狀態(tài)機(jī)從啟動(dòng)到完成的完整狀態(tài)流轉(zhuǎn)分區(qū)只解決“放哪里”的問(wèn)題而啟動(dòng)邏輯要解決的是“往哪走”。這套源碼里我把bootloader的行為實(shí)現(xiàn)為一個(gè)狀態(tài)機(jī)IDLE啟動(dòng)后默認(rèn)狀態(tài)。讀取Parameter區(qū)的標(biāo)志和App區(qū)的有效性判定是跳轉(zhuǎn)App還是等待升級(jí)。WAIT_FRAME進(jìn)入升級(jí)模式后等待主機(jī)發(fā)送握手包。握手成功后才允許后續(xù)擦寫操作。RECEIVING按幀接收固件數(shù)據(jù)每幀校驗(yàn)CRC后寫入緩沖緩沖區(qū)滿或者收到扇區(qū)結(jié)束幀時(shí)執(zhí)行擦寫。VERIFYING整包收完后對(duì)App區(qū)數(shù)據(jù)做CRC/累加和校驗(yàn)與固件包頭聲明的校驗(yàn)值比對(duì)。JUMP_READY校驗(yàn)通過(guò)后置位App有效標(biāo)志延時(shí)或直接復(fù)位跳轉(zhuǎn)到App。在實(shí)際實(shí)現(xiàn)時(shí)IDLE狀態(tài)還需要處理“超時(shí)跳轉(zhuǎn)”——也就是上電后如果沒(méi)有主機(jī)主動(dòng)連上來(lái)等幾百毫秒直接跳轉(zhuǎn)App保證設(shè)備正常啟動(dòng)速度不受影響。不要小看這幾百毫秒很多產(chǎn)品對(duì)冷啟動(dòng)時(shí)間有硬指標(biāo)拖太久會(huì)被提bug。此外參數(shù)區(qū)建議寫入“固件版本號(hào)固件長(zhǎng)度固件CRC”。版本號(hào)用于主機(jī)查詢后決定要不要升級(jí)固件長(zhǎng)度用于bootloader判斷整包收齊CRC是最終校驗(yàn)的依據(jù)。三者缺一不可。2.3 “通用”的關(guān)鍵分區(qū)地址和容量全部走配置宏通用bootloader最大的敵人是寫死的地址。如果你把App起始地址直接寫成0x00010000換一個(gè)Flash只有256KB的型號(hào)這套代碼就廢了。所以我在這套源碼里把分區(qū)信息全部收斂到一個(gè)頭文件里例如#define APP_BASE_ADDR 0x00010000u #define APP_MAX_SIZE 0x000E0000u #define PARAM_BASE_ADDR 0x000F0000u #define BOOT_HEAD_MAGIC 0xA55A5AA5u后續(xù)新項(xiàng)目只需要改這個(gè)配置頭不用動(dòng)任何邏輯代碼。這看起來(lái)是個(gè)簡(jiǎn)單的工程規(guī)范但在實(shí)際項(xiàng)目里我見(jiàn)過(guò)太多人把地址散在七八個(gè).c文件里升級(jí)一次Flash容量要全局搜索替換相當(dāng)痛苦。3. 通信協(xié)議與傳輸容錯(cuò)機(jī)制3.1 幀格式設(shè)計(jì)幀頭、命令、長(zhǎng)度、載荷、CRCbootloader的通信協(xié)議不需要像業(yè)務(wù)協(xié)議那么花哨但健壯性必須拉滿。因?yàn)檫@可能是產(chǎn)品出廠后唯一能救磚的通道一旦協(xié)議脆弱現(xiàn)場(chǎng)升級(jí)失敗就沒(méi)法收拾。我設(shè)計(jì)的幀格式長(zhǎng)這樣字節(jié)偏移字段長(zhǎng)度說(shuō)明0幀頭2B固定值 0xA5 0x5A2命令字1B見(jiàn)下方命令枚舉3包序號(hào)2B用于丟包重傳和亂序檢測(cè)5數(shù)據(jù)長(zhǎng)度2B載荷部分的字節(jié)數(shù)大端7數(shù)據(jù)載荷N最大256B7NCRC324B從幀頭到載荷末尾的CRC32幀頭用兩字節(jié)是為了避免單字節(jié)誤判。0xA5 0x5A這個(gè)組合不是隨便定的它在串口空閑狀態(tài)下不容易被噪聲隨機(jī)組合出來(lái)。包序號(hào)則是實(shí)現(xiàn)斷點(diǎn)續(xù)傳和重傳的重要依據(jù)接收端只需要檢查序號(hào)是否連續(xù)就知道有沒(méi)有丟幀。命令字這一層我定義了一組最小集合CMD_HANDSHAKE0x01主機(jī)查詢bootloader是否存在返回bootloader版本和協(xié)議版本。CMD_GET_STATUS0x02查詢當(dāng)前升級(jí)狀態(tài)、已寫入偏移。CMD_ERASE0x03擦除指定扇區(qū)。扇區(qū)參數(shù)由主機(jī)下發(fā)避免bootloader自己去算。CMD_WRITE0x04攜帶固件數(shù)據(jù)bootloader收到后寫入緩沖。CMD_CRC_CHECK0x05請(qǐng)求bootloader對(duì)App區(qū)執(zhí)行CRC校驗(yàn)并返回結(jié)果。CMD_JUMP_APP0x06校驗(yàn)通過(guò)后觸發(fā)跳轉(zhuǎn)。CMD_RESET0x07軟件復(fù)位。這套命令集很小但覆蓋了升級(jí)全流程。實(shí)現(xiàn)時(shí)注意一點(diǎn)任何命令處理完成后都要回ACK幀回不去就說(shuō)明鏈路有問(wèn)題主機(jī)側(cè)要能根據(jù)超時(shí)判斷重發(fā)。3.2 傳輸層抽象串口/CAN/USB如何納入同一套框架“通用”不能只停留在嘴上。我常在項(xiàng)目里遇到這種情況A產(chǎn)品用串口升級(jí)B產(chǎn)品板子上沒(méi)有串口只有CANC產(chǎn)品用的是USB。如果你為每種介質(zhì)各寫一套協(xié)議解析那維護(hù)量立刻翻倍。解決辦法是把傳輸層抽象成三個(gè)接口typedef struct { int (*init)(void); int (*send)(const uint8_t *buf, uint32_t len); int (*recv)(uint8_t *buf, uint32_t len, uint32_t timeout_ms); void (*irq_handler)(void); } boot_transport_t;協(xié)議解析層只跟這組接口打交道。以串口為例recv從環(huán)形緩沖區(qū)取數(shù)據(jù)send走UART發(fā)送換成CAN后recv負(fù)責(zé)CAN報(bào)文去幀頭幀尾后拼裝成字節(jié)流send做相反的處理。上層協(xié)議幀的解析代碼完全不用動(dòng)。這樣設(shè)計(jì)還有一個(gè)額外好處調(diào)試階段你可以用一個(gè)loopback_transport做純協(xié)議測(cè)試不依賴真實(shí)硬件先把協(xié)議邏輯跑通再聯(lián)調(diào)驅(qū)動(dòng)。3.3 容錯(cuò)設(shè)計(jì)超時(shí)重傳、斷點(diǎn)續(xù)傳、校驗(yàn)兜底通信協(xié)議設(shè)計(jì)得再干凈物理鏈路總會(huì)出問(wèn)題。我總結(jié)了三個(gè)必須在bootloader里實(shí)現(xiàn)的容錯(cuò)機(jī)制。超時(shí)重傳主機(jī)每發(fā)一幀后等待ACK超過(guò)設(shè)定的時(shí)間比如500ms就重發(fā)同一幀。bootloader收到重復(fù)幀時(shí)直接回復(fù)ACK即可不需要做什么特殊處理保證冪等。斷點(diǎn)續(xù)傳這是現(xiàn)場(chǎng)升級(jí)神器。思路很簡(jiǎn)單——bootloader每次成功處理完一幀后把“下一幀期待序號(hào)”記錄到Parameter區(qū)。升級(jí)被打斷后重新握手主機(jī)會(huì)先發(fā)CMD_GET_STATUS拿到已經(jīng)寫到的偏移然后從這個(gè)位置繼續(xù)傳。對(duì)動(dòng)不動(dòng)要傳幾百KB固件的場(chǎng)景來(lái)說(shuō)斷點(diǎn)續(xù)傳能把升級(jí)失敗率從“一言不合從頭傳”降到一個(gè)很可接受的水平。校驗(yàn)兜底每一幀有CRC32傳輸完整性整包完成后還有一次全量CRC數(shù)據(jù)一致性。兩個(gè)校驗(yàn)缺一不可。幀級(jí)校驗(yàn)保證接收過(guò)程不受干擾整包校驗(yàn)保證固件包本身沒(méi)有損壞也不能出現(xiàn)“差一幀但每幀都合法”的情況。4. Flash底層驅(qū)動(dòng)HC32F460的擦寫要點(diǎn)與踩坑記錄4.1 EF模塊規(guī)律解鎖、擦除、編程的時(shí)序邏輯HC32F460的Flash操作走的是EFEmbedded Flash模塊。驅(qū)動(dòng)庫(kù)DDL里封裝了初始化、擦除、編程相關(guān)的接口但有幾件事庫(kù)函數(shù)不會(huì)替你處理。首先是解鎖。和很多MCU一樣EF模塊寫操作前需要先解鎖。解鎖操作要按寄存器要求的時(shí)序?qū)懭胩囟ǖ腒EY值一旦時(shí)序不對(duì)后續(xù)操作直接無(wú)效。更麻煩的是Flash操作期間如果來(lái)了優(yōu)先級(jí)較高的中斷可能導(dǎo)致擦寫時(shí)序被破壞。所以我的做法是在flash擦寫期間關(guān)掉可屏蔽中斷避免一切干擾。其次是等待周期。系統(tǒng)主頻跑在200MHz時(shí)CPU訪問(wèn)Flash需要配置等待周期。bootloader跑的是Flash代碼如果等待周期配置不正確輕則Flash讀取異常重則直接HardFault。很多移植STM32代碼的人在這里翻車因?yàn)镾TM32的運(yùn)行時(shí)鐘往往最高才72M等待周期問(wèn)題沒(méi)有那么敏感。還有一點(diǎn)容易被忽略HC32F460的Flash擦寫命令發(fā)起后CPU會(huì)等待操作完成。這個(gè)期間代碼能不能繼續(xù)執(zhí)行取決于驅(qū)動(dòng)庫(kù)的實(shí)現(xiàn)——有的庫(kù)用阻塞等待狀態(tài)寄存器有的庫(kù)會(huì)先觸發(fā)命令再輪詢。真正常見(jiàn)的坑是中斷里發(fā)起Flash操作導(dǎo)致中斷延時(shí)不可控。所以我嚴(yán)格執(zhí)行“Flash操作只在主循環(huán)里做不在中斷里做”的原則。4.2 緩沖與地址對(duì)齊為什么不能按字節(jié)流傻寫HC32F460的Flash編程是按32位字寫入的。這意味著你從串口收到的固件數(shù)據(jù)即使是一個(gè)字節(jié)一個(gè)字節(jié)來(lái)的寫入Flash前也必須攢夠32位而且寫入地址必須四字節(jié)對(duì)齊。我在這套源碼里做了一層簡(jiǎn)單的緩沖拼接邏輯收到一幀數(shù)據(jù)后先把載荷拷貝到RAM緩沖同時(shí)把緩沖長(zhǎng)度和上一幀剩余未對(duì)齊的字節(jié)拼起來(lái)。等緩沖中的數(shù)據(jù)滿足一次32位編程條件時(shí)再調(diào)用驅(qū)動(dòng)庫(kù)的寫接口。這樣既滿足了Flash硬件對(duì)齊要求又不需要強(qiáng)制主機(jī)側(cè)按固定長(zhǎng)度分包。還有一個(gè)工程問(wèn)題擦除粒度。前面說(shuō)了HC32F460不同區(qū)域的扇區(qū)大小不一致所以擦除指令下發(fā)時(shí)bootloader必須根據(jù)目標(biāo)地址找到所屬扇區(qū)索引然后決定擦除的起始地址和長(zhǎng)度。這個(gè)換算邏輯我封裝成了一個(gè)查找函數(shù)它內(nèi)部維護(hù)一張扇區(qū)表。換型號(hào)時(shí)只要替換扇區(qū)表數(shù)據(jù)即可。4.3 一次真實(shí)的擦寫翻車在調(diào)試器下擦寫Flash導(dǎo)致HardFault這里分享一個(gè)值得復(fù)現(xiàn)的排查過(guò)程?，F(xiàn)象是bootloader在接收到擦除命令后只要執(zhí)行扇區(qū)擦除系統(tǒng)就進(jìn)HardFault。但在線調(diào)試時(shí)單步執(zhí)行又是正常的。排查鏈路是這樣的第一反應(yīng)是懷疑擦除參數(shù)寫錯(cuò)了比如扇區(qū)起始地址算錯(cuò)。但單步執(zhí)行時(shí)沒(méi)問(wèn)題全速跑就掛這不太像參數(shù)問(wèn)題。然后懷疑中斷干擾。我檢查了工程里所有中斷的優(yōu)先級(jí)特別是SysTick和串口接收中斷。SysTick在打印日志時(shí)會(huì)被頻繁觸發(fā)如果它在Flash擦除窗口期間打斷時(shí)序確實(shí)可能導(dǎo)致異常。于是我把Flash擦寫保護(hù)起來(lái)在進(jìn)入函數(shù)前關(guān)閉SysTick擦完再恢復(fù)。問(wèn)題依然存在。后來(lái)我把__disable_irq()加上了還是不行。最后想到一個(gè)可能性是不是調(diào)試器本身在單步時(shí)做了某種“掩護(hù)”于是斷開(kāi)調(diào)試器、讓芯片獨(dú)立上電跑。結(jié)果發(fā)現(xiàn)HardFault不再出現(xiàn)升級(jí)流程順利走通。復(fù)盤原因調(diào)試器連接時(shí)SWD接口和EF模塊存在總線訪問(wèn)競(jìng)爭(zhēng)在全速運(yùn)行狀態(tài)下調(diào)試器的后臺(tái)訪問(wèn)比如刷新內(nèi)存窗口可能打斷Flash操作的關(guān)鍵時(shí)序段。這個(gè)問(wèn)題的排查花費(fèi)了我不少時(shí)間但也讓我養(yǎng)成了習(xí)慣——驗(yàn)證bootloader的行為一定要斷開(kāi)仿真器單獨(dú)跑至少要用“脫機(jī)運(yùn)行”模式驗(yàn)證一遍。凡是涉及Flash擦寫的邏輯在仿真器連接下測(cè)試的結(jié)果只能作為參考不能作為最終結(jié)論。5. 跳轉(zhuǎn)邏輯與中斷向量重映射最容易翻車的地方5.1 跳轉(zhuǎn)前的“五大臟活”關(guān)中斷、關(guān)外設(shè)、復(fù)位時(shí)基、重設(shè)棧頂、校驗(yàn)入口跳轉(zhuǎn)App看似只是一行函數(shù)指針調(diào)用但實(shí)際上在跳轉(zhuǎn)之前有一堆“臟活”要干。我總結(jié)成五件事按順序執(zhí)行其一關(guān)閉全局中斷。進(jìn)入跳轉(zhuǎn)前必須執(zhí)行__disable_irq()同時(shí)把已打開(kāi)的外設(shè)中斷逐個(gè)關(guān)閉。原因是bootloader里用到的外設(shè)如串口如果還開(kāi)著中斷跳轉(zhuǎn)后App沒(méi)有初始化這些外設(shè)中斷一旦觸發(fā)就會(huì)因?yàn)橹袛喾?wù)函數(shù)地址不對(duì)而跑飛。其二關(guān)閉外設(shè)時(shí)鐘。把用到的UART、DMA、SysTick等外設(shè)的時(shí)鐘關(guān)閉并恢復(fù)到復(fù)位默認(rèn)狀態(tài)。這能避免外設(shè)殘留狀態(tài)干擾App的初始化。其三復(fù)位系統(tǒng)時(shí)基。SysTick在bootloader里往往作為延時(shí)工具在用如果帶著SysTick的計(jì)數(shù)值跳轉(zhuǎn)App里對(duì)SysTick的初始化結(jié)果就可能不對(duì)。其四重設(shè)主堆棧指針MSP。App工程編譯后起始地址處的前四個(gè)字節(jié)就是初始棧頂值。跳轉(zhuǎn)前要把MSP設(shè)置成這個(gè)值。其五校驗(yàn)入口地址合法性。凡是跳轉(zhuǎn)前必須檢查App入口地址是否落在Flash地址范圍內(nèi)如果入口地址是0xFFFFFFFF或者落在SRAM區(qū)說(shuō)明App區(qū)根本沒(méi)有有效固件此時(shí)跳轉(zhuǎn)必死無(wú)疑。這五件事的順序也有講究先關(guān)中斷再關(guān)外設(shè)先設(shè)棧頂再跳轉(zhuǎn)。順序反了某些情況下會(huì)出詭異問(wèn)題。5.2 向量表偏移的兩條路SCB-VTOR寄存器與鏈接腳本的配合Cortex-M4內(nèi)核的向量表偏移是通過(guò)SCB-VTOR寄存器控制的。App燒錄在0x00010000bootloader跳轉(zhuǎn)之前就要執(zhí)行SCB-VTOR APP_BASE_ADDR; __DSB(); __ISB();這段代碼大部分人都知道寫。但容易忽略的是App工程側(cè)也必須做同樣的事。App的啟動(dòng)文件里會(huì)有一段中斷向量表編譯器默認(rèn)將向量表放在ROM起始地址處。如果App鏈接腳本里依然把ROM起始地址設(shè)為0x00000000那么即使bootloader設(shè)置了VTORApp的中斷向量表實(shí)際存放在0x00000000與VTOR指向的0x00010000不一致中斷生效時(shí)根本找不到處理函數(shù)。所以App工程的鏈接腳本必須做兩個(gè)修改一是ROM起始地址改為App區(qū)基地址二是向量表在編譯后存放在鏈接腳本指定的地址處。很多“bootloader跳轉(zhuǎn)成功了但App一直卡死”的提問(wèn)八成都是這里沒(méi)配合好。還有一個(gè)比較細(xì)的地方清除流水線。設(shè)置完VTOR后執(zhí)行__DSB()和__ISB()。DSB確保前面的寫操作完成ISB清空流水線讓后面取指使用新的向量表。不要省這兩條指令我有一次圖省事刪掉了結(jié)果就是偶發(fā)性跳轉(zhuǎn)失敗復(fù)現(xiàn)極難排查。5.3 App側(cè)必須配合的三件事很多bootloader“成功”了但App跑不了的原因跳轉(zhuǎn)邏輯全對(duì)還不夠App側(cè)也要配合。我把經(jīng)驗(yàn)總結(jié)成三件事缺一不可。第一件事App的鏈接腳本ROM起始地址要設(shè)置正確。如果App燒錄在0x00010000鏈接腳本里FLASH的起始地址必須是0x00010000長(zhǎng)度相應(yīng)縮小。否則編譯出來(lái)的鏡像自帶0x00000000的起始信息燒到App區(qū)后入口跳轉(zhuǎn)面對(duì)的是一個(gè)“假地址”上的代碼。第二件事App外部中斷使能前先確認(rèn)SRAM區(qū)和外設(shè)狀態(tài)。bootloader跳轉(zhuǎn)前雖然關(guān)了外設(shè)但某些外設(shè)的配置寄存器可能還帶著bootloader留下的值。嚴(yán)謹(jǐn)?shù)淖龇ㄊ茿pp初始化函數(shù)一開(kāi)始就執(zhí)行系統(tǒng)級(jí)的SystemInit()把時(shí)鐘、總線配置恢復(fù)成已知狀態(tài)。第三件事如果App用了RTOS比如FreeRTOS在移植時(shí)要把vPortSVCHandler、xPortPendSVHandler等函數(shù)注冊(cè)到正確的中斷向量表位置。RTOS跑不起來(lái)往往不是因?yàn)閎ootloader而是App自己的向量表里這些鉤子沒(méi)配對(duì)。6. 調(diào)試心得與可復(fù)用經(jīng)驗(yàn)清單6.1 用調(diào)試器的memory窗口驗(yàn)證跳轉(zhuǎn)前的現(xiàn)場(chǎng)跳轉(zhuǎn)問(wèn)題調(diào)試起來(lái)很頭疼因?yàn)橐坏┨D(zhuǎn)失敗你連斷點(diǎn)都打不進(jìn)去。我的經(jīng)驗(yàn)是在跳轉(zhuǎn)函數(shù)入口處設(shè)置斷點(diǎn)然后在調(diào)試器的memory窗口手動(dòng)查看App起始地址處的前兩個(gè)32位值。第一個(gè)值應(yīng)當(dāng)是有效的SRAM地址0x20000000開(kāi)頭第二個(gè)值應(yīng)當(dāng)是Flash區(qū)內(nèi)地址如0x0001xxxx。如果這兩個(gè)值長(zhǎng)得不像說(shuō)明App區(qū)燒錄的鏡像本身就是錯(cuò)的——常見(jiàn)原因不是“bootloader跳不過(guò)去”而是“App鏡像鏈接地址就沒(méi)搞對(duì)”。這種前置檢查能幫你快速把問(wèn)題定位到App工程少走很多彎路。另外在跳轉(zhuǎn)后的第一行代碼App的Reset_Handler入口也設(shè)一個(gè)斷點(diǎn)。如果斷點(diǎn)生效說(shuō)明跳轉(zhuǎn)物理路徑已經(jīng)通了。剩下的問(wèn)題就是觀察App的初始化流程在哪一步掛掉那已經(jīng)是App側(cè)的問(wèn)題了。6.2 軟件觸發(fā)進(jìn)入bootloader的三種姿勢(shì)除了物理按鍵和主機(jī)主動(dòng)握手軟件觸發(fā)進(jìn)bootloader的方式也很有用我整理了三種常見(jiàn)姿勢(shì)一是RAM標(biāo)志位加軟復(fù)位。App在跳轉(zhuǎn)復(fù)位前往一個(gè)特定的RAM地址寫一個(gè)魔法數(shù)比如0xA55A0001然后執(zhí)行NVIC_SystemReset()。bootloader啟動(dòng)后檢查這個(gè)RAM地址發(fā)現(xiàn)魔法數(shù)就進(jìn)入升級(jí)模式。注意RAM里的數(shù)據(jù)在軟復(fù)位后會(huì)保留只要不復(fù)位內(nèi)存所以這個(gè)方案可行且速度很快。二是引腳電平判定。在bootloader啟動(dòng)階段檢測(cè)一個(gè)外部引腳的輸入電平比如平時(shí)拉高需要升級(jí)時(shí)拉低再上電。這個(gè)方案對(duì)沒(méi)有通信上位機(jī)配合的場(chǎng)景比較友好但會(huì)多占用一個(gè)GPIO。三是超時(shí)等待。bootloader上電后打開(kāi)串口接收等待主機(jī)的握手幀同時(shí)開(kāi)啟一個(gè)定時(shí)器比如500ms。超時(shí)未收到有效握手幀直接跳轉(zhuǎn)App。這個(gè)方案不影響正常啟動(dòng)速度也不需要額外硬件是我優(yōu)先級(jí)最高的默認(rèn)方案。實(shí)際項(xiàng)目里大多組合使用默認(rèn)超時(shí)跳轉(zhuǎn)同時(shí)支持外部命令主動(dòng)進(jìn)入升級(jí)模式。6.3 常見(jiàn)問(wèn)題快速排查表最后整理一個(gè)排查表。這些全是我在這套源碼調(diào)試和移植過(guò)程中碰到過(guò)的問(wèn)題分享出來(lái)幫大家省時(shí)間現(xiàn)象可能原因解決思路跳轉(zhuǎn)后直接HardFault入口地址校驗(yàn)沒(méi)做/棧頂指針?lè)欠z查App起始處前4字節(jié)是否0x2000開(kāi)頭App能跑但所有中斷不響應(yīng)VTOR設(shè)置和App鏈接腳本不一致確認(rèn)App鏈接腳本ROM起始地址VTOR值Flash擦除后讀回全FF擦除參數(shù)/扇區(qū)表錯(cuò)誤核對(duì)扇區(qū)起始地址和長(zhǎng)度Flash寫入后數(shù)據(jù)不對(duì)未先擦除或字節(jié)對(duì)齊有問(wèn)題確認(rèn)先擦后寫、32位對(duì)齊升級(jí)一包就斷幀同步丟失超時(shí)設(shè)置過(guò)短檢查幀頭匹配邏輯延長(zhǎng)ACK等待時(shí)間掉電重啟后回不到App升級(jí)標(biāo)志未正確清理檢查Parameter區(qū)標(biāo)志更新邏輯在線調(diào)試正常、脫機(jī)必掛調(diào)試器后臺(tái)訪問(wèn)干擾EF時(shí)序以脫機(jī)運(yùn)行為準(zhǔn)6.4 從這套源碼里沉淀出的兩個(gè)工程習(xí)慣調(diào)試完這套bootloader之后我養(yǎng)成了兩個(gè)工程習(xí)慣順帶分享出來(lái)。第一個(gè)習(xí)慣任何涉及Flash地址的改動(dòng)先畫一張分區(qū)表貼在工程目錄的README里。這個(gè)看起來(lái)不起眼但當(dāng)你過(guò)了兩三個(gè)月再回來(lái)看代碼時(shí)分區(qū)表就是最有效的設(shè)計(jì)文檔。很多事故都源于“我記得App區(qū)是從0x00010000開(kāi)始的”實(shí)際上早就改了。第二個(gè)習(xí)慣bootloader與App之間要約定一個(gè)固定位置的版本描述結(jié)構(gòu)體。App編譯時(shí)把固件版本號(hào)、編譯時(shí)間、入口地址填充到一個(gè)結(jié)構(gòu)體里并放置到App鏡像頭部固定偏移處。bootloader讀取這個(gè)結(jié)構(gòu)體就能在升級(jí)前后打印版本對(duì)比不用再額外維護(hù)數(shù)據(jù)庫(kù)。這個(gè)設(shè)計(jì)對(duì)產(chǎn)線升級(jí)和售后排查都非常實(shí)用。如果只讓我在這套HC32F460 bootloader的設(shè)計(jì)里挑一條最值得記住的經(jīng)驗(yàn)?zāi)蔷褪莃ootloader的本質(zhì)不是“跳轉(zhuǎn)代碼”而是一套完整的異?；謴?fù)機(jī)制。分區(qū)表是后路協(xié)議是通道校驗(yàn)是兜底跳轉(zhuǎn)只是最后一步。把這套機(jī)制設(shè)計(jì)好后續(xù)哪怕?lián)Q芯片換平臺(tái)核心思路依然能復(fù)用。本文還有配套的精品資源點(diǎn)擊獲取