最近在產(chǎn)線上把一批基于STM32H743和STM32H745的板卡從Embedded Bootloader V9.1升級到了V9.2。這次升級不是簡單換個版本號而是把過去半年在生產(chǎn)、現(xiàn)場運維、以及客戶反饋中踩過的大大小小的坑集中做了一次收斂。如果你正在用STM32H7系列做帶網(wǎng)絡(luò)、運動控制或者FOC算法的高性能應(yīng)用這篇文章應(yīng)該能幫你省下不少排查時間。STM32H743和STM32H745這兩顆芯片在工業(yè)控制里非常常見一個偏通用高性能計算一個帶雙核可以跑異構(gòu)任務(wù)。Bootloader看似不起眼但它決定了固件能不能穩(wěn)定升級、能不能安全回滾、能不能在量產(chǎn)產(chǎn)線上高效燒錄。V9.1這個版本在最初設(shè)計時功能上并不差但到了實際場景里尤其是配合LAN8720以太網(wǎng)、雙DMA脈沖輸出這些高負(fù)載外設(shè)時問題就開始冒頭了。這篇文章我會把V9.1到V9.2升級背后的原因、Bootloader架構(gòu)里幾個關(guān)鍵模塊的設(shè)計思路、以及升級實操中必須注意的細(xì)節(jié)都展開講一遍適合正在做STM32H7平臺固件開發(fā)的工程師也適合準(zhǔn)備自己寫B(tài)ootloader的入門者參考。1. 項目背景與升級動機(jī)1.1 為什么我給STM32H7系列換了一套BootloaderSTM32H7是一個很特殊的系列。主頻高最高到480MHzFlash和RAM也大還帶雙Bank、硬件加解密、Cache等一堆高級特性。但性能強(qiáng)的代價是系統(tǒng)復(fù)雜度高尤其是啟動流程、Flash映射、Cache一致性這些點稍不注意就會出現(xiàn)看起來全對、跑起來隨機(jī)出錯的詭異現(xiàn)象。我手里這塊板子最開始用的是自研的Bootloader V9.1功能上支持UART和CAN升級支持通過按鍵進(jìn)入Boot模式支持固件CRC32校驗。在實驗室里測試得很平穩(wěn)但一上產(chǎn)線問題就出來了。比如產(chǎn)線工人用燒錄器批量燒寫時偶爾會遇到校驗失敗客戶現(xiàn)場反饋某個批次設(shè)備以太網(wǎng)升級時經(jīng)常超時還有幾臺設(shè)備在升級完成后應(yīng)用程序直接跑飛。這些都是Bootloader層面的問題不是應(yīng)用層代碼導(dǎo)致的。所以V9.2這次升級的核心目標(biāo)很明確讓Bootloader在真實生產(chǎn)環(huán)境里更穩(wěn)定補(bǔ)充以太網(wǎng)升級通道修復(fù)Flash雙Bank切換和Cache一致性問題同時優(yōu)化升級失敗后的自動恢復(fù)流程。1.2 V9.1在產(chǎn)線上暴露的問題與升級需求清單在升級之前我先把V9.1在實際使用中暴露的問題列了一份清單也算是給V9.2定需求。這份清單直接決定了V9.2的改動范圍。問題描述出現(xiàn)場景嚴(yán)重程度V9.2目標(biāo)Flash寫入偶發(fā)對齊錯誤導(dǎo)致固件燒錄不完整產(chǎn)線批量燒錄、CAN升級大固件高重寫Flash寫入邏輯強(qiáng)制字節(jié)/半字對齊啟動跳轉(zhuǎn)后Cache沒有正確失效App運行異常升級后首次啟動、以太網(wǎng)升級后概率出現(xiàn)高增加SCB_InvalidateDCache和ICache清理雙Bank切換后地址映射錯誤App無法啟動使用Bank2啟動時高重做雙Bank地址映射與FLASH_OPTCR配置以太網(wǎng)升級通道缺失現(xiàn)場維護(hù)效率低客戶遠(yuǎn)程升級需求中新增基于LAN8720的以太網(wǎng)升級通道升級超時后沒有可靠的自動回滾機(jī)制弱網(wǎng)環(huán)境、傳輸中斷中增加版本回滾標(biāo)記與Bootloader內(nèi)看門狗兜底CAN升級時波特率自適應(yīng)邏輯在噪聲環(huán)境下誤判工業(yè)現(xiàn)場CAN總線干擾低優(yōu)化波特率檢測超時與重試策略這些需求看起來多但真正動手改起來核心改動集中在三個地方Flash驅(qū)動、啟動跳轉(zhuǎn)邏輯、以及升級通道的擴(kuò)展。V9.2就是圍繞這三塊做的重構(gòu)。2. Bootloader整體架構(gòu)與V9.2的設(shè)計思路2.1 雙Bank啟動與跳轉(zhuǎn)機(jī)制STM32H7系列的Flash通常有1MB或者2MB物理上劃分為兩個Bank可以根據(jù)FLASH_OPTCR寄存器中的DBANK位配置為單Bank或雙Bank模式。Bootloader之所以要利用雙Bank是為了實現(xiàn)A/B鏡像升級一個Bank跑當(dāng)前版本另一個Bank用來寫入新固件。升級完成后通過修改BootLoader的啟動標(biāo)記在下次復(fù)位時跳轉(zhuǎn)到新Bank。這個過程在V9.2里做了重新設(shè)計。以前V9.1的跳轉(zhuǎn)邏輯很簡單就是讀一個啟動標(biāo)記變量決定跳轉(zhuǎn)到Bank1還是Bank2。但問題在于H7的Flash地址映射和F4、F1完全不同。H7中Flash的基地址是0x08000000但在雙Bank模式下Bank2的地址并不是簡單地在0x08000000基礎(chǔ)上加1MB而是會映射到0x08100000這樣的位置。如果你的芯片實際型號是H743VI2MB Flash但配置成了單Bank模式那么整個Flash就是一個連續(xù)的2MB空間跳轉(zhuǎn)邏輯又不一樣。我在V9.2里直接做了一套統(tǒng)一的地址映射函數(shù)根據(jù)芯片型號和選項字節(jié)自動判斷當(dāng)前是單Bank還是雙Bank然后計算出正確的App起始地址。這樣避免了代碼里寫死地址導(dǎo)致?lián)Q了芯片型號就翻車的尷尬。跳轉(zhuǎn)本身也有講究。App跑起來之后中斷向量表要重映射到App的起始地址。H7支持兩種方式一種是修改VTOR寄存器把中斷向量表定位到App的Flash地址另一種是通過鏈接腳本和SCB-VTOR直接賦值。我在Bootloader里用的方式是后者跳轉(zhuǎn)前關(guān)閉全局中斷、清理流水線、重置棧指針然后跳轉(zhuǎn)到App的Reset_Handler。V9.1跳轉(zhuǎn)前經(jīng)常不做Cache清理結(jié)果App一啟動就讀到了舊數(shù)據(jù)表現(xiàn)為跑飛。V9.2在跳轉(zhuǎn)前顯式執(zhí)行了以下操作SCB_DisableICache(); SCB_DisableDCache(); SCB-VTOR (uint32_t)app_addr; __set_MSP(*(volatile uint32_t *)app_addr); __enable_irq(); ((void (*)(void))(*(volatile uint32_t *)(app_addr 4)))();這里有個順序問題我測試下來建議先關(guān)Cache再改VTOR再設(shè)置MSP。如果順序反了跳轉(zhuǎn)后第一次進(jìn)中斷時可能從舊Cache里讀到錯誤的棧指針直接HardFault。2.2 升級通道選型UART、CAN與以太網(wǎng)Bootloader升級通道選型是個老話題。V9.1只支持UART和CANV9.2把以太網(wǎng)加了進(jìn)來。很多人問為什么不直接上SD卡或者USB我的考慮是民用產(chǎn)品可以用SD卡但工業(yè)現(xiàn)場設(shè)備很多是密封金屬殼沒地方插卡。USB雖然方便但需要額外的線纜和驅(qū)動產(chǎn)線操作也不夠快。UART和CAN是工業(yè)控制器的基礎(chǔ)配置成本低、實現(xiàn)簡單以太網(wǎng)則是因為現(xiàn)在越來越多的現(xiàn)場總線會走EtherCAT或者M(jìn)odbus TCP板子上基本都有LAN8720這類PHY芯片直接把升級通道復(fù)用到物理網(wǎng)絡(luò)上現(xiàn)場維護(hù)時不用開蓋非常香。UART通道采用固定波特率握手協(xié)議的方式。V9.1里做了自動波特率檢測但在強(qiáng)干擾環(huán)境下偶爾會把噪聲當(dāng)起始位導(dǎo)致通訊錯亂。V9.2改成了默認(rèn)115200同時支持上位機(jī)通過連續(xù)發(fā)送特征字0xAA 0x55來觸發(fā)Bootloader重新握手沒有特殊情況不再做自動波特率漂移檢測。CAN通道保留但針對工業(yè)現(xiàn)場的抖動問題做了一層數(shù)字濾波。其實用起來和UART差不多只是底層驅(qū)動從串口換成FDCAN。值得注意的是一開始我沒有意識到H7的FDCAN發(fā)送FIFO是有限深度的V9.1在高速傳輸時因為沒等FIFO空就繼續(xù)填數(shù)據(jù)偶發(fā)丟幀。V9.2在每次發(fā)送前檢查TXBRP寄存器確保有空閑的發(fā)送緩沖區(qū)再寫數(shù)據(jù)。以太網(wǎng)通道是基于裸機(jī)LwIP做的這個在后面第3部分詳細(xì)展開。2.3 固件簽名、CRC32與版本回滾Bootloader絕對不是把數(shù)據(jù)寫進(jìn)Flash就完事了。固件完整性和合法性校驗直接決定了設(shè)備會不會變磚。V9.1里用了簡單的累加和校驗雖然能發(fā)現(xiàn)隨機(jī)錯誤但客戶現(xiàn)場遇到過明明數(shù)據(jù)完整卻啟動失敗的情況——因為累加和校驗對字節(jié)順序不敏感根本擋不住塊編排錯誤。V9.2統(tǒng)一改用CRC32硬件CRC單元校驗范圍覆蓋整個固件鏡像包括頭部、代碼段、只讀數(shù)據(jù)段。同時增加了一個固定格式的固件頭里面包含魔數(shù)、固件版本號、固件長度、CRC32值、目標(biāo)芯片ID。Bootloader在下載完固件后先檢查固件頭魔數(shù)再核對目標(biāo)芯片ID防止把H743的固件刷到H745上最后算一遍CRC32全部通過才允許更新啟動標(biāo)記。版本回滾依靠的是App區(qū)里的備份有效標(biāo)志。升級成功后App首次啟動時會向Bootloader信息區(qū)寫入一個新的有效標(biāo)記。如果App沒能在規(guī)定時間內(nèi)完成啟動比如10秒內(nèi)沒有心跳Bootloader就認(rèn)為新版本有問題自動切回上一個版本的備份。這個機(jī)制在V9.2里做成了強(qiáng)制流程只要存在舊備份就不允許直接擦除必須先完成新版本驗證。2.4 V9.1到V9.2的兼容性約束每次大版本升級最怕的就是老設(shè)備無法升級到新Bootloader。V9.2的固件格式和V9.1并不兼容所以我特意保留了兼容模式V9.2可以識別V9.1固件包并在燒錄時自動轉(zhuǎn)換為新版格式。這樣客戶現(xiàn)有的固件包不用全部重編也能通過V9.2 Bootloader刷進(jìn)去。同時升級路徑上的安全措施也很重要。V9.2在線升級固件本身被設(shè)計成一次性操作如果升級中途斷電或通訊中斷V9.1還能繼續(xù)工作不會因為Bootloader刷寫到一半就報廢。這是通過雙Bootloader機(jī)制做到的Bootloader區(qū)的前8KB是一個固定不變的StartLoader真正刷新的Bootloader主體在后面的區(qū)域V9.1的用戶可以直接把新的V9.2鏡像作為普通App下載到Bootloader區(qū)之外然后由StartLoader完成切換。3. V9.1到V9.2的核心代碼改動解析3.1 Flash擦寫對齊與雙Bank切換修復(fù)這個坑是V9.1代碼里最讓我頭疼的。STM32H7的Flash控制器和F1/F4的區(qū)別非常大寫操作受到嚴(yán)格限制H7在寫Flash時必須按32字節(jié)的粒度進(jìn)行對齊。具體地說如果你想往任意地址寫一個字節(jié)實際上Flash控制器會先讀出一個64位的行row修改對應(yīng)字節(jié)再寫回去。這個操作如果跨行就會觸發(fā)對齊錯誤。V9.1里我當(dāng)時用了比較偷懶的方式直接把接收到的UART數(shù)據(jù)包逐個字節(jié)寫進(jìn)Flash。理論上H7允許字節(jié)寫但它要求寫入地址必須與行邊界對齊否則就會產(chǎn)生PGA錯誤。這個問題在實驗室里很少被觸發(fā)因為每次升級長度都恰好是4字節(jié)對齊的但產(chǎn)線上有幾次固件長度不是4的整數(shù)倍最后一包數(shù)據(jù)就把Flash寫壞了。V9.2里我重寫了Flash寫入驅(qū)動核心思想是緩沖對齊刷入uint8_t line_buf[32]; uint32_t line_addr start_addr ~0x1FUL; // 先把非對齊部分讀到line_buf for (int i 0; i data_len; i) { line_buf[(pos i) 0x1F] data[i]; if (((pos i) 0x1F) 0x1F) { FLASH_Program_32B(line_addr, (uint32_t *)line_buf); line_addr 32; memset(line_buf, 0xFF, 32); } }這樣不管是1字節(jié)還是100字節(jié)都統(tǒng)一按照32字節(jié)行來刷寫。實測下來產(chǎn)線上再沒出現(xiàn)過燒錄一半失敗的問題。雙Bank切換則涉及選項字節(jié)的修改。H743和H745支持在運行中動態(tài)切換DBANK模式但切換前必須保證Flash控制器處于空閑狀態(tài)而且切換后所有Bank地址會重新映射。V9.1在切換時沒有做延時和狀態(tài)輪詢導(dǎo)致偶爾切換失敗。V9.2的代碼框架如下等待FLASH-SR中的BSY位清零解鎖Flash選項字節(jié)寫入寫入新的DBANK配置等待操作完成軟件復(fù)位讓Flash重新映射生效。這里提醒一下如果您用的是STM32CubeMX生成工程并勾選了雙Bank模式在Bootloader里做切換時必須特別小心CubeMX生成的Flash驅(qū)動會默認(rèn)按單Bank布局處理某些地址。3.2 新增基于LAN8720的以太網(wǎng)升級通道LAN8720是很經(jīng)典的10/100M以太網(wǎng)PHY芯片STM32H7片內(nèi)有MAC啟用RMII接口后PA1是ETH_REF_CLKPA2是MDIOPA7是ETH_CRS_DVPC1是ETH_MDCPG11是ETH_RX_EN這些引腳必須和LAN8720的接線一一對應(yīng)。很多工程師第一次調(diào)LAN8720時容易被時鐘源卡住LAN8720的REF_CLK可以由外部提供也可以由MCU的MCO引腳輸出50MHz時鐘。H7的MCO輸出頻率還要先經(jīng)過PLL分頻細(xì)節(jié)非常多。這里不展開時鐘樹只說和Bootloader相關(guān)的點。以太網(wǎng)升級通道在V9.2中基于LwIP裸機(jī)協(xié)議棧實現(xiàn)只開了UDP服務(wù)。選UDP而不是TCP是因為在Bootloader階段要盡量保持簡單UDP無連接處理邏輯少。升級流程是上位機(jī)通過UDP廣播搜索設(shè)備設(shè)備回復(fù)自己的MAC地址和當(dāng)前版本號上位機(jī)發(fā)送升級命令并附帶固件包Bootloader收到固件包后逐塊寫入Flash每寫完一塊回一個ACK上位機(jī)根據(jù)ACK決定繼續(xù)發(fā)送下一塊還是重發(fā)。這個過程中有一個容易忽略的點ETH DMA描述符必須放在非Cacheable的內(nèi)存區(qū)域。H7的DMA描述符如果放在默認(rèn)的普通SRAM里DMA寫完后CPU讀到的可能是Cache里的舊數(shù)據(jù)。我在V9.2中把DMA描述符定義到了專門的非緩存內(nèi)存段同時在以太網(wǎng)中斷里加了顯式的Cache清理。沒有這一步以太網(wǎng)升級大概率會出現(xiàn)接收到的數(shù)據(jù)隨機(jī)損壞。LwIP的配置也要精簡。Bootloader畢竟不是跑應(yīng)用不需要完整協(xié)議棧。我只保留最基礎(chǔ)的UDP支持關(guān)閉TCP、關(guān)閉DHCP客戶端用固定IP關(guān)閉ICMP響應(yīng)內(nèi)存池開小一點整體RAM占用控制在幾十KB以內(nèi)。這樣連H743都能輕松運行。3.3 中斷向量重映射與Cache一致性處理H7的Cache是把雙刃劍。性能高但Bootloader在這些地方必須謹(jǐn)慎處理。首先是中斷向量表重映射。H7支持把中斷向量表放到普通RAM中這樣可以在運行期動態(tài)修改IRQ處理函數(shù)。但Bootloader不需要這種花活我直接用SCB-VTOR把向量表指向App區(qū)開頭。之前V9.1犯過的錯誤是跳轉(zhuǎn)前只設(shè)置了VTOR卻忘了關(guān)閉ITCM和DTCM相關(guān)的Cache。H7的ITCM指令緊耦合內(nèi)存和DTCM數(shù)據(jù)緊耦合內(nèi)存不受Cache控制但Flash本身是被緩存的。如果App代碼在Flash里而我們在Bootloader里已經(jīng)啟用了ICache跳轉(zhuǎn)后ICache里還殘留著Bootloader程序的部分指令A(yù)pp執(zhí)行流可能在跳轉(zhuǎn)邊界處讀到臟指令。V9.2的處理是強(qiáng)制要求關(guān)閉ICache和DCache再跳轉(zhuǎn)等App自己重新初始化Cache。這看起來損失了一點啟動速度但換來的是極高的穩(wěn)定性。有的App鏈接腳本里可能還開了MPU配置了某些SRAM區(qū)域為設(shè)備內(nèi)存Device Memory或非緩存區(qū)域這種情況下Bootloader無法知道App的MPU配置所以更不應(yīng)該擅自開著Cache跳轉(zhuǎn)。DCache一致性問題更多體現(xiàn)在升級過程中。固件數(shù)據(jù)通過DMA從UART或以太網(wǎng)外設(shè)搬進(jìn)RAM如果RAM區(qū)域是Cacheable的那么CPU直接用指針訪問這塊內(nèi)存時可能讀到的不是DMA寫好的數(shù)據(jù)而是Cache里的舊值。V9.2在做每一次DMA接收前都調(diào)用了SCB_CleanDCache接收完成后調(diào)用SCB_InvalidateDCache確保數(shù)據(jù)完整。極端情況下還可以直接用CMSIS提供的SCB_InvalidateDCache_by_Addr精確清理某一段地址。3.4 Bootloader超時與獨立看門狗策略Bootloader最怕的一件事是卡死。如果設(shè)備在Bootloader階段死循環(huán)復(fù)位既進(jìn)不了App也進(jìn)不了DFU那只能通過硬件恢復(fù)。V9.2做了一個比較完善的多級超時機(jī)制。第一個超時是等待升級命令超時。設(shè)備上電進(jìn)入Bootloader后默認(rèn)等待5秒鐘。如果5秒內(nèi)沒有收到任何有效的升級命令就直接跳轉(zhuǎn)App。這樣即使現(xiàn)場人員誤觸發(fā)進(jìn)入Bootloader設(shè)備也能自動回到正常應(yīng)用不會一直干等。第二個超時是數(shù)據(jù)包間隔超時。在升級過程中如果超過3秒沒有收到下一個數(shù)據(jù)包Bootloader會判定鏈路異常停止升級并回滾啟動標(biāo)記下次復(fù)位仍啟動舊版本。這個超時時間要設(shè)置合理太短會誤判太長會讓現(xiàn)場調(diào)試難受。3秒對UART和有線以太網(wǎng)來說都足夠可靠對CAN在強(qiáng)干擾場景可能需要加長到5秒。第三個是獨立看門狗IWDG。V9.1沒有開IWDG導(dǎo)致Bootloader如果卡在Flash擦寫死循環(huán)里整個系統(tǒng)就罷工了。V9.2在Bootloader初始化階段直接開啟IWDG超時時間設(shè)為2秒主循環(huán)里周期性喂狗。這樣即使代碼有嚴(yán)重邏輯Bug也能在2秒內(nèi)復(fù)位至少可以恢復(fù)到一個可重新燒錄的狀態(tài)。不過要特別提醒IWDG一旦開啟就不能在運行中關(guān)閉。如果App需要長時間占用CPU做密集計算比如FOC算法的參數(shù)自整定App里也必須定期喂IWDG否則App運行到一半會被看門狗復(fù)位。我在V9.2的Bootloader文檔里專門標(biāo)注了這一點并且把喂狗接口封裝成一個弱函數(shù)App里如果沒有實現(xiàn)Bootloader默認(rèn)用SysTick周期喂狗App如果接管了SysTick就必須自己實現(xiàn)喂狗邏輯。4. 升級全過程實操記錄4.1 升級前的固件準(zhǔn)備與版本搭配這次升級我準(zhǔn)備了三種固件包完整的Bootloader V9.2鏡像、應(yīng)用固件V2.3.1配套新Bootloader、以及一個臨時過渡鏡像用于老版本V9.1設(shè)備先把App備份到另一個Bank。這三類固件包我都在上位機(jī)工具里統(tǒng)一打包成了標(biāo)準(zhǔn)格式頭部包含固件類型和版本信息。升級前有一件事必須做確認(rèn)芯片的選項字節(jié)和Flash大小。STM32H743有不同F(xiàn)lash容量的型號H743VI是2MBH743AI是1MB。同一個bootloader鏡像如果直接燒到1MB芯片上雙Bank地址映射就會出錯。V9.2在啟動時會讀取DBGMCU-IDCODE和Flash大小寄存器自動適配但V9.1沒有這個邏輯。所以從V9.1向V9.2升級時第一步還是要手動確認(rèn)目標(biāo)板子是2MB還是1MB。另外升級過程中最好把調(diào)試器的SWD接口留出來特別是現(xiàn)場第一次升級時。萬一升級失敗只要SWD還在就能用st-link把好的鏡像硬懟進(jìn)去。4.2 基于UART的串口升級步驟串口升級是最通用的路徑適用于不帶以太網(wǎng)的板子。V9.2的UART協(xié)議和V9.1不太一樣命令幀頭部增加了2字節(jié)的協(xié)議版本字段因此我用了新的上位機(jī)工具HM_FlashTool。具體操作步驟板卡斷電把BOOT引腳拉高上電進(jìn)入Bootloader在HM_FlashTool里選擇串口號波特率設(shè)置為115200不變軟件通過串口發(fā)送握手指令設(shè)備返回Bootloader版本號在工具里選擇要下載的固件包確認(rèn)固件類型為App目標(biāo)Bank可以選擇自動優(yōu)先寫入非活動Bank點擊下載工具會把固件分包發(fā)出去每包256字節(jié)等設(shè)備回ACK再發(fā)下一包下載完成后工具發(fā)送跳轉(zhuǎn)App命令設(shè)備復(fù)位并啟動App。整個過程如果用2MB的大固件串口115200波特率大約需要3分鐘左右。實際應(yīng)用固件一般200KB以內(nèi)30秒左右就能完成。如果希望更快可以把UART波特率提高到921600但前提是線纜質(zhì)量要好否則容易出現(xiàn)丟包。我的建議是保守一點先用115200跑通需要提速再改。4.3 基于LAN8720的以太網(wǎng)批量升級步驟以太網(wǎng)升級是我最推薦在產(chǎn)線使用的方案尤其是支持雙DMA脈沖輸出的運動控制板。線纜插上不用額外接BOOT引腳只要上位機(jī)發(fā)送遠(yuǎn)程升級命令板卡從App狀態(tài)下自動跳進(jìn)Bootloader即可。V9.2的以太網(wǎng)升級過程板卡在App運行狀態(tài)上位機(jī)發(fā)送預(yù)先約定好的UDP廣播升級請求App收到請求后把當(dāng)前固件狀態(tài)保存到備份區(qū)然后軟件復(fù)位進(jìn)入BootloaderBootloader啟動后初始化LAN8720和LwIP用固定IP比如10.10.10.100啟動UDP服務(wù)上位機(jī)搜索設(shè)備發(fā)現(xiàn)后發(fā)送開始升級命令按塊發(fā)送固件數(shù)據(jù)Bootloader塊校驗寫入Flash回ACK全部完成Bootloader校驗CRC32設(shè)置啟動標(biāo)記復(fù)位進(jìn)入App。這里客戶端配置需要注意LAN8720的PHY地址通過LED0/PHYAD0引腳拉高或拉低確定我板子上是地址0。LwIP初始化時對應(yīng)的PHY地址如果不對MDIO訪問不到PHY網(wǎng)口燈不亮升級自然就卡住。V9.2在初始化LAN8720時做了自動探測通過循環(huán)讀取PHY ID寄存器來確認(rèn)PHY地址避免了這種低級錯誤。批量產(chǎn)線升級時我一般會配置多臺板卡為不同的固定IP段上位機(jī)逐個掃描并行升級一次可以同時刷4到8塊板效率比串口手工刷快很多。4.4 升級失敗后的緊急恢復(fù)流程即使Bootloader寫得很穩(wěn)升級失敗也是無法完全避免的。最常出現(xiàn)的失敗場景是升級過程中斷電或以太網(wǎng)線被拔掉。V9.2為這些場景設(shè)計了一套完整的恢復(fù)流程。首先是未驗證不回滾。如果新App還沒啟動驗證成功就斷電Bootloader不會把啟動標(biāo)記切到新版本。下次上電仍然進(jìn)入舊版本如果舊版本還在或者再次回到Bootloader等待命令。如果連新固件也沒下載完整Bootloader里的CRC32校驗失敗會直接放棄本次固件。其次是雙保險恢復(fù)。如果既沒有舊版本新版本又損壞了設(shè)備會進(jìn)入一個特殊的串口恢復(fù)模式。這個模式只監(jiān)聽UART1等待上位機(jī)使用強(qiáng)制燒錄命令把固件刷進(jìn)去。我在產(chǎn)線上專門做了一個夾具USB轉(zhuǎn)串口插到調(diào)試口幾秒鐘就能救回來。最后是SWD兜底。如果上述操作都因為Bootloader自身損壞而失效只能用st-link、J-Link通過SWD直接連接MCU先擦除整個Flash再燒寫一個可用的Bootloader。對于H743/H745來說SWD在復(fù)位期間如果能連上基本都能救活前提是沒有打開RDP讀保護(hù)級別1級以上。5. V9.2與高頻應(yīng)用場景的兼容性驗證5.1 高負(fù)載場景下的LAN8720以太網(wǎng)應(yīng)用很多客戶把STM32H7配合LAN8720用來做Modbus TCP網(wǎng)關(guān)或EtherCAT從站。V9.2在Bootloader階段就能通過以太網(wǎng)升級那么在App里以太網(wǎng)功能會不會受影響我專門做了驗證。結(jié)論是如果在App初始化以太網(wǎng)之前先把Bootloader的以太網(wǎng)外設(shè)完整復(fù)位ETH_RST、MAC和DMA收發(fā)器復(fù)位不會影響App的LAN8720驅(qū)動。但如果不復(fù)位App的LwIP或者裸機(jī)驅(qū)動在初始化時可能會發(fā)現(xiàn)DMA描述符還在Bootloader的舊狀態(tài)下導(dǎo)致收發(fā)鏈路異常。解決方法是在App初始化ETH時做一次徹底的外設(shè)復(fù)位參考代碼__HAL_RCC_ETH1MAC_FORCE_RESET(); __HAL_RCC_ETH1MAC_RELEASE_RESET(); __HAL_RCC_ETH1TX_FORCE_RESET(); __HAL_RCC_ETH1TX_RELEASE_RESET(); __HAL_RCC_ETH1RX_FORCE_RESET(); __HAL_RCC_ETH1RX_RELEASE_RESET();這樣Bootloader留下的殘留狀態(tài)就完全清除了。V9.2在跳轉(zhuǎn)App前也會主動執(zhí)行一次硬件復(fù)位所以嚴(yán)格來說App側(cè)的復(fù)位不是必須但加上更保險。5.2 基于STM32CubeMX的ADC軟觸發(fā)與FOC算法升級場景ST公司在H7上推薦的FOC算法方案大多基于STM32CubeMX和Motor Control SDK生成。FOC應(yīng)用有一個特點控制頻率高采樣窗口非常短通常在幾微秒到幾十微秒。如果Bootloader在升級后被App覆蓋卻又保留了某種外設(shè)配置可能與FOC的ADC軟觸發(fā)采樣沖突。V9.2升級后首次進(jìn)入App時我會建議把ADC1/ADC2的校準(zhǔn)重新做一遍。H7的ADC有硬件偏移校準(zhǔn)offset calibration如果Bootloader在升級過程中動過ADC的校準(zhǔn)寄存器App直接使用默認(rèn)校準(zhǔn)值可能導(dǎo)致采樣偏差。這個問題在做FOC電流環(huán)時會影響電流環(huán)零漂。V9.2本身不會主動改ADC校準(zhǔn)但為了保險我在升級完成后的App初始化代碼中加了ADC校準(zhǔn)重新執(zhí)行邏輯。5.3 雙DMA脈沖輸出與多軸插補(bǔ)場景運動控制場景是我這邊最強(qiáng)調(diào)兼容性的地方?？蛻粲幸粔K板子通過雙DMA實現(xiàn)脈沖輸出8軸插補(bǔ)輸出頻率能達(dá)到500kHz3軸的話能到1MHz。這種高頻率脈沖輸出對時序要求很高DMA描述符、定時器配置都不能被Bootloader影響。V9.2在跳轉(zhuǎn)App時做了干凈退出把所有Bootloader用到的外設(shè)都恢復(fù)到復(fù)位狀態(tài)包括定時器、UART、ETH、DMA、以及GPIO。這樣App啟動時無論自己的DMA配置如何都不會受到Bootloader殘留配置的影響。另外如果你想讓Bootloader在升級過程中不干擾正在運行的電機(jī)或其他執(zhí)行器建議把升級命令設(shè)計成先停止運動再進(jìn)入Bootloader。不要在運動過程中直接復(fù)位升級因為Bootloader初始化期間所有外設(shè)都處于默認(rèn)狀態(tài)PWM輸出引腳會變成普通GPIO可能瞬間讓電機(jī)失控。我們的上位機(jī)和App之間有一個預(yù)升級握手App收到升級請求后先把使能信號置低等所有軸停止運動再延遲200ms復(fù)位。6. 常見問題與排查技巧6.1 快速定位表我把V9.2上線后遇到的典型問題整理成了一張速查表遇到問題可以對照排查?，F(xiàn)象可能原因排查方向上電后一直停在Bootloader不進(jìn)App啟動標(biāo)記被清掉或App校驗失敗串口打印Bootloader日志確認(rèn)啟動標(biāo)記狀態(tài)升級時UART發(fā)送完最后一包設(shè)備無響應(yīng)Flash寫入對齊錯誤或CRC校驗失敗看Flash錯誤標(biāo)志重新計算固件CRC以太網(wǎng)搜索不到設(shè)備LAN8720 PHY地址錯誤、RMII時鐘未配置檢查PHY ID讀取時序、REF_CLK頻率升級完成但App運行5秒后自動復(fù)位App沒有喂獨立看門狗確認(rèn)App里是否實現(xiàn)了IWDG喂狗函數(shù)雙Bank切換后App啟動但外設(shè)亂切換前沒有關(guān)閉全部外設(shè)中斷在跳轉(zhuǎn)App前做完整外設(shè)復(fù)位升級中斷電后上電可以進(jìn)Bootloader但無法再次寫入Flash扇區(qū)沒有正確擦除或選項字節(jié)被改檢查FLASH_CR的SER/SNB邏輯6.2 三個實際案例的排查過程案例一有一批設(shè)備在更新V9.2后UART升級一切正常但以太網(wǎng)升級每次傳輸?shù)郊s500KB時就會超時。排查發(fā)現(xiàn)是PHY的自動協(xié)商在長時間高負(fù)載下不穩(wěn)定把PHY的自動協(xié)商關(guān)閉、固定為100M全雙工后問題消失。LAN8720在工業(yè)環(huán)境里非常依賴這個配置。案例二有個客戶反饋App下載成功后設(shè)備無法啟動但重新上電進(jìn)入Bootloader后App的CRC校驗又是通過的。后來發(fā)現(xiàn)是App的Startup文件里設(shè)置了不同的初始棧大小而Bootloader跳轉(zhuǎn)前從App頭部讀取的棧頂?shù)刂窙]有做合法性檢查跳到了非法地址。V9.2在跳轉(zhuǎn)前增加了一個簡單的棧頂?shù)刂贩秶鷻z查非法地址則放棄跳轉(zhuǎn)。案例三V9.2在配合H745雙核運行時出現(xiàn)過一個特殊現(xiàn)象CM7內(nèi)核的Bootloader升級完成后CM4內(nèi)核的固件沒有同步更新導(dǎo)致兩個核的版本不匹配。H745是雙核芯片Bootloader需要分別處理CM7和CM4的兩個鏡像。V9.2里專門增加了雙核鏡像升級模式先升級CM7鏡像再升級CM4鏡像最后統(tǒng)一校驗。如果你用H745千萬別只刷了CM7就以為完事了。6.3 排查工具與調(diào)試心得調(diào)試Bootloader最痛苦的是看不到日志。V9.2里我把日志輸出統(tǒng)一到了UART1波特率1152008N1。如果你遇到問題建議先串口連上在Bootloader啟動的時候觀察它的日志內(nèi)容。日志等級可以根據(jù)編譯宏調(diào)整我一般會打開INFO級別關(guān)鍵流程會打印狀態(tài)標(biāo)記、將要跳轉(zhuǎn)的地址、校驗結(jié)果等。在不方便接串口的場合也可以在RAM里維護(hù)一個環(huán)形日志緩沖區(qū)然后通過升級協(xié)議把日志讀出來這個對現(xiàn)場定位很有用。V9.2里已經(jīng)內(nèi)置了遠(yuǎn)程日志功能通過UDP把最近200條日志發(fā)送給上位機(jī)現(xiàn)場排查效率高了很多。收尾一點經(jīng)驗這次從V9.1折騰到V9.2我最深的體會是Bootloader的代碼量雖然不大但它處在硬件初始化和應(yīng)用跳轉(zhuǎn)這個承上啟下的位置任何一個環(huán)境差異都會被放大。H7系列和F1/F4很不一樣Cache、雙Bank、DMA一致性這些概念如果只是照著CubeMX的模板抄很難理解為什么Bootloader要處理這么多細(xì)節(jié)。最后再分享一個小技巧如果你也在維護(hù)一個嵌入式Bootloader建議在固件頭里預(yù)留至少16字節(jié)的元信息區(qū)。當(dāng)前版本、編譯時間、Git提交號都可以放進(jìn)去。這次V9.2能這么快定位產(chǎn)線上的問題很大程度上靠的就是從固件頭里直接讀到了編譯時間排除了刷錯固件包這種低級的可能性。后續(xù)如果再升V9.3這個區(qū)域還能繼續(xù)擴(kuò)展一點不用動協(xié)議。