大多數Bootloader 包含兩種操作模式。
- 啟動(dòng)加載模式
- 下載模式
對于大多數汽車(chē)軟件開(kāi)發(fā)者來(lái)說(shuō)，從客戶(hù)需求的角度，他們更多關(guān)心Bootloader的下載模式。
下面我們將從CAN Bootloader的一般需求入手，來(lái)介紹一下CAN Bootloader 的整個(gè)實(shí)現過(guò)程。
通過(guò)CAN網(wǎng)絡(luò )升級一般需要考慮下面幾個(gè)方向。
01 針對單一節點(diǎn)
CAN網(wǎng)絡(luò )是串行結構，在對節點(diǎn)升級的時(shí)候，不能被別的節點(diǎn)影響，也不能影響到別的節點(diǎn)。這里就需要進(jìn)行點(diǎn)對點(diǎn)升級。在OEM 的規范中會(huì )對每一個(gè)ECU 都有自己的診斷ID。一般情況下針對CAN網(wǎng)絡(luò )的ECU有。
兩個(gè)接收ID
- 功能尋址ID
- 物理尋址ID
一個(gè)發(fā)送ID
- 診斷發(fā)送ID
這樣可以確保點(diǎn)對點(diǎn)的操作，和其他節點(diǎn)互相不干擾。
02 節點(diǎn)的智能設計
在CAN網(wǎng)絡(luò )中實(shí)現數據更新，最進(jìn)本的就是master ECU 把數據有效的傳輸給Slave ECU, 這樣Slave ECU 對自身的flash 進(jìn)行操作。在這個(gè)過(guò)程中需要對數據進(jìn)行一定要求。
-
保證數據傳遞的有效性-->傳輸過(guò)程沒(méi)有錯誤
-
保證數據本身的真實(shí)性--> 未被篡改
-
保證數據發(fā)送方的可靠性-->被授權的ECU
-
保證數據本身的正確性--> 是否與Bootloader 兼容
-
等等需求
這里對傳輸過(guò)程的保證，汽車(chē)OEM 一般通過(guò)UDS 讓Master ECU 和 Slave 進(jìn)行交互。通過(guò)握手協(xié)議，以及一些routine 來(lái)對上面需求進(jìn)行一一實(shí)現。
針對UDS 這里不一一介紹，可以翻閱14229 自行查詢(xún)。
注意這里缺少新版的 0x29 服務(wù)。
UDS診斷29認證服務(wù)-Authentication Service
03 進(jìn)入Bootloader 模式
一般來(lái)說(shuō)這里有一下幾種方式
-
APP 主動(dòng)跳轉至 Bootloader 模式
-
上電啟動(dòng)由于Bootloader 檢測APP 失效，主動(dòng)停留在Bootloader
-
APP 軟件異常，自動(dòng)復位到Bootloader 模式下。
這里針對OEM 的升級需求，一般是 第一種， APP 主動(dòng)跳轉至Bootloader 模式。因為Bootloader 不一定都是需要依賴(lài)UDS的，這里統一叫Bootloader 模式，OEM 的 UDS 的規范里面的名稱(chēng)叫做programming session。
一般來(lái)說(shuō)OEM 會(huì )在A(yíng)PP 里面先進(jìn)行session 跳轉，身份驗證。
最后通過(guò) 10 02 命令讓APP 跳轉到Bootloader 模式下。
在我們進(jìn)行bootloader設計的時(shí)候，可以通過(guò)任何特定方式，注意這里的特定方式不能是隨隨便便就可以觸發(fā) 的，防止誤觸進(jìn)入bootloader 模式。
因為跳轉的邏輯是 APP 檢測到一定的條件，然后 對某些寄存器，或者某些Bootloader 可讀的內存空間進(jìn)行寫(xiě)flag. 隨后進(jìn)行reset. 這樣在reset完成之后， bootloader 會(huì )檢測到，這次不需要跳轉至APP 了。
04 對bootloader的要求
從實(shí)際的研發(fā)需求出發(fā)，這里列出了一些常用的需求。實(shí)際OEM 的bootloader 可能會(huì )細化需求，但是最終都是為了下面的目的提出來(lái)的需求。
-
多次數據更新
-
刷寫(xiě)速度，傳輸速度
-
差分更新
-
身份驗證
-
數據格式的標準化
-
對數據的完整性，有效性等進(jìn)行校驗
-
對APP 的有效性進(jìn)行校驗
-
上位機方便友好
在OEM 的需求里，在刷寫(xiě)過(guò)程一般分為三個(gè)步驟。
-
前處理
-
刷寫(xiě)
-
后處理
分別是做什么的呢？
前處理
需求各不相同，但是目的基本都一致。
-
避免其他節點(diǎn)對升級過(guò)程的影響
-
避免自身節點(diǎn)對升級過(guò)程的影響
-
避免自身節點(diǎn)對其他節點(diǎn)的影響
刷寫(xiě)
通過(guò)一系列的UDS 命令進(jìn)行 點(diǎn)對點(diǎn) 交互。其目的和前面提到的一致。
-
發(fā)送數據的ECU 可靠
-
數據傳輸過(guò)程可靠
-
數據有效性(識別有沒(méi)有被篡改)
-
數據加密解密數據安全
-
等等
后處理
解除自身的特殊狀態(tài)。更新配置參數等等。
這里面 ECU 需要做好和APP 的相互校驗。需要達到
-
APP 是否有效，Bootloader 需要能判斷出
-
APP 運行時(shí)無(wú)效，需要能有效進(jìn)入Bootloader模式。
-
APP 無(wú)效， Bootloader 不應該跳入
-
等等
總結一句話(huà)
最基本的Bootloader通過(guò)傳輸協(xié)議把數據可靠的寫(xiě)入指定的內存空間
通過(guò)上面的分析，總結一下我們需要實(shí)現哪些功能。
01 控制器最小系統
單純運行Bootloader的軟件，這里是不需要os的。只需要一個(gè)while(1) + 中斷系統順序執行即可。
本文以Aurix Tricore芯片示例代碼介紹。
啟動(dòng)代碼
main 函數
這里面實(shí)現很簡(jiǎn)單，只需要判斷是否進(jìn)入app. 如果不進(jìn)入app. 就只需要監聽(tīng)通訊接口的數據，進(jìn)行相對應的操作即可。
02 通訊驅動(dòng)
這里面采用的是比較簡(jiǎn)單的CAN 通訊。
一般來(lái)說(shuō)因為上位機在傳輸數據的時(shí)候，速度是很快的。我們bootloader里面的CAN 接收需要采用中斷的模式進(jìn)行收發(fā)。
對于CAN 的參數配置。
波特率
可以根據芯片手冊的原理進(jìn)行配置。
這里面對于Bootloader來(lái)說(shuō)，比較重要的就是波特率和收發(fā)報文ID 以及中斷模式。
因為這些是需要和上位機進(jìn)行配合的。
這里給出以下Mcal 代碼初始化CAN時(shí)候的形參?？梢源蟾趴闯鲂枰跏蓟膬热?/span>
對于bootloader來(lái)說(shuō)，這里只需要三個(gè)接口
初始化，收，發(fā)
03 內存驅動(dòng)
首先看一下內存分配
PFLASH
DFLASH
一般來(lái)說(shuō) 被刷的軟件格式是Hex 或S19. 針對這兩種格式就不說(shuō)了。
code 和 data 可以根據主機廠(chǎng)需求分為兩個(gè)或多個(gè)Hex.
所以這里需要對Pflash 和 DFlash 都進(jìn)行操作。
需要注意的是兩個(gè)不同的flash 操作的 扇區大小是不一樣的。Mcal提供的接口已經(jīng)做了相對應的處理。
對于bootloader來(lái)說(shuō)，需要的接口 擦除 和 寫(xiě)入。
04 額外需求庫
這里比如需要對數據進(jìn)行CRC 校驗
需要對數據包進(jìn)行數據解密用到的加密算法
等等
05 交互邏輯 上層應用
根據具體的OEM 需求實(shí)現的功能。比如說(shuō)。配置參數的交換，與APP軟件的有效位相互校驗，等等需求。這里無(wú)法給出對應代碼。
總結 一張圖
轉自汽車(chē)電子與軟件
