随着半導體技術的不斷進步（按照摩爾定律），MCU内部內建的邏輯功能外設越來越多，存儲器也越來越大。消費者對于汽車節能（經濟和法規對排放的要求）型、舒适性、互聯性、安全性（功能安全和資訊安全）的要求越來越高，特别是近年來新能源電動車、車聯網和自動駕駛技術的興起，更大大加速了汽車電子技術的發展。汽車電子ECU（Electronic Control Unit--電控單元）內建的功能日益複雜，為了應對軟體遠端（線上）功能更新（增加新的功能）和bug修複的需求、對bootLoader（啟動加載程式）的需求越來越多。本文詳細介紹了汽車電子ECU bootloader的一般性工作原理和開發要點，其适用于所有的汽車電子ECU bootloader開發。
一、bootloader的功能
BootLoader，顧名思義，就是駐留在ECU非易失性存儲器中的一段程式加載代碼，每次ECU複位後，都會運作bootloader。它會檢查是否有來自通信總線的遠端程式加載請求，如果有，則進入bootloader模式，建立與程式下載下傳端（通常為PC上位機）的總線通信并接收通信總線下載下傳的應用程式、解析其位址和資料代碼，運作NVM（None Valitale Momory--非易失性存儲器）驅動程式，将其程式設計到NVM中，并校驗其完整性，進而完成應用程式更新。如果沒有來自通信總線的遠端程式加載請求，則直接跳轉到應用程式複位入口函數（複位中斷ISR，也稱作Entry_Point（）--使用Processor Expert的CodeWarrior 工程或者Startup（）函數--普通CodeWarrior 工程），運作應用程式。
基于此，汽車ECU的bootloader三大主要概念如下：
與遠端程式下載下傳端建立可靠的總線通信以擷取要更新應用程式；
解析應用程式程式設計檔案（S19/HEX/BIN）獲得其在NVM中的位址和程式代碼及資料；
運作NVM驅動将應用程式的代碼和資料程式設計到NVM中并校驗；
二、如何建立可靠的總線通信？
汽車ECU常見的資料總線有CAN和LIN，是以通常汽車ECU的bootloader都是通過CAN或者LIN下載下傳資料的。當然也可以基于其他總線，比如基于SPI總線或者I2C總線（典型如一些帶有安全監測的功能安全ECU，通過主MCU對功能安全監測MCU的程式進行更新）以及以太網（基于Enternet通信的中控或者全液晶儀表的ECU以及下一代高速網關和ADAS ECU）。
TIps：
a、不同的ECU通信總線不一樣，具體需要用到某種通信總線取決于實際應用;
b、通信總線有ECU的MCU外設實作，是以在bootloader中必須開發相應的通信總線外設驅動程式，實作基本的資料發送和接收功能；
c、為了保證通信的可靠性，必須開發一個基于通信總線完善的通信協定，應用程式下載下傳端和bootloader之間需要建立請求指令（request command）、确認（acknowledge）、等待（block wait）、錯誤重傳（error re-send）等機制----bootloader根據不同的請求指令完成不同的任務并确認操作是否完成（ACK）以及資料是否正被确完整的傳輸，若出現資料錯誤（通過校驗和或者ECC實作），需要進行自動重傳；
d、應用程式下載下傳端通過需要在PC上基于VC或者C#、QT、Labview等開發GUI軟體，實作c中要求的總線通信協定，一般在其底層都是通過調用相應的總線裝置，如USB轉CAN/LIN的轉發器裝置的動态庫（DLL）的API接口來實作資料的收發，相應的總線USB轉發裝置都會提供相應的驅動庫（DLL）。是以bootloader開發者一般還需具備一定的PC上位機軟體開發能力；
e、為了實作資料的可靠傳輸，一般在總線通信協定中添加信源編碼，即在發送是對有效資料進行校驗和或者ECC計算并将結果在通信資料幀中和有效資料一起發送，bootloader接收端，接收到資料幀後對有效資料域進行發送端同樣的校驗和或者ECC計算，得出結果與接收到的校驗和或者ECC計算結果值進行比較進而判斷資料的完整性。應用程式程式設計檔案（S19/HEX/BIN）都具有相應的校驗和機制，是以可以采取直接傳送程式程式設計檔案行的方式；否則，使用者需要在上位機軟體中首先解析程式設計檔案，再将其中的位址和資料及代碼封裝打包成某種定制的通信協定，在bootloader中還得對其進行解包，這樣一來，略顯麻煩，但有些主機廠（Car OEM）為了知識産權保護，有自己的bootloader協定，這種情況下，bootloader開發者就必須按照主機廠的要求來開發；
f、一些正規的大主機廠要求其ECU供應商開發放入ECU bootloader必須基于UDS等總線診斷協定，在UDS中規定了相應的CAN ID給bootloader使用，那麼久必須在該類ECU中的bootloader工程中加入相應的UDS協定棧；
三、解析程式設計檔案（S19/HEX/BIN）
不同的MCU軟體開發IDE編譯連結生成的程式設計檔案格式可能不同，但S19、HEX和BIN檔案之間是可以互相轉化的，是以隻需要在bootloader中開一種程式設計檔案的解析程式就可以了，其他的可以使用相應的轉換工具（convert tool）在上位機上進行轉換;
對程式設計檔案的解析，目的在于獲得應用程式的程式代碼和資料及其在NVM中的存儲位址；
為了解析程式設計檔案必須先了解其中的編碼格式和原理，常用的S19、HEX和BIN檔案的格式說明請參考如下維基百科連結：
S19檔案：https://en.wikipedia.org/wiki/SREC_（file_format）
HEX檔案：https://en.wikipedia.org/wiki/Intel_HEX
BIN檔案：https://en.wikipedia.org/wiki/Binary_file
TIps：
S19和HEX檔案都是可以直接使用文本編輯器（比如記事本，notepad++）打開的，隻需要将包含位址和資料代碼的S1、S2和S3開始的S19檔案行合并即可，可以手動拷貝，也可以編寫window批處理腳本來處理；當然也有專門的可以支援兩個S19檔案的合并，網上可以找到很多開源軟體，比如常見的Srecord等；
MCU的軟體開發IDE一般都內建不同程式設計檔案之間的轉換工具：比如S32DS的objcopy（Create Flash Image ）
以及Keil的Motorola S-Record to BINARY File Converter http://www.keil.com/download/docs/10.asp
四、NVM驅動程式開發
ECU的NVM一般包括其MCU片内內建的用于存放資料的EEPROM或者Data-Flash和用于存儲程式代碼/資料的Code-Flash/Program-Flash以及MPU擴充的片外NOR Flash或者NAND-Flash；NVM驅動程式包括對NVM的擦除（erase）、程式設計（program）和校驗（verify）等基本操作，也包括對NVM的加密（secure）/解密（unsecure）和加保護（protecTIon）/解保護（unprotecTIon）操作。
Tips：
a、MCU片上內建的NVM中EEPROM/D-Flash和C_Flash/P-Flash一般屬于不同的block，是以可以直接在Flash上運作NVM驅動對EEPROM/D-Flash進行擦除和程式設計操作；
b、NVM驅動一般都是通過運作一個NVM command序列，在其中通過NVM控制器寄存器給出不同的NVM操作指令代碼、NVM程式設計資料和目标位址的方式完成，典型的NVM command序列如下（Freescale的S12（X）系列MCU Flash write command 序列）：
c、由于NVM的工作速度一般較CPU核心頻率和總線頻率低，是以運作NVM驅動前必須對NVM進行初始化，将設定分頻器其工作頻率設定為正常工作所需頻率範圍；
d、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）；
e、由于以上b的要求，通常需要将bootloader的NVM驅動拷貝到MCU的RAM中運作，其可以将其完成的NVM拷貝到RAM中運作，也可以隻拷貝NVM command launch到等待command完成的幾條指令到RAM執行即可，因為NVM驅動中其他操作（比如填寫NVM操作指令、寫入程式設計位址和資料等）并不會往占用資料總線上往NVM中寫入資料；
f、NVM的驅動程式駐留在Flash中，如果出現堆棧溢出等意外程式跑飛意外運作NVM驅動程式則會造成NVM内容意外擦除丢失或者修改的情況。是以需要對關鍵資料或代碼（比如bootloader本身）進行保護以防止意外修改，或者更為安全的方法是不将NVM驅動程式存放在NVM中，而是在bootloader最開始通過上位機将其下載下傳到RAM中運作，bootloader結束後将該區域RAM清除，進而避免由于意外運作NVM驅動程式造成的NVM資料丢失和修改。（PS：後續我會專門寫一篇文章介紹相關的方法，盡請關注閱讀）
g、一般MCU廠商都會給出其MCU的NVM驅動庫，使用者可以使用該類庫實作NVM操作，如果是Freescale/NXP的汽車級MCU，還可以使用CodeWarrior IDE內建的Processor Expert生成相應的NVM驅動程式；
五、bootloader開發的其他要點
a、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）；
Tips：
如果應用程式新過程中斷電或者意外複位，則應用程式更新失敗，相應的應用程式完整性校驗通不過，當然得重新下載下傳，為了避免這種情況下應用程式丢失，常常BootLoader需要對應用程式進行雙備份，即使用兩個不同的NVM分區來儲存應用程式，隻有新的應用程式更新成功之後，才擦除老的應用程式，否則下次複位之後還是運作老的應用程式
b、bootloader到應用程式的跳轉方法
開發使用bootloader後，每次ECU複位之後都将首先運作bootloader，若無遠端應用程式下載下傳請求則直接跳轉到應用程式複位函數位址，這裡面有兩個問題需要考慮：
如何獲得應用程式複位函數位址：方法有：1）通過連結檔案固定應用程式的複位啟動函數位址；2）從應用程式中斷向量表的複位向量位址擷取；推薦方法2）：因為其靈活性好，每次應用程式變化後無需關心應用程式複位函數被編譯到了NVM的具體位址，隻需要将應用程式中斷向量表中的複位向量取出運作即可：
典型方法如下（假設S12（X）系列MCU的應用程式中斷向量表基位址寄存器IVBR=0x7F）：
typedef void （*near tIsrFunc）（void）;
word *Ptr;
Ptr = （word *）0x7FFE;
（（tIsrFunc）（*Ptr））（）;
跳轉時機：方法有：1）bootloader更新完應用程式并校驗其完整性OK之後，将用到的外設（比如CAN/LIN通信總線子產品、定時器、GPIO等）寄存器恢複到複位後的預設狀态，然後直接跳轉；bootloader更新完應用程式并校驗其完整性OK之後，等待看門狗定時器逾時溢出複位，在bootloader最開始判斷無遠端應用程式下載下傳請求而跳轉；推薦使用方法2）：因為方法1）相對于軟體複位，其跳轉至應用程式複位啟動函數時MCU的硬體環境與直接運作應用程式可能存在差異，而方法2）的看門狗複位則屬于硬體複位，其會将絕大部分外設（模拟、時鐘和外設）電路複位，更接近直接運作應用程式的情況。
c、開發bootloader需要掌握的知識和調試方法技巧
首先，開發bootloader需要對ECU所用的MCU的RAM和NVM資源十厘清楚，然後對其進行分區，保證應用程式和bootloader的NVM配置設定沒有重疊。是以必須了解所用軟體開發工具IDE的連結檔案的使用方法和編寫規則；
然後，需要判斷中斷向量表偏移是否成功，NVM驅動拷貝的位址和大小等資訊，是以必須掌握所用軟體開發工具IDE的編譯連結結果中map檔案的具體資訊；
此外，掌握如何将NVM函數重定向（将函數程式代碼的存儲位址和運作時位址分開）到RAM中執行的方法也十分有用；
Tips：
在開發應用程式時，需要先對其進行單獨調試以保證其功能正常，這時雖然其外設中斷向量表已經進行了偏移，但其複位向量必須的放置在預設中斷向量表中複位向量所在的位址，否則下載下傳後無法運作，進行正常調試，因為如果把應用程式的複位向量放在偏移後的應用程式中斷向量表中，則預設的複位向量内容為0xFFFF（Flash擦除後的狀态），CPU核心就會到0xFFFF的位址取指運作，顯然不是真實的工程啟動函數，是以無法運作，其結果跟一個新MCU未寫入任何程式時上電運作的情況一樣，會不斷的出現非法位址複位；而在應用程式開發完成後，再将其偏移到應用程式中斷向量中，以避免與bootloader工程的Flash位址沖突；
最後，掌握利用調試器的Hotsync或者attach方法加載elf檔案中的調試資訊對bootloader和應用程式進行無縫調試也是非常實用的，可以大大提高bootloader的調試效率；
d、量産時bootloader和應用程式的下載下傳方法
推薦将bootloader和應用程式編譯連結生成的程式設計檔案進行合并，一次性使用量産工具（如Cyclone程式設計器）下載下傳以提高生産效率。