通過下面兩張圖了解一下bootloader的軟件堆棧架構(gòu)及刷寫的流程。

• 下圖為bootloader程序架構(gòu)圖：

1 為什么要搞Bootloader？為什么要基于UDS搞Bootloader

假如你的控制器有外殼，卻沒有設(shè)計(jì)bootloader的話，每次更新ECU的程序，你都需要把外殼拆開，用燒寫器來更新程序。有了bootloader，你就可以通過CAN線來更新程序了。更方便些的話，甚至可以通過OTA進(jìn)行遠(yuǎn)程升級(jí)。

那為什么使用UDS呢？主要是為了規(guī)范bootloader的全過程。比如燒寫小明牌ECU時(shí)，我們肯定希望其他牌子的ECU處于一個(gè)靜默的狀態(tài)，都歇一歇，這就需要一個(gè)大家共同執(zhí)行的標(biāo)準(zhǔn)來進(jìn)行規(guī)范，什么時(shí)候停發(fā)數(shù)據(jù)，什么時(shí)候不能再儲(chǔ)存DTC了等等。

又比如在調(diào)試時(shí)，大家肯定希望你的控制器經(jīng)由CAN燒寫的過程是大家都能看得懂的，是滿足于某種規(guī)范的。由此，UDS在設(shè)計(jì)時(shí)考慮了bootloader的需求，專門為bootloader設(shè)計(jì)了幾個(gè)服務(wù)，供大家使用。主機(jī)廠在發(fā)需求時(shí)自然就要求大家要在UDS規(guī)范的基礎(chǔ)上完成bootloader功能了。

2 Bootloader應(yīng)支持的UDS服務(wù)

顯然bootloader不需要支持19/14等故障類服務(wù)。

在boot程序中，10/27/11/3E這樣的基礎(chǔ)診斷服務(wù)需要支持，22/2E讀寫DID的服務(wù)需要支持，31/34/36/37這4個(gè)bootloader主打服務(wù)需要支持，共10個(gè)。

在app段程序中，85和28服務(wù)需要支持，保證暫停CAN正常通信，暫停記錄DTC，讓被升級(jí)設(shè)備專心升級(jí)。

3 Bootloader——三段式

（1）預(yù)編程階段

1. 3E TP報(bào)文。

2. 10服務(wù)切換到03擴(kuò)展模式。

3. 85服務(wù)和28服務(wù)，關(guān)DTC和非診斷報(bào)文。使整個(gè)CAN網(wǎng)絡(luò)處于安靜的狀態(tài)。這是對(duì)整車網(wǎng)絡(luò)進(jìn)行操作的，一般都是以功能尋址的方式來發(fā)送。注意先用85服務(wù)關(guān)閉DTC，再使用28服務(wù)關(guān)報(bào)文。

（2）主編程階段

1. 10服務(wù)切換到編程模式，這里要注意，正確的方式是App段程序回復(fù)0x78 NRC，接下來跳轉(zhuǎn)到boot段程序，最后由Boot段程序來回復(fù)10 02的肯定響應(yīng)。錯(cuò)誤的方式是由App段回復(fù)10 02的肯定響應(yīng)，再進(jìn)行跳轉(zhuǎn)。

2. 讀取一個(gè)DID，tester要判斷一下返回值。返回值里面可能包含密鑰的一部分信息。

3. 27服務(wù)，解鎖，通過安全驗(yàn)證。

注意10 02服務(wù)不應(yīng)直接進(jìn)行肯定響應(yīng)，存在風(fēng)險(xiǎn)

4. 寫DID指紋，標(biāo)記寫軟件人的身份，ECU回復(fù)寫指紋成功。（根據(jù)OEM要求來執(zhí)行）

5. 31服務(wù)-擦除Flash。ECU肯定響應(yīng)，擦除成功。

6. 34服務(wù)，請(qǐng)求數(shù)據(jù)下載，ECU回復(fù)確認(rèn)最大塊大小。

7. 36服務(wù)，開始傳輸數(shù)據(jù)。每個(gè)塊傳輸完成后，ECU肯定響應(yīng)。判斷是否還有更多塊需要下載。最多可以支持255個(gè)塊。

8. 37服務(wù)，請(qǐng)求退出傳輸。ECU肯定響應(yīng)。

9. 31服務(wù)-校驗(yàn)APP段程序，檢查編程一致性/完整性。ECU肯定響應(yīng)。校驗(yàn)成功。

10. 若有更多塊需要下載，重新執(zhí)行31（擦除Flash區(qū)域）-34-36-37-31（校驗(yàn)）服務(wù)。若無，往下執(zhí)行。

11. 11服務(wù)，ECU復(fù)位。之后應(yīng)直接跳轉(zhuǎn)到新下載的APP段程序中。

（3）后編程狀態(tài)

1. 10服務(wù)切換到03擴(kuò)展會(huì)話。

2. 執(zhí)行28服務(wù)和85服務(wù)，使能非診斷報(bào)文和DTC。這是對(duì)整車網(wǎng)絡(luò)進(jìn)行操作的，一般都是以功能尋址的方式來發(fā)送。注意先執(zhí)行28，后執(zhí)行85，避免DTC誤報(bào)。

3. 27服務(wù)，安全校驗(yàn)，準(zhǔn)備寫入數(shù)據(jù)。

4. 2E服務(wù)，將編程信息寫入到ECU中。

5. 10服務(wù)，退回01默認(rèn)會(huì)話。結(jié)束。

4 BootLoader的啟動(dòng)順序與轉(zhuǎn)換流程

以下流程僅作為參考，有很多不規(guī)范之處。歡迎大家留言探討。

1. ECU上電或復(fù)位后，先進(jìn)入Boot段。從Flash/EEPROM中讀取 App有效標(biāo)志，運(yùn)行boot標(biāo)志 。

2. 判斷 運(yùn)行boot標(biāo)志 ，若為1，則進(jìn)入Boot段的編程會(huì)話（安全等級(jí)為上鎖），之后寫Flash/EEPROM（不安全操作）， 運(yùn)行boot標(biāo)志 清零。若S3定時(shí)器超時(shí)則退回Boot段默認(rèn)會(huì)話。

3. 經(jīng)過安全訪問進(jìn)入Level2解鎖狀態(tài)，開始執(zhí)行App內(nèi)存擦除，擦除后 App有效標(biāo)志 清零（不安全操作）。

4. 開始燒寫。燒寫成功后 運(yùn)行boot標(biāo)志 寫0，App有效標(biāo)志 寫1。

2*. 判斷 運(yùn)行boot標(biāo)志 ，若為0，則進(jìn)入Boot段的默認(rèn)會(huì)話。

3*. 50ms后判斷 App有效標(biāo)志 ，若為1，則 跳轉(zhuǎn)到 App段默認(rèn)會(huì)話。實(shí)現(xiàn)時(shí)使用匯編指令執(zhí)行APP段程序；若為0，退回Boot段默認(rèn)會(huì)話，且不再判斷 App有效標(biāo)志，不會(huì)再嘗試進(jìn)入App段。

4*. App段程序若收到了編程會(huì)話請(qǐng)求， 運(yùn)行boot標(biāo)志寫1 ，隨即執(zhí)行ECU復(fù)位，這樣會(huì)重新進(jìn)入boot段程序。

注：從BOOT跳入APP前需要判斷APP的數(shù)據(jù)完整性，例如進(jìn)行CRC校驗(yàn)。

5 問題點(diǎn)

Q:假如燒進(jìn)去了不良App段程序，無法返回boot段程序怎么辦？

A:參照電腦的開機(jī)方式，在ECU開機(jī)之后，預(yù)留很短的一段時(shí)間維持在boot狀態(tài)，在這段時(shí)間內(nèi)，若收到指定報(bào)文（比如，電腦是按住F8），那么就不跳轉(zhuǎn)到App段了。

Q:運(yùn)行boot標(biāo)志和App有效標(biāo)志為了安全起見，應(yīng)該保存到哪里？

A:運(yùn)行boot標(biāo)志可以放置在RAM中，由Boot和App共用。

Q:上文圖中的CAN數(shù)據(jù)實(shí)例，為什么出現(xiàn)了兩次CRC的校驗(yàn)？CRC校驗(yàn)是對(duì)哪些數(shù)據(jù)的校驗(yàn)？

A:OEM不希望ECU中保存有可以擦寫Flash的代碼，所以BootLoader需要在燒錄App之前，先把擦寫Flash的代碼通過UDS燒寫到RAM中，燒完了之后進(jìn)行一下31服務(wù)下的CRC校驗(yàn)。之后燒錄ECU的App程序，App可能會(huì)因?yàn)榈刂凡贿B續(xù)而分為很多段下載。下載完畢后需要進(jìn)行總的CRC校驗(yàn)。不管哪次校驗(yàn)，CRC所校驗(yàn)的數(shù)據(jù)是代碼的數(shù)據(jù)段，即36服務(wù)中傳輸?shù)挠行?shù)據(jù)。

點(diǎn)擊文章開頭上方藍(lán)字可關(guān)注微信公眾號(hào)『糖果Autosar』，分享文章至朋友圈或者點(diǎn)在看，通過微信『cloud2sunshine』備注“加群”加入汽車電子與AUTOSAR技術(shù)交流群，備注“汽車電子資料”領(lǐng)取技術(shù)資料。