基于CANFD的域控制器Bootloader系統(tǒng)設(shè)計

中圖分類號：U463.6 文獻標識碼：A 文章編號：1003-8639（2025）06-0084-03 Design ofDomain ControllerBootloaderSystem Basedon CANFD YuWenhan，Chen Mingyin，Lin Zhi，F(xiàn)ang Zebin，Lin Yuyu，HuangYongbo （Guangzhou Automobile Group Co.，Ltd.，Automotive Engineering Institute，Guangzhou 510，China）

【Abstract】This paper based on the UDS diagnostic protocol and the auto factory's write specification，aset of write upper computer and domain controller Bootloader upgrade scheme based on CANFD communication is designed. Theupper computer is independentlydeveloped byTsmaster.OnlyFlash DriverandApp filescanbeimported toachieve a complete brush and write process，which is efficient andpractical.In the domaincontrolerscheme，thedesign principleofBTprogramiscompletelyproposed，inwhichAppbackupcan ensure theintegrityofECU function，and the scheme of Flash Driver downloaded toRAMenhances therobustness androbustness of theprogram.Theexperiment shows that the upper computer schemecan realize the complete process of brushing andwriting，and the domain controller Bootloader program has high stability.

【Keywords】 CANFD；ZCU；Bootloader；reprogramming

0 引言

2020年以前，汽車電子電氣架構(gòu)主要采用分布式架構(gòu)，該架構(gòu)無法應(yīng)對功能快速迭代升級和定制化生產(chǎn)的需求，也無法滿足未來汽車龐大的算力和數(shù)據(jù)要求。2023年開始，主機廠開始選擇集中式域控架構(gòu)作為解決方案。集中式域控架構(gòu)包括中央域、智駕域、信息娛樂域和區(qū)域控制等關(guān)鍵控制器。這些域控制器集成了分布式架構(gòu)下控制器的眾多功能，由于軟件迭代頻繁，所以這些控制器的軟件升級就顯得格外重要。

控制器供應(yīng)商排查整車問題時常用的是Bootloader刷新。CANFD通信可以增加通信速率1。本文依據(jù)ISO14229標準的UDS診斷協(xié)議，并結(jié)合整車廠的刷寫規(guī)范，設(shè)計一套基于CANFDUDS的BootLoader上下位機升級方案。

1車載軟件總體論述

一個可重編程的ECU包含Bootloader（BT）和App程序。Bootloader是MCU上電后運行的第一段程序2，它可初始化硬件設(shè)備、建立內(nèi)存空間的映射，也可對Flash進行擦除和編程，起到引導應(yīng)用程序和升級應(yīng)用程序的作用。簡而言之，F(xiàn)lashBootloader通過CAN總線升級App程序。一個ECU如果沒有BT，那么更新程序只能通過燒錄器，反之，則可以通過診斷接口進行升級，這在整車上是非常方便的，不用拆件[3]。僅當應(yīng)用程序無效、上電之初和軟件升級時才會運行Bootloader。ECU在多數(shù)時間執(zhí)行的是應(yīng)用程序。

Bootloader在產(chǎn)品出廠時就會固定下來，當需要更新程序時，通過BT程序?qū)pp程序進行擦除和重新寫人，即產(chǎn)品出廠后只更新App軟件。ECU正常上電走完初始化后，會判斷是否有升級請求，如果沒有則跳到App程序運行；如果有升級請求，則運行BT程序進行升級4。BT程序一般放在Flash的最開始處，App程序在其后，這樣可以獨立配置兩個區(qū)域的內(nèi)存保護。如圖1所示，App程序和BT程序占用不同的Flash，App程序和BT程序的區(qū)別在于它通過控制驅(qū)動芯片、功率芯片和通信芯片，從而具有了輸入輸出功能。

1.1 Bootloader

Bootloader是Boot加Loader，Boot是引導，用于初始化硬件設(shè)備，是為Loader做準備的。Loader是加載器，Boot準備好環(huán)境后，Loader將要執(zhí)行的程序從非易失性存儲設(shè)備中加載到內(nèi)存中運行。Bootloader通過調(diào)用特定IAP程序?qū)α硗庖欢蜦lash空間進行讀與寫操作，從而實現(xiàn)對MCU程序的更新。ECU如果有BT程序，則可通過CAN刷寫進行版本修改、升級，不用拆件，極大地方便了開發(fā)者。

圖1中，BT程序使用UDS的診斷服務(wù)作為通信協(xié)議，它具有CAN驅(qū)動、傳輸層和UDS協(xié)議層的通信堆棧。由于BT程序的重要性，它應(yīng)該被存放在已進行保護（軟件上鎖或硬件保護）的存儲區(qū)域?？紤]可能刷寫失敗導致丟失 App 程序，可以在Flash中增加App備份、BT備份程序。

1.2 Flash Driver

本文FlashDriver指MCU廠商提供的擦寫Flash的驅(qū)動函數(shù)，當升級時，F(xiàn)lashDriver會被臨時下載到RAM中，軟件升級完成后復位就會刪除。這樣可以避免程序正常運行中誤調(diào)用FlashDriver導致Flash程序被改寫。

?

FlashDriver至少包含四個Flash接口函數(shù)：初始化、反初始化、擦除和寫入。初始化函數(shù)，BT程序調(diào)用此函數(shù)為Flash編程執(zhí)行硬件特定的初始化；反初始化函數(shù)，下載完成后，BT調(diào)用此函數(shù)執(zhí)行特定的硬件操作來完成Flash編程，擦除函數(shù)，BT程序調(diào)用此函數(shù)擦除指定的內(nèi)存區(qū)域；寫入函數(shù)，BT程序調(diào)用此函數(shù)把數(shù)據(jù)寫進Flash。

1.3 Flash Tool

FlashTool可以使用 C++^[6] 、C#等進行開發(fā)。如圖2所示，刷寫上位機導入安全算法文件、FlashDriver、App文件后自動解析出 bin 文件里的起始地址、長度等信息，通過CAN卡（CANoe、Vspy、Kvaser、同星等）發(fā)送診斷報文與下位機進行交互9。下位機接收到診斷報文后調(diào)用FlashDriver里的擦寫函數(shù)進行App程序升級。如果上位機發(fā)報文格式錯誤或者下位機響應(yīng)錯誤都將導致刷寫失敗。

FlashTool下載流程如下。

1）讀取編譯后的目標文件（s19、hex）。

2）控制下載流程。

3）基于協(xié)議執(zhí)行數(shù)據(jù)傳輸。

4）執(zhí)行驗證。

2 BT程序軟件設(shè)計

復位后，ECU從BT程序開始運行，確保BT程序不受特定應(yīng)用程序硬件設(shè)置的影響。為確保BT程序不被修改，有些MCU廠商還會給BT程序加鎖實現(xiàn)保護。

2.1 Flash重編程規(guī)范

如圖3所示，ECU啟動完成初始化后判斷是否有外部升級請求，有則跳到BT程序；沒有則判斷App程序是否有效，有效則跳到 App 程序，無效則跳到BT程序。

?

ISO14229系列標準定義的統(tǒng)一診斷服務(wù)（Uni-fiedDiagnosticServices，UDS）診斷協(xié)議是用于汽車行業(yè)診斷通信的需求規(guī)范。表1是刷寫常用的診斷服務(wù)[0]?；赨DS診斷協(xié)議和整車廠的刷寫規(guī)范，將刷寫分為三個步驟：預編程、服務(wù)器編程和后編程。

2.2 預編程

預編程通過物理尋址和功能尋址發(fā)送診斷報文為編程網(wǎng)絡(luò)準備網(wǎng)絡(luò)。檢查編程條件是為了判斷當前條件是否可以升級。當條件不滿足時（高壓上電、低壓異常或車速不為0），刷新服務(wù)請求將被拒絕。關(guān)閉DTC記錄和所有非診斷報文傳輸是為了降低總線負載率，為接下來的服務(wù)器編程準備網(wǎng)絡(luò)。預編程步驟如圖4所示。

?

22服務(wù)讀取 擴展模式 檢查編程條件 預編程 ＼22xx＼yy10＼0331＼0102＼01003 停發(fā)非診斷報文 關(guān)閉DTC檢測 ＼0028＼0301 ＼8502

2.3 服務(wù)器編程

服務(wù)器編程是整個編程步驟的重點，它包含了安全算法、寫指紋信息、下載FlashDriver、升級App程序、校驗程序完整性一致性等關(guān)鍵步驟。

ECU收到1002指令后將外部刷新請求標志位設(shè)置為有效并執(zhí)行ECU重啟。解鎖ECU，F(xiàn)lashTool向ECU請求種子，F(xiàn)lashTool和ECU都計算出密鑰，F(xiàn)lashTool將密鑰發(fā)送給ECU。ECU將匹配自己算出的值和FlashTool收到的密鑰值，如果一致，則通過安全算法。寫指紋信息是將診斷儀完成的刷寫信息寫進ECU，這樣可以追溯到對應(yīng)的診斷儀。

因為Flash中存儲FlashDriver有風險，所以FlashDriver是通過34、36、37服務(wù)下載到RAM。如圖5所示，寫App程序需要參數(shù)為 31～＼ S 01 FF" "00 的RoutineControl服務(wù)請求擦除請求的邏輯塊。邏輯塊的所有段都通過服務(wù)RequestDownload（參數(shù)為起始地址和段的長度）、TransferData和RequestTransfer-Exit的序列下載到ECU。在34服務(wù)之后，段的所有數(shù)據(jù)字節(jié)由36服務(wù)傳輸。傳輸完所有的段字節(jié)后，使用37服務(wù)結(jié)束下載。

2.4 后編程

如圖6所示，后編程步驟由2E服務(wù)和硬復位等步驟完成。寫編程日期將編程日期寫入Flash中，可以追溯到最近一次刷寫的時間。硬復位將重啟ECU并最終跳轉(zhuǎn)到App程序運行。

?

?

3試驗

本文基于域控制器進行CANFD的刷寫試驗，采用同星TC1013為刷寫CAN卡，同星配套軟件Tsmas-ter為上位機。假如刷寫條件（供電電壓、車速等）不滿足，刷寫會失??；假如刷寫過程中斷電，由于有App備份，ECU依然具有備份的App程序。整個試驗過程檢驗了FlashTool上位機的功能，也檢驗了域控制器的BT程序。整個刷寫流程滿足國標和企標要求，試驗成功。如圖7所示。

4結(jié)束語

本文依據(jù)ISO14229標準的UDS診斷協(xié)議，并結(jié)合整車廠的刷寫規(guī)范，設(shè)計了一套基于CANFDUDS的Bootloader上位機和域控制器升級方案。上位機采用同星配套軟件Tsmaster，上位機方案自主開發(fā)出刷寫界面，只用導人FlashDriver和App文件即可，高效實用。上位機方案完整地提出了刷寫的流程。域控制器升級方案中完整地提出了BT程序的設(shè)計原理，其中App備份可以保證ECU功能的完整性。FlashDriver臨時下載到RAM中的方案增強了程序的魯棒性和健壯性。

參考文獻：

[1]潘文卿，劉興義，王飛飛．CANFD協(xié)議在程序刷寫中的研究與應(yīng)用[J].汽車電器，2021（12）：36-38，41.

[2]凌露露，趙芬.車載毫米波雷達Bootloader的設(shè)計與實現(xiàn)[J].電腦知識與技術(shù)，2021（9）：218-220.

[3]陳睿智，石春，吳剛，等.面向OTA需求的汽車電控單元Bootloader設(shè)計[J].儀表技術(shù)，2021（2）：8-12，22.

[4]李鑫，李艷明，王志遠，等.基于CAN總線電氣綜合控制盒Bootloader軟件的設(shè)計與實現(xiàn)[J].車輛與動力技術(shù)，2021（1）：39-42，54.

[5]李興國，周榮，李旭.基于PowerPC系列處理器的Boot-loader設(shè)計與應(yīng)用[J].鐵路通信信號工程技術(shù)，2020，17（1）：34-37.

[6]袁鋒，丁元章，張偉，等.基于S32K148的車輛網(wǎng)關(guān)CANBootloader開發(fā)與實現(xiàn)[J].汽車電器，2021（12）：30-32，35.

[7]唐恒飛，王效金.基于UDS協(xié)議的汽車控制器刷寫軟件設(shè)計[J].智能計算機與應(yīng)用，2021，11（1）：102-105

[8]么居標，宋建桐，呂江毅，等.基于CAN總線的電機控制器Bootloader開發(fā)[J].測控技術(shù)，2018，37（10）：124-126，131.

[9]楊朝陽，黃凱旋，仝秀峰，等.基于UDS的Bootloader上下位機設(shè)計[J].軟件，2023，44（7）：42-47.

[10]趙鑫.基于CAN總線的多控制器軟件刷寫技術(shù)的研究與實現(xiàn)[D].武漢：武漢科技大學，2022.

（編輯楊凱麟）

?