bootloader程序架構
略有簡化的bootloader圖
這張圖和恆潤教程中的BootLoader流程大體是一致的。
疑問點
Q:圖中的燒寫順序是34-36-34-36-34-36-37，但另一些材料中的順序是34-36-36-36-37。
A:這個問題這樣理解，34-36-36-36-37的前提是你要下載的數據是連續的數據，每個36所使用的地址信息，都是34中包含的地址信息再加上一定的偏移量。如果需要下載不連續的數據，就需要重新進行34服務或31（擦除）-34服務。
1 為什么要搞Bootloader？為什么要基於UDS搞Bootloader
假如你的控制器有外殼，卻沒有設計bootloader的話，每次更新ECU的程序，你都需要把外殼拆開，用燒寫器來更新程序。有了bootloader，你就可以通過CAN線來更新程序了。更方便些的話，甚至可以通過OTA進行遠程升級。
那為什么使用UDS呢？主要是為了規范bootloader的全過程。比如燒寫小明牌ECU時，我們肯定希望其他牌子的ECU處於一個靜默的狀態，都歇一歇，這就需要一個大家共同執行的標准來進行規范，什么時候停發數據，什么時候不能再儲存DTC了等等。
又比如在調試時，大家肯定希望你的控制器經由CAN燒寫的過程是大家都能看得懂的，是滿足於某種規范的。由此，UDS在設計時考慮了bootloader的需求，專門為bootloader設計了幾個服務，供大家使用。主機廠在發需求時自然就要求大家要在UDS規范的基礎上完成bootloader功能了。
2 Bootloader應支持的UDS服務
顯然bootloader不需要支持19/14等故障類服務。
在boot程序中，10/27/11/3E這樣的基礎診斷服務需要支持，22/2E讀寫DID的服務需要支持，31/34/36/37這4個bootloader主打服務需要支持，共10個。
在app段程序中，85和28服務需要支持，保證暫停CAN正常通信，暫停記錄DTC，讓被升級設備專心升級。
10種boot段服務+2種app段服務
3 Bootloader——三段式
（1）預編程階段
1. 3E TP報文。
2. 10服務切換到03擴展模式。
3. 85服務和28服務，關DTC和非診斷報文。使整個CAN網絡處於安靜的狀態。這是對整車網絡進行操作的，一般都是以功能尋址的方式來發送。注意先用85服務關閉DTC，再使用28服務關報文。
（2）主編程階段
1. 10服務切換到編程模式，這里要注意，正確的方式是App段程序回復0x78 NRC，接下來跳轉到boot段程序，最后由Boot段程序來回復10 02的肯定響應。錯誤的方式是由App段回復10 02的肯定響應，再進行跳轉。
2. 讀取一個DID，tester要判斷一下返回值。返回值里面可能包含密鑰的一部分信息。
3. 27服務，解鎖，通過安全驗證。
注意10 02服務不應直接進行肯定響應，存在風險
4. 寫DID指紋，標記寫軟件人的身份，ECU回復寫指紋成功。（根據OEM要求來執行）
5. 31服務-擦除Flash。ECU肯定響應，擦除成功。
6. 34服務，請求數據下載，ECU回復確認最大塊大小。
7. 36服務，開始傳輸數據。每個塊傳輸完成后，ECU肯定響應。判斷是否還有更多塊需要下載。最多可以支持255個塊。
8. 37服務，請求退出傳輸。ECU肯定響應。
9. 31服務-校驗APP段程序，檢查編程一致性/完整性。ECU肯定響應。校驗成功。
10. 若有更多塊需要下載，重新執行31（擦除Flash區域）-34-36-37-31（校驗）服務。若無，往下執行。
11. 11服務，ECU復位。之后應直接跳轉到新下載的APP段程序中。
31（擦Flash）-34-36
36-37-31（校驗）
（3）后編程狀態
1. 10服務切換到03擴展會話。
2. 執行28服務和85服務，使能非診斷報文和DTC。這是對整車網絡進行操作的，一般都是以功能尋址的方式來發送。注意先執行28，后執行85，避免DTC誤報。
3. 27服務，安全校驗，准備寫入數據。
4. 2E服務，將編程信息寫入到ECU中。
5. 10服務，退回01默認會話。結束。
4 BootLoader的啟動順序與轉換流程
以下流程僅作為參考，有很多不規范之處。歡迎大家留言探討。
1. ECU上電或復位后，先進入Boot段。從Flash/EEPROM中讀取 App有效標志，運行boot標志 。
2.判斷 運行boot標志 ，若為1，則進入Boot段的編程會話（安全等級為上鎖），之后寫Flash/EEPROM（不安全操作）， 運行boot標志 清零。若S3定時器超時則退回Boot段默認會話。
3. 經過安全訪問進入Level2解鎖狀態，開始執行App內存擦除，擦除后 App有效標志 清零（不安全操作）。
4. 開始燒寫。燒寫成功后 運行boot標志 寫0，App有效標志 寫1。
2*. 判斷 運行boot標志 ，若為0，則進入Boot段的默認會話。
3*. 50ms后判斷 App有效標志 ，若為1，則 跳轉到 App段默認會話。實現時使用匯編指令執行APP段程序；若為0，退回Boot段默認會話，且不再判斷 App有效標志，不會再嘗試進入App段。
4*. App段程序若收到了編程會話請求， 運行boot標志寫1 ，隨即執行ECU復位，這樣會重新進入boot段程序。
注：從BOOT跳入APP前需要判斷APP的數據完整性，例如進行CRC校驗。
5 問題點
Q:假如燒進去了不良App段程序，無法返回boot段程序怎么辦？
A:參照電腦的開機方式，在ECU開機之后，預留很短的一段時間維持在boot狀態，在這段時間內，若收到指定報文（比如，電腦是按住F8），那么就不跳轉到App段了。
Q:運行boot標志和App有效標志為了安全起見，應該保存到哪里？
A:運行boot標志可以放置在RAM中，由Boot和App共用。
Q:上文圖中的CAN數據實例，為什么出現了兩次CRC的校驗？CRC校驗是對哪些數據的校驗？
A:OEM不希望ECU中保存有可以擦寫Flash的代碼，所以BootLoader需要在燒錄App之前，先把擦寫Flash的代碼通過UDS燒寫到RAM中，燒完了之后進行一下31服務下的CRC校驗。之后燒錄ECU的App程序，App可能會因為地址不連續而分為很多段下載。下載完畢后需要進行總的CRC校驗。不管哪次校驗，CRC所校驗的數據是代碼的數據段，即36服務中傳輸的有效數據。