汽車ECU的Bootloader升級(jí)過(guò)程分析

前言

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

正文

1.什么是Bootloader

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

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

2.汽車ECU的Bootloader

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

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

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

ISO 14229 一個(gè)用于汽車行業(yè)診斷通信的需求規(guī)范，它只規(guī)定了與診斷相關(guān)的服務(wù)需求，并沒(méi)有涉及通信機(jī)制，因此要實(shí)現(xiàn)一個(gè)完整的診斷通信還需要定義網(wǎng)絡(luò)層協(xié)議（比如ISO 15765），還有底層硬件實(shí)現(xiàn)方式（比如CAN控制器）。由于不涉及網(wǎng)絡(luò)通信機(jī)制，可以架設(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)的實(shí)施。它給所有汽車連接至CAN網(wǎng)絡(luò)服務(wù)器及外部測(cè)試設(shè)備提供診斷服務(wù)及服務(wù)器存儲(chǔ)器編程的需求?；贑AN總線的升級(jí)方式是目前汽車ECU升級(jí)的最主要升級(jí)方式。

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

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

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

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

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

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

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

如果使用標(biāo)準(zhǔn)CAN，則所有的報(bào)文數(shù)據(jù)都是8 Byte，如下圖所示：

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

例如：

Request: 02 10 03 CC CC CC CC CC --> 單幀數(shù)據(jù)，協(xié)議數(shù)據(jù)長(zhǎng)度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ù)長(zhǎng)度SF_DL為6，協(xié)議數(shù)據(jù)為0 03 00 32 00 C8，后面的CC為填充數(shù)據(jù)

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

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

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

Respons: 21 00 00 00 00 00 B8 AC --> 連續(xù)幀的第一幀數(shù)據(jù)（0x21），協(xié)議數(shù)據(jù)為7個(gè)Byte，內(nèi)容為00 00 00 00 00 B8 AC。

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

表1：標(biāo)準(zhǔn)CAN的傳輸層幀格式

如果使用標(biāo)準(zhǔn)CANFD，則數(shù)據(jù)長(zhǎng)度是可變的如下圖所示，這里不在贅述。

表2：CANFD的傳輸層幀格式

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

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

診斷工具使用0x34服務(wù)初始化從診斷工具到ECU的數(shù)據(jù)傳輸（下載）。接收到此服務(wù)的請(qǐng)求報(bào)文時(shí)，ECU應(yīng)在發(fā)送肯定響應(yīng)報(bào)文前，采取所有必要?jiǎng)幼饔糜跀?shù)據(jù)接收。

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

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

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

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

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

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

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

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

4.Bootloader中診斷升級(jí)流程

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

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

2）編程：刷寫(xiě)過(guò)程

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

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

4.1預(yù)編程階段

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

4.2編程階段

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

寫(xiě)時(shí)候先寫(xiě)DID指紋，標(biāo)記寫(xiě)軟件人的身份（按照主機(jī)廠要求），擦寫(xiě)下載等操作。

4.3編程結(jié)束

刷寫(xiě)完成之后，ECU進(jìn)行重啟，重新進(jìn)入擴(kuò)展會(huì)話，打開(kāi)之前關(guān)閉的配置。

審核編輯 ：李倩