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