前言

最近負責的ECU報了CAN升級失敗的問題，反饋到開發這邊就是問題描述和一堆的Error log，因為發生問題的車輛在外地，這就需要我們從Error Log中找到問題所在（起碼找到是上位機問題還是ECU端問題，如果是ECU的問題還要繼續分析ECU為啥故障），因為以前的Bootloader升級知識還停留在理論階段，到真正找問題的時候還是有很多模糊的地方的，終歸還是對一些基礎試著掌握的不牢固，這里把分析過程中需要的基礎知識都列出來，同時把升級的分析過程也記錄下來，希望以后分析Bootlodaer的升級問題時能更加得心應手。

正文

1.什么是Bootloader

MCU正常運行時總是從固定地方取指令，順序運行，程序更新時需要使用燒錄器等工具燒錄，于是有人將程序設計成，由一個程序跳轉到另一個程序，這個程序通常稱作Bootloader，另一個叫做APP。

Bootloader程序常常具有通信接口和擦寫內部存儲空間的功能，可將需要更新的APP擦除，寫入新的APP。有時會設計成相互跳轉，技術也是可以實現的。有些為了保證程序不丟失，單獨預留出備份區和出廠版本，出現某些錯誤時可以恢復到出廠版本或使用其他APP均可。

2.汽車ECU的Bootloader

汽車ECU也就是汽車控制器單元，專門用在汽車上。ECU經常會用在汽車零部件中，零部件密封性等要求都比較苛刻，并且裝車，如果想取下零部件可能需要將車拆解才可以做到，這種行為是不被允許的，成本極高，操作復雜，因此大多主機廠（OEM）要求ECU具有升級功能，并且通過多年的積淀制定了行業標準UDS。

3.Bootloader刷寫使用的協議

UDS（Unified Diagnostic Services，統一診斷服務）診斷協議是用于汽車行業診斷通信的需求規范，由ISO 14229系列標準定義。應用于OSI七層模型的應用層（第7層），它只規定了與診斷相關的服務需求，并未涉及通信機制，所以，它可以在不同的汽車總線（例如CAN, LIN, Flexray, Ethernet）上實現。

ISO 14229 一個用于汽車行業診斷通信的需求規范，它只規定了與診斷相關的服務需求，并沒有涉及通信機制，因此要實現一個完整的診斷通信還需要定義網絡層協議（比如ISO 15765），還有底層硬件實現方式（比如CAN控制器）。由于不涉及網絡通信機制，可以架設在各種網絡之上，因此ISO 14229也稱為UDS（Unified Diagnostic Services）。

ISO 15765 協議是一種CAN總線上的診斷協議。ISO 15765 3 協議是按照 ISO 14229 1，描述了在 ISO 11898 定義的控制器局域網中統一診斷服務(UDS)的實施。它給所有汽車連接至CAN網絡服務器及外部測試設備提供診斷服務及服務器存儲器編程的需求。基于CAN總線的升級方式是目前汽車ECU升級的最主要升級方式。

ISO 17987 其中定義LIN通信相關部分。診斷通信用于建立診斷儀與ECU之間的通信連接，并負責將ECU中的診斷結果輸送到診斷儀中。

UDS的作用非常廣泛，幾乎跟隨ECU軟件開發的全過程。

CAN Driver:最小化的CAN驅動。

TP：提供最小化的 CAN TP，實現ISO-15765-2傳輸協議。

Diag：診斷層，實現裁剪后適用Boot的診斷服務。

3.1基于CAN的傳輸層協議

分析升級過程的報文Log時，看到的都是最原始的報文數據（標準CAN：8 Byte，CANFD：8，12，16，20，24，32，48，64 Byte），所以我們不光要熟悉應用層的數據格式，也要熟悉傳輸層的數據格式。

如果使用標準CAN，則所有的報文數據都是8 Byte，如下圖所示：

如果診斷應用層數據長度小于等于7 Byte，則使用單幀（SingleFrame, SF）數據，Byte 0的Bit0-Bit3為應用層協議數據長度，Bit4-Bit7為單幀固定標識00。

例如：

Request: 02 10 03 CC CC CC CC CC --> 單幀數據，協議數據長度SF_DL為2，協議數據為10 03，后面的CC為填充數據

Response: 06 50 03 00 32 00 C8 AA --> 單幀數據，協議數據長度SF_DL為6，協議數據為0 03 00 32 00 C8，后面的CC為填充數據

如果診斷應用層數據長度大于7Byte，則需要使用首幀（FF）+連續幀（CF）傳輸數據，首幀（FF）的Byte 0的Bit4-7為首幀的固定標識01，Byte 0的Bit0-Bit3+Byte 1為應用層協議數據長度。

Response: 10 14 62 F1 89 00 00 00 --> 首幀數據，協議數據長度為0x014（20）個字節，首幀協議數據長度固定6個字節，內容為 62 F1 89 00 00 00。

連續幀（CF）的Byte0的Bit4-Bit7為連續幀的固定標識20，Byte 0的Bit0-Bit3為SN編號（連續幀序號，共4bit，0--0xF循環），協議數據長度為7個Byte。

Respons: 21 00 00 00 00 00 B8 AC --> 連續幀的第一幀數據（0x21），協議數據為7個Byte，內容為00 00 00 00 00 B8 AC。

流控幀（FC）Byte0的Bit4-7為固定標識（11b），bit0-bit3為FS，Byte 1為BS（Block size），Bite 2為STmin（Seperation time）。

表1：標準CAN的傳輸層幀格式

如果使用標準CANFD，則數據長度是可變的如下圖所示，這里不在贅述。

表2：CANFD的傳輸層幀格式

表3：CANFD下首幀或連續幀的最后一幀的幀長度

3.2Bootloader使用到的關鍵應用層協議

診斷工具使用0x34服務初始化從診斷工具到ECU的數據傳輸（下載）。接收到此服務的請求報文時，ECU應在發送肯定響應報文前，采取所有必要動作用于數據接收。

表4：0x34服務的請求幀數據格式

表5：0x34服務的積極響應幀數據格式

診斷工具使用0x36服務從診斷工具到ECU傳輸數據（下載）或者從ECU到診斷工具傳輸數據（上傳）。

表6：0x36服務的請求幀數據格式

表7：0x36服務的積極響應幀數據格式

診斷工具使用0x37服務終止診斷工具與ECU的數據傳輸。

表8：0x37服務的請求幀數據格式

表9：0x37服務的積極響應幀數據格式

4.Bootloader中診斷升級流程

UDS服務設計復雜，Bootloader升級一般分為以下三步：

1）預編程：主要進行一些環境配置

2）編程：刷寫過程

3）刷新完成：恢復配置

Bootloader可以保證在上述三個階段任一問題出現都能再次進入該過程重新刷新。

4.1預編程階段

在進入刷新之前，UDS的85服務和28服務，關閉DTC診斷同時停發非診斷報文。使整個CAN網絡處于靜默（Silent）狀態。這是對整車網絡進行操作的，一般都是以功能尋址（Functional addressing）的方式來發送。注意先用85服務關閉DTC，再使用28服務關報文。關閉DTC診斷是防止升級過程誤報DTC（例如通信丟失DTC等），關閉CAN通信是為了降低總線負載，加快刷寫速度。

4.2編程階段

UDS設計了安全訪問功能，安全訪問是為了保證ECU數據的安全，實現方式是由ECU發送一個隨機數種子到主機，主機通過對應ECU預先定義好的算法算出結果與ECU算出結果進行比對，結果一致則解鎖成功通過安全驗證。ECU解鎖可以存在多個等級，安全要求越高則需要的安全等級越高（使用0x27服務實現）。

寫時候先寫DID指紋，標記寫軟件人的身份（按照主機廠要求），擦寫下載等操作。

4.3編程結束

刷寫完成之后，ECU進行重啟，重新進入擴展會話，打開之前關閉的配置。

審核編輯 ：李倩