1. Bootloader項(xiàng)目到底解決什么問題1.1 為什么要做CAN Bootloader先交代一下背景。我這邊做的產(chǎn)品是分布式的車載電控單元主控用的STM32F103系列節(jié)點(diǎn)之間走CAN總線。早期固件升級(jí)都是人工拿著ST-Link挨個(gè)開蓋刷寫一條產(chǎn)線幾十個(gè)節(jié)點(diǎn)一遍刷下來少說一個(gè)多小時(shí)而且后裝市場(chǎng)返修更頭疼——設(shè)備已經(jīng)封在機(jī)殼里有些還打了膠壓根沒法拆。這時(shí)候遠(yuǎn)程升級(jí)就成了剛需而CAN總線恰恰是現(xiàn)成的通道。STM32F103在國(guó)產(chǎn)化替代和低成本項(xiàng)目里用得非常多芯片本身自帶CAN外設(shè)支持標(biāo)準(zhǔn)幀和擴(kuò)展幀波特率可配硬件上只要加一個(gè)CAN收發(fā)器比如TJA1050、SN65HVD230就能跑起來。所以我就把Bootloader方案定成了“CAN Bootloader”上電先跑一段IAP程序通過CAN總線接收升級(jí)包寫入內(nèi)部Flash完成后跳轉(zhuǎn)到APP執(zhí)行。整個(gè)過程不需要額外的下載器只需要一個(gè)USBCAN卡或者現(xiàn)場(chǎng)總線上的上位機(jī)節(jié)點(diǎn)就能完成。做這件事之前我踩過一個(gè)認(rèn)知誤區(qū)以為Bootloader就是寫一段“把接收到的數(shù)據(jù)往Flash里寫”的代碼結(jié)果第一版出來問題一大堆——跳轉(zhuǎn)過去就死機(jī)、寫到一半寫不進(jìn)去、升級(jí)中斷后設(shè)備變磚。后來才明白Bootloader看起來簡(jiǎn)單實(shí)際涉及Flash分區(qū)規(guī)劃、中斷向量表遷移、CAN協(xié)議設(shè)計(jì)、異?；謴?fù)機(jī)制、量產(chǎn)防呆設(shè)計(jì)一堆事。這篇文章把我在這個(gè)項(xiàng)目里的完整實(shí)踐拆開講從協(xié)議、源碼、調(diào)試到量產(chǎn)落地一條線捋清楚。1.2 方案選型為什么是CAN而不是UART很多教程講Bootloader都喜歡用UART因?yàn)楹?jiǎn)單一個(gè)串口加一個(gè)USB轉(zhuǎn)TTL就能演示。但在整車和工業(yè)現(xiàn)場(chǎng)場(chǎng)景里UART有幾個(gè)致命問題第一很多設(shè)備沒有拉出串口引腳或者串口被其他功能占用。第二RS232/TTL抗干擾能力弱線纜一長(zhǎng)誤碼率就上來而工業(yè)現(xiàn)場(chǎng)動(dòng)輒幾米甚至幾十米線束。第三整車上已經(jīng)是CAN網(wǎng)絡(luò)了單獨(dú)為升級(jí)再拉一條調(diào)試串口產(chǎn)線和售后都要多一套硬件。CAN的優(yōu)勢(shì)是物理層本身就是差分信號(hào)抗干擾強(qiáng)通信距離遠(yuǎn)而且天然支持多節(jié)點(diǎn)組網(wǎng)。同一根總線上的設(shè)備可以通過ID過濾只響應(yīng)升級(jí)指令其他節(jié)點(diǎn)正常工作不受影響。對(duì)于量產(chǎn)部署來說CAN還有一個(gè)好處產(chǎn)線測(cè)試本來就要通過CAN做EOLEnd of Line檢測(cè)升級(jí)功能可以直接復(fù)用同一套工裝和線束。另外從成本角度看F103的CAN外設(shè)幾乎是“白送”的不需要額外加芯片。唯一要注意的是CAN收發(fā)器選型我建議用帶隔離的模塊比如CTM1050產(chǎn)線上經(jīng)常有設(shè)備接地不一致的問題隔離模塊能直接把共模干擾攔在物理層外面少很多莫名其妙的通信故障。1.3 整體架構(gòu)與功能拆解這個(gè)項(xiàng)目最終落地的系統(tǒng)架構(gòu)分成三層第一層是上位機(jī)/產(chǎn)線工裝。我這邊用的是周立功USBCAN-II上位機(jī)軟件自己用C#寫了一個(gè)簡(jiǎn)單的升級(jí)工具通過CAN發(fā)送升級(jí)包。如果現(xiàn)場(chǎng)總線里已經(jīng)有主節(jié)點(diǎn)在做調(diào)度也可以讓主節(jié)點(diǎn)兼任升級(jí)發(fā)起方。第二層是Bootloader程序放在STM32F103內(nèi)部Flash的起始區(qū)域。它負(fù)責(zé)上電初始化CAN、等待升級(jí)指令、接收固件包、擦寫Flash、校驗(yàn)、跳轉(zhuǎn)。第三層是APP應(yīng)用程序放在了Flash的高地址區(qū)。APP里面也要配合做一件事把中斷向量表重映射到自己的起始地址否則中斷一進(jìn)來就跑到Bootloader里去了。整個(gè)升級(jí)流程大概是這樣設(shè)備上電先跑Bootloader如果是冷啟動(dòng)并且沒有收到升級(jí)指令就延時(shí)幾百毫秒后直接跳轉(zhuǎn)到APP如果收到了升級(jí)幀或者APP區(qū)無效就留在Bootloader等待完整升級(jí)包。升級(jí)指令體一般包括握手、開始傳輸、數(shù)據(jù)幀、結(jié)束幀、校驗(yàn)結(jié)果回讀這幾類。2. 核心原理Flash分區(qū)與程序跳轉(zhuǎn)機(jī)制2.1 STM32F103內(nèi)部Flash布局與分區(qū)STM32F103的內(nèi)部Flash從0x08000000開始大小因型號(hào)而異比如F103C8T6是64KBF103RCT6是256KBF103ZET6是512KB。Flash的擦除以頁為單位注意不同容量的頁大小不一樣小容量和中容量64KB以下是1KB一頁大容量128KB以上是2KB一頁。我在這個(gè)項(xiàng)目里用了F103CBT6Flash一共128KB頁大小1KB。分區(qū)很關(guān)鍵規(guī)劃好了后面所有邏輯都順。我的分區(qū)如下區(qū)間地址范圍大小用途Bootloader0x08000000 ~ 0x08001FFF8KBIAP升級(jí)程序參數(shù)存儲(chǔ)區(qū)0x08002000 ~ 0x08002FFF4KB升級(jí)標(biāo)志、版本號(hào)、校驗(yàn)和APP程序區(qū)0x08003000 ~ 0x0801BFFF102KB應(yīng)用程序預(yù)留0x0801C000 ~ 0x0801FFFF16KB備份區(qū)或日志區(qū)Bootloader給8KB是非常寬裕的實(shí)際上我編譯完只有4KB多。APP起始地址選0x08003000注意這里有個(gè)對(duì)齊問題雖然F103的頁是1KB但向量表要求按地址對(duì)齊到0x08000000或0x08010000這樣的大地址邊界嗎不需要向量表只要對(duì)齊到自己所在地址即可關(guān)鍵是偏移量按字對(duì)齊。0x08003000可以被4整除滿足要求。2.2 向量表偏移與APP起始地址設(shè)置APP程序編譯時(shí)必須把ROM起始地址改成0x08003000。在Keil MDK里就是打開Target選項(xiàng)卡把IROM1的Start改成0x08003000Size改成0x1B000102KB。很多人改了ROM地址后程序還是跑飛其實(shí)就是忘了初始化向量表偏移。從F103啟動(dòng)流程來說芯片上電后固定從0x08000000取棧指針和復(fù)位向量。如果APP放在0x08003000那么APP的向量表也在0x08003000但CPU并不會(huì)自動(dòng)知道它默認(rèn)還是去0x08000000找向量表。所以Bootloader跳轉(zhuǎn)前必須告訴CPU“你的向量表搬家了以后中斷從這里查”。標(biāo)準(zhǔn)做法是在APP的main函數(shù)最開始調(diào)用#define APP_VECTOR_TABLE_ADDR 0x08003000 SCB-VTOR APP_VECTOR_TABLE_ADDR;對(duì)F103來說SCB-VTOR這個(gè)寄存器是0xE000ED08。注意第一次賦值時(shí)要先確保當(dāng)前代碼本身不依賴中斷因?yàn)橐坏└牧薞TOR后面來的所有中斷都會(huì)去新向量表取地址。所以這句要放在main最前面最好在系統(tǒng)初始化之前。2.3 跳轉(zhuǎn)函數(shù)實(shí)現(xiàn)與臨界區(qū)處理Bootloader跳轉(zhuǎn)APP的方法有講究。不能簡(jiǎn)單地用函數(shù)指針因?yàn)橹苯诱{(diào)用時(shí)棧指針和復(fù)位向量沒重新初始化很可能跳過去后第一句就進(jìn)HardFault。我用的跳轉(zhuǎn)代碼是業(yè)內(nèi)標(biāo)準(zhǔn)的做法typedef void (*pFunction)(void); void JumpToApp(uint32_t app_addr) { uint32_t stack_addr *(volatile uint32_t *)app_addr; uint32_t reset_addr *(volatile uint32_t *)(app_addr 4); if ((stack_addr 0xFFF00000) ! 0x20000000) { return; // 棧指針異常不能跳轉(zhuǎn) } // 關(guān)閉全局中斷 __disable_irq(); // 恢復(fù)默認(rèn)時(shí)鐘配置避免APP初始化時(shí)鐘時(shí)沖突 RCC_DeInit(); SysTick-CTRL 0; SysTick-LOAD 0; SysTick-VAL 0; // 關(guān)閉AHB/APB外設(shè)時(shí)鐘可選但建議做 RCC-AHBENR 0; RCC-APB1ENR 0; RCC-APB2ENR 0; // 重新設(shè)置棧指針然后跳轉(zhuǎn) __set_MSP(stack_addr); ((pFunction)reset_addr)(); }有幾個(gè)容易忽略的點(diǎn)跳轉(zhuǎn)前要把SysTick關(guān)掉否則APP里初始化SysTick時(shí)會(huì)開在Bootloader殘留的中斷上。其次是中斷標(biāo)志位CAN外設(shè)如果還有掛起中斷跳過去可能馬上觸發(fā)但APP的CAN中斷向量已經(jīng)重映射了沒問題主要是EXTI、USART這些最好也清一下掛起位。另一個(gè)是硬件看門狗如果Bootloader里開了IWDG跳轉(zhuǎn)前先關(guān)掉否則APP如果初始化耗時(shí)長(zhǎng)看門狗先復(fù)位了。為什么跳轉(zhuǎn)前檢查棧指針因?yàn)槿绻鸄PP區(qū)是空的或者數(shù)據(jù)損壞第一個(gè)字不落在0x20000000開頭的SRAM范圍內(nèi)說明這個(gè)“棧指針”根本不是合法的直接跳過去必然死機(jī)。實(shí)測(cè)中最常見的就是APP沒燒錄就跳轉(zhuǎn)加了這道檢查能省很多返修。3. CAN通信協(xié)議設(shè)計(jì)3.1 協(xié)議分層與幀格式定義CAN通信和UART的升級(jí)協(xié)議有個(gè)本質(zhì)區(qū)別UART可以一字節(jié)一字節(jié)流式處理CAN一次最多傳8字節(jié)有效載荷而且?guī)蛶g沒有天然的“流”的概念。所以協(xié)議必須自己定義幀類型、幀序號(hào)、數(shù)據(jù)長(zhǎng)度、校驗(yàn)方式實(shí)現(xiàn)“CAN上的文件傳輸”。我設(shè)計(jì)的協(xié)議比較簡(jiǎn)單兩層就夠了底層是CAN數(shù)據(jù)幀上層是升級(jí)指令區(qū)。全部使用標(biāo)準(zhǔn)幀11位ID波特率500kbps。ID分配如下ID方向含義0x100上位機(jī) - 設(shè)備升級(jí)控制命令0x101上位機(jī) - 設(shè)備數(shù)據(jù)幀0x102上位機(jī) - 設(shè)備請(qǐng)求重傳0x110設(shè)備 - 上位機(jī)應(yīng)答幀0x111設(shè)備 - 上位機(jī)狀態(tài)上報(bào)注意一個(gè)細(xì)節(jié)如果總線上還有其他業(yè)務(wù)節(jié)點(diǎn)ID分配要避開業(yè)務(wù)ID的范圍防止升級(jí)幀被當(dāng)成普通業(yè)務(wù)幀解析。我們這邊業(yè)務(wù)幀ID都在0x200以上所以升級(jí)幀用0x1xx完全隔離。控制命令幀的Data[0]是命令碼Data[1]是參數(shù)。常用命令包括握手0x10、開始升級(jí)0x11、結(jié)束升級(jí)0x12、查詢狀態(tài)0x13、復(fù)位執(zhí)行0x14。數(shù)據(jù)幀里Data[0]是幀序號(hào)Data[1]~Data[7]是固件數(shù)據(jù)一次最多傳7字節(jié)。3.2 分幀傳輸與多幀重組F103的Flash頁最小1KB而CAN一幀最多7字節(jié)數(shù)據(jù)所以一頁數(shù)據(jù)要拆成147幀左右。整個(gè)固件如果有90KB大概需要13000多幀。聽起來很多但500kbps的CAN總線上每幀大約0.26ms一秒鐘能傳3000多幀實(shí)際上傳90KB的固件大概10秒內(nèi)能完成這個(gè)速度在量產(chǎn)產(chǎn)線里完全可接受。分幀傳輸?shù)暮诵膯栴}是丟幀和亂序。CAN本身有硬件仲裁和CRC校驗(yàn)正常通信丟幀率非常低但也不是萬無一失——總線繁忙、錯(cuò)誤幀、節(jié)點(diǎn)掉線都會(huì)導(dǎo)致丟幀。我采用的辦法是“滑動(dòng)確認(rèn)”上位機(jī)每發(fā)送64幀后等待設(shè)備應(yīng)答一個(gè)“接收進(jìn)度”消息設(shè)備告訴上位機(jī)“我已經(jīng)正確收到了第N幀”上位機(jī)從N1繼續(xù)發(fā)。這種方式比逐幀握手快得多又比全包發(fā)完再校驗(yàn)保險(xiǎn)得多。設(shè)備端收到數(shù)據(jù)幀后先把數(shù)據(jù)暫存在一個(gè)RAM緩沖區(qū)里。因?yàn)镕103CBT6的SRAM是20KB裝不下整個(gè)固件所以緩沖區(qū)只放一頁1KB的數(shù)據(jù)攢滿一頁后立刻寫入Flash然后清空緩沖區(qū)等下一頁。這樣RAM占用不到2KB非常節(jié)省。3.3 高可靠性的確認(rèn)與重傳機(jī)制升級(jí)過程最怕的不是“傳輸慢”而是“悄悄丟幀最后校驗(yàn)失敗”。所以協(xié)議里在結(jié)束階段做了一個(gè)雙保險(xiǎn)CRC32校驗(yàn)和回讀校驗(yàn)。發(fā)送端上位機(jī)在發(fā)送固件前先計(jì)算整個(gè)固件文件的CRC32放在結(jié)束升級(jí)命令幀里一起發(fā)過去。設(shè)備端收完所有數(shù)據(jù)后也把收到的固件數(shù)據(jù)按同樣的算法算一遍CRC32和上位機(jī)發(fā)的值比對(duì)。如果一致應(yīng)答“校驗(yàn)通過”如果不一致應(yīng)答“校驗(yàn)失敗”上位機(jī)可以重新發(fā)送整個(gè)固件或者逐幀重傳。只做CRC還不夠因?yàn)樵O(shè)備寫Flash后可能因?yàn)楣╇姴环€(wěn)、Flash疲勞等原因出現(xiàn)個(gè)別字節(jié)寫入錯(cuò)誤。我在校驗(yàn)CRC之前還有一個(gè)“回讀”步驟所有數(shù)據(jù)寫完后把Flash里的內(nèi)容和RAM緩存里的原始數(shù)據(jù)逐字節(jié)比較一遍確認(rèn)硬件寫入沒有異常。這個(gè)回讀比較看起來慢90KB數(shù)據(jù)逐個(gè)字節(jié)讀但實(shí)際上Flash讀速度很快耗時(shí)不到一秒鐘這筆賬花得很值。3.4 和DBC文件的對(duì)接問題做整車項(xiàng)目的朋友會(huì)關(guān)心CAN協(xié)議能不能用DBC文件管理。我的建議是升級(jí)專用的私有協(xié)議不建議進(jìn)DBC因?yàn)镈BC里的信號(hào)是周期或事件觸發(fā)的“業(yè)務(wù)信號(hào)”而升級(jí)協(xié)議里的數(shù)據(jù)幀是“連續(xù)字節(jié)流”用DBC來表達(dá)反而別扭。如果產(chǎn)線工具非要通過DBC來對(duì)接可以把控制命令和狀態(tài)應(yīng)答做成DBC里的兩個(gè)消息數(shù)據(jù)幀通過DBC的原始字節(jié)信號(hào)透?jìng)鳌５珜?shí)際產(chǎn)線我都是讓上位機(jī)直接走原始CAN幀。4. 工程實(shí)現(xiàn)與源碼解析4.1 工程結(jié)構(gòu)搭建工程我基于STM32CubeMX生成底層再在Keil MDK里加Bootloader邏輯。CubeMX里開了CAN1、UART1用來打日志調(diào)試期用、一個(gè)定時(shí)器TIM3作為升級(jí)超時(shí)計(jì)時(shí)GPIO里留了一個(gè)LED做狀態(tài)指示。之所以用TIM3做超時(shí)計(jì)時(shí)而不是簡(jiǎn)單用延時(shí)是因?yàn)锽ootloader的接收循環(huán)中經(jīng)常要判斷“等一個(gè)握手應(yīng)答等了多久”“等下一幀等了多久”用定時(shí)器做基準(zhǔn)可以避免阻塞式延時(shí)把CAN接收卡死。CubeMX配置要點(diǎn)CAN波特率500k采樣點(diǎn)設(shè)置在75%左右。F103的CAN外設(shè)時(shí)鐘來自APB1通常是36MHz500k波特率對(duì)應(yīng)的分頻是// APB1 36MHz // BRP 4, 則時(shí)基 4 * (1/36MHz) 111ns // tq數(shù) (1/500k) / 111ns ≈ 18 // 采樣點(diǎn) (1 13) / 18 ≈ 77.8%具體在CubeMX里就是配置CAN的Prescaler4Time Quanta18重新同步跳躍寬度選2。采樣點(diǎn)對(duì)老練的車載CAN網(wǎng)絡(luò)很重要總線線纜長(zhǎng)、節(jié)點(diǎn)多時(shí)采樣點(diǎn)稍微不對(duì)就會(huì)出現(xiàn)“對(duì)方發(fā)得出來、自己收不到”的靈異問題。4.2 Flash擦寫底層實(shí)現(xiàn)Flash驅(qū)動(dòng)是本項(xiàng)目的硬骨頭之一F103的Flash寫入有幾個(gè)硬性規(guī)則寫Flash前必須先擦除整個(gè)扇區(qū)頁擦除后數(shù)據(jù)全變成0xFF。擦除和編程操作需要在FLASH_CR寄存器配置操作完成后要檢查BSY位。編程必須按16位半字進(jìn)行操作不能按字節(jié)寫。操作期間不能有中斷嵌套訪問Flash否則會(huì)報(bào)錯(cuò)。我封裝了一個(gè)比較穩(wěn)的寫Flash函數(shù)基本原理是“先擦除目標(biāo)頁然后按半字寫入”uint8_t FLASH_WritePage(uint32_t page_addr, uint8_t *buf, uint16_t len) { uint16_t i 0; uint16_t *p (uint16_t *)buf; uint16_t num_halfwords (len 1) / 2; // 補(bǔ)到半字對(duì)齊 FLASH_Unlock(); FLASH_ClearFlag(FLASH_FLAG_EOP | FLASH_FLAG_PGERR | FLASH_FLAG_WRPRTERR); if (FLASH_ErasePage(page_addr) ! FLASH_COMPLETE) { FLASH_Lock(); return 1; } for (i 0; i num_halfwords; i) { if (FLASH_ProgramHalfWord(page_addr i * 2, p[i]) ! FLASH_COMPLETE) { FLASH_Lock(); return 2; } } FLASH_Lock(); return 0; }注意這個(gè)函數(shù)里的FLASH_ProgramHalfWord來自標(biāo)準(zhǔn)外設(shè)庫(kù)操作時(shí)要確保全局中斷是關(guān)閉的或者至少保證沒有其他更高優(yōu)先級(jí)的中斷在Flash編程期間進(jìn)入。我在Bootloader的升級(jí)主循環(huán)里用臨界區(qū)保護(hù)了整個(gè)擦寫過程代價(jià)是CAN接收中斷在寫Flash期間大約1KB數(shù)據(jù)擦寫要幾十ms會(huì)丟幾幀。這個(gè)問題的解決方案是上位機(jī)發(fā)數(shù)據(jù)時(shí)設(shè)計(jì)了“每64幀等待應(yīng)答”的機(jī)制預(yù)留了足夠的時(shí)間余量所以丟幀不影響最終結(jié)果。4.3 主循環(huán)狀態(tài)機(jī)Bootloader不能寫成“順序執(zhí)行”的流水賬代碼因?yàn)楝F(xiàn)場(chǎng)可能出現(xiàn)在任意階段掉線、復(fù)位、中斷等異常情況。我把它設(shè)計(jì)成一個(gè)有限狀態(tài)機(jī)這樣每個(gè)狀態(tài)對(duì)應(yīng)明確的行為和超時(shí)處理。狀態(tài)有狀態(tài)說明超時(shí)動(dòng)作IDLE初始等待無WAIT_HANDSHAKE等待上位機(jī)握手超時(shí)跳APPRECEIVING接收固件數(shù)據(jù)超時(shí)報(bào)錯(cuò)返回IDLEWRITING_FLASH寫入Flash寫失敗返回IDLEWAIT_CRC_CMD等待結(jié)束/校驗(yàn)命令超時(shí)報(bào)錯(cuò)返回IDLECRC_CHECK校驗(yàn)固件校驗(yàn)失敗進(jìn)入ERRORJUMP_APP跳轉(zhuǎn)執(zhí)行APP跳轉(zhuǎn)失敗進(jìn)入ERROR主循環(huán)偽代碼如下while (1) { switch (state) { case IDLE: if (frame_received cmd CMD_HANDSHAKE) { send_response(RESP_ACK); state WAIT_HANDSHAKE; timer_start(TIMER_UPGRADE_TIMEOUT); } else if (app_valid()) { delay_ms(500); // 冷啟動(dòng)短暫等待給上位機(jī)一個(gè)握手窗口 JumpToApp(APP_START_ADDR); } break; case RECEIVING: page_buf_receive(frame); if (page_buf_full()) { FLASH_WritePage(...); send_ack(progress); } break; case CRC_CHECK: if (crc32_matched()) { send_response(RESP_CRC_OK); state JUMP_APP; } else { send_response(RESP_CRC_ERR); state ERROR; } break; case JUMP_APP: JumpToApp(APP_START_ADDR); break; case ERROR: // 停留等待重新握手或超時(shí)后自復(fù)位 break; } }狀態(tài)機(jī)的好處是邏輯可控出問題能快速定位到具體環(huán)節(jié)。調(diào)試的時(shí)候我在每個(gè)狀態(tài)切換點(diǎn)打一條串口日志配合上位機(jī)抓幀哪里斷的一目了然。4.4 APP端配合改法很多朋友只盯著Bootloader寫忘了APP也要配合。前面說了要設(shè)SCB-VTOR還有幾件事也別忽略一是中斷服務(wù)函數(shù)的地址不能寫死。比如老代碼里有時(shí)會(huì)直接給某個(gè)外設(shè)中斷回調(diào)賦函數(shù)指針從舊地址跳到新地址后這個(gè)指針如果不重新初始化就會(huì)飛掉。二是APP的啟動(dòng)文件里堆棧大小要重新評(píng)估。Bootloader跳轉(zhuǎn)到APP時(shí)用的是APP向量表第一個(gè)字作為棧指針?biāo)訟PP啟動(dòng)文件開頭的Stack_Size和Heap_Size要按APP的實(shí)際需求配別沿用Bootloader的小棧配置。三是APP里要預(yù)留一個(gè)“固件更新標(biāo)志”。我是在參數(shù)存儲(chǔ)區(qū)里放了4個(gè)字節(jié)的魔數(shù)比如0xA5A5A5A5表示“下次復(fù)位進(jìn)入Bootloader升級(jí)模式”APP收到升級(jí)指令后先在參數(shù)區(qū)寫標(biāo)志然后軟復(fù)位。這樣就不需要每次上電都要等待Bootloader的超時(shí)窗口用戶體驗(yàn)好得多。具體做法void EnterBootloader(void) { *(volatile uint32_t *)PARAM_AREA_ADDR UPGRADE_REQUEST_FLAG; NVIC_SystemReset(); }Bootloader啟動(dòng)后先檢查參數(shù)區(qū)的標(biāo)志如果是升級(jí)請(qǐng)求就直接留在Bootloader否則延時(shí)跳APP。升級(jí)流程完成后清除標(biāo)志。4.5 計(jì)時(shí)與超時(shí)處理升級(jí)過程中如果上位機(jī)掉線設(shè)備不能永遠(yuǎn)死在“接收狀態(tài)”要有一個(gè)兜底超時(shí)。我用TIM3做毫秒級(jí)計(jì)時(shí)基準(zhǔn)每次收到有效幀就清零計(jì)數(shù)值如果超過5秒沒收到任何幀就判定通信中斷自動(dòng)復(fù)位到Bootloader起始狀態(tài)等待下一次升級(jí)指令。這樣即使上位機(jī)中途崩潰設(shè)備也不會(huì)卡死。超時(shí)時(shí)間的選擇我說一下不能太短因?yàn)镃AN總線在某些瞬間可能連續(xù)幾個(gè)錯(cuò)誤幀導(dǎo)致總線阻塞幾幀收不到很正常也不能太長(zhǎng)否則產(chǎn)線上發(fā)現(xiàn)升級(jí)失敗后要干等半天。5秒是實(shí)踐下來比較合適的值。5. 量產(chǎn)部署的坑與對(duì)策5.1 產(chǎn)線燒錄流程設(shè)計(jì)實(shí)驗(yàn)室里怎么玩都可以但量產(chǎn)部署講究的是流程標(biāo)準(zhǔn)化和防呆。我這邊最終確定的產(chǎn)線流程是這樣工裝治具夾好設(shè)備給設(shè)備上電設(shè)備進(jìn)入Bootloader等待握手。上位機(jī)掃描總線上所有設(shè)備ID確認(rèn)數(shù)量與工位產(chǎn)品一致。上位機(jī)發(fā)送握手幀設(shè)備端回讀版本號(hào)、芯片ID、上次升級(jí)狀態(tài)。上位機(jī)比對(duì)目標(biāo)固件和當(dāng)前固件版本決定是否升級(jí)。升級(jí)完成后上位機(jī)發(fā)送“查詢固件CRC”命令把設(shè)備端Flash中固件的CRC32讀回來和上位機(jī)源文件比對(duì)作為出廠驗(yàn)收項(xiàng)之一。記錄升級(jí)時(shí)間、設(shè)備序列號(hào)、固件版本、CRC結(jié)果到MES系統(tǒng)。這個(gè)流程在產(chǎn)線上跑了兩個(gè)多月了最大的經(jīng)驗(yàn)是上位機(jī)不要每臺(tái)設(shè)備都重新配置參數(shù)最好是讀一個(gè)固定的配置文件。固件版本號(hào)、存放路徑、目標(biāo)節(jié)點(diǎn)ID、是否強(qiáng)制升級(jí)這些統(tǒng)統(tǒng)從配置文件讀避免操作員手動(dòng)點(diǎn)錯(cuò)。5.2 防止刷成磚的機(jī)制任何Bootloader最怕的就是升級(jí)失敗后設(shè)備變磚尤其量產(chǎn)階段一旦磚了就要拆殼燒寫損失很大。我的防磚策略有三個(gè)層次第一是雙保險(xiǎn)啟動(dòng)邏輯設(shè)備上電后先檢查APP區(qū)首字棧指針和復(fù)位向量是否合法不合法就留在Bootloader。這樣即使APP刷得稀爛只要Bootloader還在就能重新刷回來。第二是升級(jí)確認(rèn)機(jī)制寫完固件后先校驗(yàn)CRC校驗(yàn)通過才設(shè)置“APP可用”標(biāo)志。這個(gè)標(biāo)志單獨(dú)放在參數(shù)存儲(chǔ)區(qū)是最后一步才寫入的。如果固件還沒校驗(yàn)就斷電標(biāo)志不被置位下次啟動(dòng)還是會(huì)進(jìn)Bootloader。第三是Bootloader本身的自保護(hù)在擦除APP區(qū)之前先校驗(yàn)Bootloader自己的CRC如果Bootloader區(qū)損壞了才說明真沒救了但這幾乎不會(huì)發(fā)生。F103內(nèi)部Flash的壽命和穩(wěn)定性在正常供電下是有保障的真正會(huì)搞壞Bootloader的是在擦寫過程中斷電。另外我強(qiáng)烈建議給產(chǎn)線工裝加一個(gè)檢測(cè)程序升級(jí)完成后設(shè)備自動(dòng)發(fā)一條“版本CRC”消息工裝顯示綠色通過才允許裝箱。雖然看起來多了一步但能攔截掉幾乎所有潛在問題。5.3 升級(jí)認(rèn)證與防回滾如果產(chǎn)品對(duì)安全有要求光有CRC還不夠。我這邊在協(xié)議里加了簡(jiǎn)單的序列號(hào)認(rèn)證設(shè)備端在握手時(shí)把96位唯一ID芯片的Unique ID回傳給上位機(jī)上位機(jī)把升級(jí)包綁定到這個(gè)ID上防止A設(shè)備的固件被復(fù)制刷到B設(shè)備里去。這個(gè)在知識(shí)產(chǎn)權(quán)保護(hù)和產(chǎn)品管理上有實(shí)際價(jià)值。防回滾機(jī)制也做了比如當(dāng)前版本是V1.2上位機(jī)不允許下發(fā)V1.1。怎么實(shí)現(xiàn)在結(jié)束升級(jí)命令幀里帶上目標(biāo)版本號(hào)和最低允許版本號(hào)設(shè)備端判定版本號(hào)是否符合要求不符合直接拒絕。這樣能避免產(chǎn)線調(diào)試時(shí)誤刷舊固件導(dǎo)致后期兼容性問題。5.4 量產(chǎn)測(cè)試項(xiàng)與驗(yàn)收量產(chǎn)驗(yàn)證踩過坑之后我整理了一份驗(yàn)收清單推薦給同樣要做量產(chǎn)部署的朋友測(cè)試項(xiàng)操作通過標(biāo)準(zhǔn)升級(jí)功能正常下發(fā)固件CRC一致APP可正常運(yùn)行斷電恢復(fù)傳輸中隨機(jī)斷電上電后進(jìn)入Bootloader可重新升級(jí)非法固件發(fā)送損壞固件設(shè)備拒絕執(zhí)行APP不變升級(jí)后用業(yè)務(wù)測(cè)試跑一遍正常業(yè)務(wù)無異常復(fù)位、無總線錯(cuò)誤長(zhǎng)時(shí)間老化升級(jí)后連續(xù)運(yùn)行24小時(shí)無復(fù)位、無死機(jī)6. 調(diào)試經(jīng)驗(yàn)與常見問題6.1 CAN通信突然連不上這個(gè)坑我遇到太多次了現(xiàn)象是“之前明明好好的突然一發(fā)數(shù)據(jù)就發(fā)不出去或者對(duì)方收不到”。排查順序我總結(jié)如下先看波特率。CAN沒有“自動(dòng)識(shí)別波特率”的功能雙方波特率不一致時(shí)表現(xiàn)為發(fā)送方自己能看到總線報(bào)文嗎可以。但對(duì)方收不到或者收到一幀后后續(xù)全是錯(cuò)誤幀。用CAN分析儀USBCAN、PCAN都可以抓總線數(shù)據(jù)如果看到一堆Error Frame幾乎可以斷定波特率或采樣點(diǎn)不匹配。再看終端電阻。CAN總線的兩端必須各接一個(gè)120歐電阻。我的產(chǎn)線工裝里經(jīng)常出現(xiàn)只在一端接了電阻的情況短距離實(shí)驗(yàn)發(fā)現(xiàn)不了問題但線纜長(zhǎng)度超過幾米后信號(hào)反射會(huì)把波形搞崩表現(xiàn)為升級(jí)過程中偶發(fā)性丟幀。還要檢查總線占用率。如果現(xiàn)有CAN網(wǎng)絡(luò)里業(yè)務(wù)報(bào)文非常密集升級(jí)幀的優(yōu)先級(jí)低可能一直無法獲得仲裁。這種情況可以調(diào)高升級(jí)幀的ID優(yōu)先級(jí)或者暫時(shí)讓業(yè)務(wù)節(jié)點(diǎn)靜默。我調(diào)這類問題一般用USBCAN的“總線檢測(cè)”模式抓一段波形看電平是否正常再用“報(bào)文統(tǒng)計(jì)”看錯(cuò)誤幀計(jì)數(shù)基本能定位。6.2 下載中途斷開與Flash寫入失敗升級(jí)過程中最惡心的事情是“傳輸?shù)?0%后設(shè)備斷了”。原因五花八門但我排查下來最多的是供電問題。CAN升級(jí)時(shí)設(shè)備通常要連續(xù)工作一段時(shí)間如果供電用的是劣質(zhì)電源適配器電流一波動(dòng)Flash擦寫瞬間電流大直接把供電拉低到復(fù)位閾值設(shè)備就重啟了。處理方式給設(shè)備供電用穩(wěn)壓電源電流余量留足。另外在Bootloader里加“掉電保護(hù)”一旦檢測(cè)到供電異常比如用ADC采樣VDD立即停止Flash操作等待供電穩(wěn)定后再繼續(xù)。Flash寫入失敗還有一種隱蔽原因?qū)懩硞€(gè)地址區(qū)間時(shí)該地址對(duì)應(yīng)的Flash扇區(qū)正在被代碼本身占用。比如把緩沖區(qū)定義在Flash映射的地址空間雖然這不可能因?yàn)镾RAM和Flash地址分開的或者中斷向量表所在的扇區(qū)被誤擦除。真遇到了可以用CMSIS里的FLASH_GetStatus函數(shù)把錯(cuò)誤狀態(tài)打出來常見的PGERR或WRPRTERR對(duì)應(yīng)的問題不一樣。6.3 跳轉(zhuǎn)失敗死機(jī)的定位跳轉(zhuǎn)失敗的現(xiàn)象通常是“Bootloader屏幕還活著LED閃但APP不啟動(dòng)”或者是“直接進(jìn)HardFault”。定位思路第一步檢查APP區(qū)是否真的有內(nèi)容。用調(diào)試器讀0x08003000處的前8個(gè)字節(jié)正常應(yīng)該是一個(gè)SRAM地址比如0x20001234和一個(gè)Flash地址比如0x08003341。如果讀出來是0xFFFFFFFF說明壓根沒刷進(jìn)去。第二步檢查APP的VTOR是否設(shè)置。在APP的main函數(shù)里設(shè)SCB-VTOR后再查看該寄存器值是否等于0x08003000。第三步檢查跳轉(zhuǎn)時(shí)中斷是否還掛著?？梢园阉袙炱鹬袛嗲逡槐樵偬D(zhuǎn)NVIC-ICER[0] 0xFFFFFFFF; NVIC-ICPR[0] 0xFFFFFFFF;另外還有一個(gè)容易忽視的點(diǎn)如果APP用了FreeRTOS跳轉(zhuǎn)時(shí)APP的任務(wù)棧和系統(tǒng)時(shí)鐘初始化都不能依賴于“從0x08000000開始的啟動(dòng)流程”FreeRTOS的啟動(dòng)文件通常會(huì)調(diào)用SystemInit這個(gè)函數(shù)里有時(shí)會(huì)寫PLL和Flash等待周期但它是用寄存器配置硬編碼的不會(huì)因?yàn)榈刂纷兞司统鲥e(cuò)。只要確保時(shí)鐘和Flash等待狀態(tài)在跳轉(zhuǎn)前被妥善處理即可。6.4 工具與資料推薦關(guān)于工具和資料我建議手頭常備這么幾樣周立功USBCAN-II或者PCAN用來抓CAN報(bào)文、模擬上位機(jī)ST-Link V2用來燒錄Bootloader和調(diào)試APPSTM32F103中文參考手冊(cè)RM0008注意要看“Flash編程”和“CAN控制器”這兩章PDF記得下原版或者靠譜翻譯版Keil MDK工程用CubeMX生成底層后千萬別手動(dòng)畫代碼能省掉大量無意義錯(cuò)誤一個(gè)示波器或者邏輯分析儀排查CAN物理層問題時(shí)必備調(diào)試期如果嫌串口日志麻煩我后來是直接把調(diào)試信息編碼成CAN私有幀發(fā)出來上位機(jī)一個(gè)窗口實(shí)時(shí)顯示Bootloader內(nèi)部狀態(tài)。這樣最貼近實(shí)際工作環(huán)境也省得在板子上額外留串口。7. 寫在后面的幾句體會(huì)這個(gè)CAN Bootloader項(xiàng)目前前后后改了五六版真正穩(wěn)定是在加了狀態(tài)機(jī)、超時(shí)處理和斷電保護(hù)之后。回頭看我踩過最大的坑反而是最基礎(chǔ)的兩件事一是Flash分區(qū)和向量表偏移二是CAN總線的物理層參數(shù)。這兩個(gè)問題如果提前吃透后面很多折騰根本不會(huì)發(fā)生。另外一個(gè)深刻的體會(huì)是Bootloader這東西不是“寫完就行”它是出廠后你唯一能遠(yuǎn)程抓住設(shè)備的手質(zhì)量要求要比普通業(yè)務(wù)代碼更高多花幾天時(shí)間把邊緣情況想全比后面出差返修劃算得多。最后再提醒一句量產(chǎn)部署前一定要用壞固件、半截固件、斷電場(chǎng)景充分折磨你的Bootloader它扛得住產(chǎn)線才能睡得著覺。