汽車Bootloader的案例
詳解汽車Bootloader設計
來源 |
汽車ECU開發
BootLoader(下文簡稱Boot)也稱為引導程序，其主要用于軟件更新。這就帶來一個問題，ECU的軟件更新方式有很多，比如通過JTAG調試更新軟件，為什么要Boot呢？
由于ECU軟件中難免會有BUG存在，以及要滿足整車OTA需求，必須可以在不開蓋的情況下更新軟件。而ECU控制器對外的接口通常只有總線、電源和控制IO等。出于最大化復用接口(減少線束的重量和成本）考慮，通常采用基于UDS的Boot，而最常用的總線為CAN。為什么不用JTAG口呢？主要是ECU裝車后，直接通過燒錄器或者仿真器更新軟件的很不方便，難以實現遠程更新，另外由于JTAG口的權限很高，可以任意修改內部程序，安全風險很大。
BootLoader的設計需求
Boot除了正常滿足更新軟件需求外，還需滿足以下需求。
1、安全需求
Boot和APP應該放在不同的內存區域，防止相互干擾。Boot中不應集成Flash Driver，避免程序在正常運行時非法修改FLash，導致軟件異常，通常在刷寫App或者標定數據時，先將Flash Driver下載至芯片的RAM中。
另外，在Boot執行App或者標定數據更新時，應該具有多重安全檢查機制，確保刷入正確的軟件。
首先在執行刷寫流程之前，上位機對需要更新的軟件包進行檢查，通常包括兩項，其一是在生成軟件包時，開發人員會在特定位置增加一個與上位機約定的特定的ID，當上位機加載軟件包時，會去檢查軟件包中存儲的ID是否與上位機中相同，如果不同，則終止刷寫，這樣可以防止刷入其他ECU的軟件包。
展開 汽車電控系統bootloader知識介紹
汽車明確規定通過UDS進行更新程序，主機廠要求擦寫內部存儲的代碼不可寫入正常代碼中。汽車電子中ECU一旦設計完成，裝車量產就很難再拆卸并返回零部件供應商完成功能升級或補丁修復。一旦出現售后質量問題，如果召回的話，零部件供應商和整車廠將面臨嚴重的經濟損失，因此設計基于CAN總線的ECU在線程序更新Bootloader可以很好的解決這一問題，將零部件供應商和整車廠的損失降低到最小。目前國外大部分汽車整機廠（主機廠）和全球的一級汽車零部件供應商 (Tier 1) 都要求在其設計的ECU實現Bootloader功能。
圖1-3 Bootloader簡易框圖
假如使用CAN，框架則會設計成如圖1-3。
2.3 Bootloader框架
Bootloader由主機廠或者自己，可以選擇用或者不用，本次主要針對使用Bootloader情況進行分析。主機使用協議由自己進行定義，ECU啟動模式選擇由芯片廠商進行技術支持（如果沒有廠商支持是不可以的，是不被主機廠認可的，大多數是購買商業軟件包，由服務商進行技術支持與芯片廠商共同支持的）。內部編寫均需要遵循協議，大多數開發都是由多年開發經驗沉淀下來，修改而成的，協議依然在進步，代碼可能無法維護而無法支持，主機廠也會被迫選擇使用舊版協議。
圖1-4 Bootloader架構
2.4 ECU Bootloader原理
主機廠規定不可把擦寫內部代碼的功能直接寫入程序中，因此，只能每次用時才能將代碼放入ECU，ECU內部可以有Bootloader，但不可以有擦寫內部代碼的功能，擦寫代碼的功能稱作NVM (None Valitale Momory–非易失性存儲器)驅動程序。
展開 LabVIEW技能加持，完美實現，汽車行業復雜測試
比如本公眾號的下面的圖片，帶邊緣陰影和淡紅色水印，都是自己做出來的，里面用到了很復雜的底層數學處理邏輯
CANDE汽車網絡設計平臺。用到了很復雜的報文結構體處理邏輯，使得師子一號堅定認為：數據結構是代碼的核心
收銀軟件。用LabVIEW+C#實現，走的支付寶的支付通道。
軟件加密技術。用的是LabVIEW直接控制MBR保留分區字節，以及對BIOS的控制技術，使用了自己開發了一個DLL。
Excel2DBC工具
。純LabVIEW實現，這個軟件目前正在無償共享給廣大同行。毫不謙虛地說，
是目前業內最好用的轉換工具，也是我們在LabVIEW領域雄厚實力的證明
。有需要的朋友，可以轉發一下本文并截圖發給我，免費領取工具。
PID仿真及控制。
對ActiveX的調用。調用Excel，實現形形色 色的自動報告格式
汽車UDS診斷。
汽車NM網絡管理。
汽車BOOTloader。
示波器數據的獲取和分析。
前面板控件自動布局。這個是Labview的軟肋，縮放幾次就扭曲了，所以我自己做了個程序，自動識別前面板大小、各個控件的大小及在前面板的坐標，從而實現動態自動布局。不過，一般而言，我們使用labview的目的是實現功能，對界面的美觀度要求一般不高。
LabVIEW憑借著簡單易用的特性，以及強大的擴展功能，給我帶來了太多的驚喜，也幫我解決了不少的問題。
展開 