BootLoad（簡稱Boot）是一種啟動加載程序，或者稱為引導程序，我們在操作系統和嵌入式開發中經常用到，因為汽車ECU也是一種嵌入式系統，Boot程序主要用于ECU軟件更新，汽車OTA升級，本文主要講述汽車bootloader程序的工作原理和設計方法。

01

bootloader的功能

BootLoader，通常是駐留在ECU非易失性存儲器（NVM，None Valitale Momory）中的一段程序加載代碼，每次ECU復位后，都會運行bootloader。它會檢查是否有來自通信總線的遠程程序加載請求。

如果有，則進入bootloader模式，建立與程序下載端（通常為PC上位機）的總線通信并接收通信總線下載的應用程序、解析其地址和數據代碼，運行NVM驅動程序，將其編程到NVM中，并校驗其完整性，從而完成應用程序更新。

如果沒有來自通信總線的遠程程序加載請求，則直接跳轉到應用程序復位入口函數（復位中斷ISR，也稱作Entry_Point（）–使用Processor Expert的CodeWarrior 工程或者Startup（）函數–普通CodeWarrior 工程），運行應用程序。

因此，汽車ECU的bootloader三個主要的作用：

與遠程程序下載端建立可靠的總線通信以獲取要更新應用程序；

解析應用程序編程文件（S19/HEX/BIN）獲得其在NVM中的地址和程序代碼及數據；

運行NVM驅動將應用程序的代碼和數據編程到NVM中并校驗；

下面就圍繞這三個方面展開講述。

02

如何建立可靠的總線通信？

汽車ECU常見的數據總線有CAN和LIN，因此通常汽車ECU的bootloader都是通過CAN或者LIN下載數據的。當然也可以基于其他總線，比如基于SPI總線或者I2C總線（典型如一些帶有安全監測的功能安全ECU，通過主MCU對功能安全監測MCU的程序進行升級）以及以太網（基于Enternet通信的中控或者全液晶儀表的ECU以及下一代高速網關和ADAS ECU）。

注意事項：

不同的ECU通信總線不一樣，具體需要用到某種通信總線取決于實際應用;

通信總線由ECU的MCU外設實現，所以在bootloader中必須開發相應的通信總線外設驅動程序，實現基本的數據發送和接收功能；

為了保證通信的可靠性，必須開發一個基于通信總線完善的通信協議，應用程序下載端和bootloader之間需要建立請求命令（request command）、確認（acknowledge）、等待（block wait）、錯誤重傳（errorre-send）等機制----bootloader根據不同的請求命令完成不同的任務并確認操作是否完成（ACK）以及數據是否正被確完整的傳輸，若出現數據錯誤（通過校驗和或者ECC實現），需要進行自動重傳；

應用程序下載端通過需要在PC上基于VC或者C#、QT、Labview等開發GUI軟件，實現中要求的總線通信協議，一般在其底層都是通過調用相應的總線設備，如USB轉CAN/LIN的轉發器設備的動態庫（DLL）的API接口來實現數據的收發，相應的總線USB轉發設備都會提供相應的驅動庫（DLL）。因此bootloader開發者一般還需具備一定的PC上位機軟件開發能力；

為了實現數據的可靠傳輸，一般在總線通信協議中添加信源編碼，即在發送是對有效數據進行校驗和或者ECC計算并將結果在通信數據幀中和有效數據一起發送，bootloader接收端，接收到數據幀后對有效數據域進行發送端同樣的校驗和或者ECC計算，得出結果與接收到的校驗和或者ECC計算結果值進行比較從而判斷數據的完整性。應用程序編程文件（S19/HEX/BIN）都具有相應的校驗機制，所以可以采取直接傳送程序編程文件行的方式；

否則，用戶需要在上位機軟件中首先解析編程文件，再將其中的地址和數據及代碼封裝打包成某種定制的通信協議，在bootloader中還得對其進行解包，這樣一來，略顯麻煩，但有些主機廠為了知識產權保護，有自己的bootloader協議，這種情況下，bootloader開發者就必須按照主機廠的要求來開發；

一些正規的大主機廠要求其ECU供應商開發放入ECU bootloader必須基于UDS等總線診斷協議，在UDS中規定了相應的CAN ID給bootloader使用，那么就必須在該類ECU中的bootloader工程中加入相應的UDS協議棧；

3和5的注意事項都是為了滿足Boot程序設計的安全要求，要特別重視。

03

解析編程文件（S19/HEX/BIN）

不同的MCU軟件開發IDE編譯鏈接生成的編程文件格式可能不同，但S19、HEX和BIN文件之間是可以相互轉化的，所以只需要在bootloader中開一種編程文件的解析程序就可以了，其他的可以使用相應的轉換工具（convert tool）在上位機上進行轉換;MCU的軟件開發IDE一般都集成不同編程文件之間的轉換工具：比如S32DS的objcopy（Create Flash Image ）以及Keil的Motorola S-Record to BINARY File Converter 。

解析編程文件的目的在于獲得應用程序的程序代碼和數據及其在NVM中的存儲地址；

為了解析編程文件必須先了解其中的編碼格式和原理，常用的S19、HEX和BIN文件的格式說明請自行查閱。

S19和HEX文件都是可以直接使用文本編輯器（比如記事本，notepad++）打開的，只需要將包含地址和數據代碼的S1、S2和S3開始的S19文件行合并即可，可以手動拷貝，也可以編寫window批處理腳本來處理；當然也有專門的可以支持兩個S19文件的合并，網上可以找到很多開源軟件，比如常見的Srecord等；

04

NVM驅動程序開發

ECU的NVM一般包括：

MCU片內集成的用于存放數據的EEPROM或者Data-Flash;

用于存儲程序代碼/數據的Code-Flash/Program-Flash;

MPU擴展的片外NORFlash或者NAND-Flash；

NVM驅動程序 的作用包括

對NVM的擦除（erase）、編程（program）和校驗（verify）等基本操作；

對NVM的加密（secure）/解密（unsecure）和加保護（protecTIon）/解保護（unprotecTIon）操作。

注意事項：

MCU片上集成的NVM中EEPROM/D-Flash和C_Flash/P-Flash一般屬于不同的block，所以可以直接在Flash上運行NVM驅動對EEPROM/D-Flash進行擦除和編程操作；

NVM驅動一般都是通過運行一個NVM command序列，在其中通過NVM控制器寄存器給出不同的NVM操作命令代碼、NVM編程數據和目標地址的方式完成，典型的NVM command序列有（Freescale的S12（X）系列MCU Flash write command 序列）；

由于NVM的工作速度一般較CPU內核頻率和總線頻率低，所以運行NVM驅動前必須對NVM進行初始化，將設置分頻器其工作頻率設置為正常工作所需頻率范圍；

MCU片內的NVM同一個block上不能運行NVM的驅動對其自身進行擦除和編程操作，否則會傳出read while write的總線訪問沖突（每個NVM block只有一條數據總線，一個時刻只能進行讀出或者寫入，不支持同時讀出和寫入）。

因此對于僅有一個block Flash的MCU來說，就必須在RAM中調用其NVM驅動，來對其自身進行擦除和編程操作，同時在launch Flash command到等待command完成期間必須關閉CPU全局中斷，禁止外設中斷響應，否則取中斷向量和運行中斷ISR都會訪問Flash。要使能中斷，就必須將中斷向量表偏移到RAM或者NVM block（EEPROM/D-Flash）并將響應的中斷ISR也拷貝到其他RAM或者NVM block上（當然該中斷向量表也必須更新指導新的中斷ISR）；

由于以上2的要求，通常需要將bootloader的NVM驅動拷貝到MCU的RAM中運行，其可以將其完成的NVM拷貝到RAM中運行，也可以只拷貝NVM command launch到等待command完成的幾條指令到RAM執行即可，因為NVM驅動中其他操作（比如填寫NVM操作命令、寫入編程地址和數據等）并不會往占用數據總線上往NVM中寫入數據；

NVM的驅動程序駐留在Flash中，如果出現堆棧溢出等意外程序跑飛意外運行NVM驅動程序則會造成NVM內容意外擦除丟失或者修改的情況。因此需要對關鍵數據或代碼（比如bootloader本身）進行保護以防止意外修改，或者更為安全的方法是**不將NVM驅動程序存放在NVM中，而是在bootloader最開始通過上位機將其下載到RAM中運行，bootloader結束后將該區域RAM清除，**從而避免由于意外運行NVM驅動程序造成的NVM數據丟失和修改。

一般MCU廠商都會給出其MCU的NVM驅動庫，用戶可以使用該類庫實現NVM操作，如果是Freescale/NXP的汽車級MCU，還可以使用CodeWarrior IDE集成的Processor Expert生成相應的NVM驅動程序；

02

bootloader開發的其他要點

1. bootloader與應用程序的關系：

bootloader和應用程序分別是兩個完整的MCU軟件工程，各自都由自己的啟動代碼、main（）函數、鏈接文件、外設驅動程序和中斷向量表；

因此bootloader和應用程序的鏈接文件中，對NVM的地址空間分配必須分開獨立，不能重疊（overlap），但其RAM分配沒有約束，兩者都可以使用整個RAM空間，因為跳轉到應用工程后，將啟動代碼將重新初始化RAM；

bootloader必須使用MCU默認的中斷向量表，因為每次復位后MCU都是從其默認中斷向量表的復位向量取地址執行的；應用程序的中斷向量必須進行偏移（通過相應的中斷向量偏移寄存器，如S12（X）系列MCU的IVBR寄存器或者ARM Cortex M系列MCU的SCB-》VTOR寄存器）；

而NVM（P-Flash）的擦除都是按照sector進行的，所以為了充分利用NVM（P-Flash）空間，都將bootloader分區到包含默認中斷向量表的若干NVM（P-Flash）sector（S12（X）系列MCU的NVM最后若干sector， ARM Cortex M系列MCU從0地址開始的若干sector）；

注意：

如果應用程序新過程中斷電或者意外復位，則應用程序更新失敗，相應的應用程序完整性校驗通不過，當然得重新下載，為了避免這種情況下應用程序丟失，常常BootLoader需要對應用程序進行雙備份，即使用兩個不同的NVM分區來保存應用程序，只有新的應用程序更新成功之后，才擦除老的應用程序，否則下次復位之后還是運行老的應用程序

2. bootloader到應用程序的跳轉方法：

開發使用bootloader后，每次ECU復位之后都將首先運行bootloader，若無遠程應用程序下載請求則直接跳轉到應用程序復位函數地址，這里面有兩個問題需要考慮：

如何獲得應用程序復位函數地址：方法有：1）通過鏈接文件固定應用程序的復位啟動函數地址；2）從應用程序中斷向量表的復位向量地址獲取；推薦方法2）：因為其靈活性好，每次應用程序變化后無需關心應用程序復位函數被編譯到了NVM的具體地址，只需要將應用程序中斷向量表中的復位向量取出運行即可：

典型方法如下（假設S12（X）系列MCU的應用程序中斷向量表基地址寄存器IVBR=0x7F）：

typedef void （near tIsrFunc）（void）;/ ISR prototype definition */

word *Ptr; /pointer used for ISR vector fecth/

Ptr = （word *）0x7FFE; /*get the ISR vector from the interrupt vector table of APP project */

（（tIsrFunc）（*Ptr））（）; /covert and run/

跳轉時機：方法有：

1）bootloader更新完應用程序并校驗其完整性OK之后，將用到的外設（比如CAN/LIN通信總線模塊、定時器、GPIO等）寄存器恢復到復位后的默認狀態，然后直接跳轉；bootloader更新完應用程序并校驗其完整性OK之后，等待看門狗定時器超時溢出復位，在bootloader最開始判斷無遠程應用程序下載請求而跳轉；

推薦使用方法2）：因為方法1）相對于軟件復位，其跳轉至應用程序復位啟動函數時MCU的硬件環境與直接運行應用程序可能存在差異，而方法2）的看門狗復位則屬于硬件復位，其會將絕大部分外設（模擬、時鐘和外設）電路復位，更接近直接運行應用程序的情況。

編輯：jq