汽車ECU的Bootloader升級過程分析

前言

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

正文

1.什么是Bootloader

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

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

2.汽車ECU的Bootloader

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

3.Bootloader刷寫使用的協(xié)議

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

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

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

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

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

CAN Driver:最小化的CAN驅(qū)動。

TP：提供最小化的 CAN TP，實現(xiàn)ISO-15765-2傳輸協(xié)議。

Diag：診斷層，實現(xiàn)裁剪后適用Boot的診斷服務(wù)。

3.1基于CAN的傳輸層協(xié)議

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

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

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

例如：

Request: 02 10 03 CC CC CC CC CC --> 單幀數(shù)據(jù)，協(xié)議數(shù)據(jù)長度SF_DL為2，協(xié)議數(shù)據(jù)為10 03，后面的CC為填充數(shù)據(jù)

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

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

Response: 10 14 62 F1 89 00 00 00 --> 首幀數(shù)據(jù)，協(xié)議數(shù)據(jù)長度為0x014（20）個字節(jié)，首幀協(xié)議數(shù)據(jù)長度固定6個字節(jié)，內(nèi)容為 62 F1 89 00 00 00。

連續(xù)幀（CF）的Byte0的Bit4-Bit7為連續(xù)幀的固定標識20，Byte 0的Bit0-Bit3為SN編號（連續(xù)幀序號，共4bit，0--0xF循環(huán)），協(xié)議數(shù)據(jù)長度為7個Byte。

Respons: 21 00 00 00 00 00 B8 AC --> 連續(xù)幀的第一幀數(shù)據(jù)（0x21），協(xié)議數(shù)據(jù)為7個Byte，內(nèi)容為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，則數(shù)據(jù)長度是可變的如下圖所示，這里不在贅述。

表2：CANFD的傳輸層幀格式

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

3.2Bootloader使用到的關(guān)鍵應(yīng)用層協(xié)議

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

表4：0x34服務(wù)的請求幀數(shù)據(jù)格式

表5：0x34服務(wù)的積極響應(yīng)幀數(shù)據(jù)格式

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

表6：0x36服務(wù)的請求幀數(shù)據(jù)格式

表7：0x36服務(wù)的積極響應(yīng)幀數(shù)據(jù)格式

診斷工具使用0x37服務(wù)終止診斷工具與ECU的數(shù)據(jù)傳輸。

表8：0x37服務(wù)的請求幀數(shù)據(jù)格式

表9：0x37服務(wù)的積極響應(yīng)幀數(shù)據(jù)格式

4.Bootloader中診斷升級流程

UDS服務(wù)設(shè)計復(fù)雜，Bootloader升級一般分為以下三步：

1）預(yù)編程：主要進行一些環(huán)境配置

2）編程：刷寫過程

3）刷新完成：恢復(fù)配置

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

4.1預(yù)編程階段

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

4.2編程階段

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

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

4.3編程結(jié)束

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

審核編輯 ：李倩