電子發燒友App
Bootloader 介紹
大多數Bootloader 包含兩種操作模式。
- 啟動加載模式
- 下載模式
對于大多數汽車軟件開發者來說，從客戶需求的角度，他們更多關心Bootloader的下載模式。下面我們將從CAN 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 對Bootloader 的基本要求
在OEM 的需求里，在刷寫過程一般分為三個步驟。
- 前處理
- 刷寫
- 后處理
分別是做什么的呢？
前處理
需求各不相同，但是目的基本都一致。
- 避免其他節點對升級過程的影響
- 避免自身節點對升級過程的影響
- 避免自身節點對其他節點的影響
刷寫
通過一系列的UDS 命令進行 點對點 交互。其目的和前面提到的一致。
- 發送數據的ECU 可靠
- 數據傳輸過程可靠
- 數據有效性(識別有沒有被篡改)
- 數據加密解密數據安全
- 等等
后處理
解除自身的特殊狀態。更新配置參數等等。
這里面 ECU 需要做好和APP 的相互校驗。需要達到
- APP 是否有效，Bootloader 需要能判斷出
- APP 運行時無效，需要能有效進入Bootloader模式。
- APP 無效， Bootloader 不應該跳入
- 等等
Bootloader的設計與實現
總結一句話
最基本的Bootloader通過傳輸協議把數據可靠的寫入指定的內存空間
通過上面的分析，總結一下我們需要實現哪些功能。
01 控制器最小系統
單純運行Bootloader的軟件，這里是不需要os的。只需要一個while(1) + 中斷系統順序執行即可。
本文以Aurix Tricore芯片示例代碼介紹。
啟動代碼
static void __StartUpSoftware(void);
static void __StartUpSoftware_Phase2(void);
static void __StartUpSoftware_Phase3ApplicationResetPath(void);
static void __StartUpSoftware_Phase3PowerOnResetPath(void);
static void __StartUpSoftware_Phase4(void);
static void __StartUpSoftware_Phase5(void);
static void __StartUpSoftware_Phase6(void);
static void __Core0_start(void);
main 函數
這里面實現很簡單，只需要判斷是否進入app. 如果不進入app. 就只需要監聽通訊接口的數據，進行相對應的操作即可。
int main(void)
{
if(*((uint32_t *)APP_EXE_FLAG_START_ADDR)==0x80001000){
CAN_BOOT_JumpToApplication(APP_START_ADDR);
}
__set_PRIMASK(0);//開啟總中斷
CAN_Configuration(1000000);
while (1)
{
if(CAN1_CanRxMsgFlag){
CAN_BOOT_ExecutiveCommand(&CAN1_RxMessage);
CAN1_CanRxMsgFlag = 0;
}
}
}
02 通訊驅動
這里面采用的是比較簡單的CAN 通訊。
一般來說因為上位機在傳輸數據的時候，速度是很快的。我們bootloader里面的CAN 接收需要采用中斷的模式進行收發。
對于CAN 的參數配置。
波特率
typedef struct {
unsigned char SJW;
unsigned char BS1;
unsigned char BS2;
unsigned short PreScale;
} tCAN_BaudRate;
可以根據芯片手冊的原理進行配置。
這里面對于Bootloader來說，比較重要的就是波特率和收發報文ID 以及中斷模式。
因為這些是需要和上位機進行配合的。
這里給出以下Mcal 代碼初始化CAN時候的形參。可以大概看出需要初始化的內容
/*******************************************************************************
** Traceability : [cover parentID={196A1432-EAB1-461a-BD6C-259784BF6397}] **
** **
** Syntax : void Can_17_McmCan_Init **
** ( **
** const Can_17_McmCan_ConfigType* const Config **
** ) **
** **
** Description : Driver Module Initialization function **
** * This function initializes: **
** * Static variables, including flags **
** * CAN HW Unit global hardware settings **
** * Controller specific settings for each CAN Controller **
** All CAN Controllers will be in state CANIF_CS_STOPPED after initialization**
** [/cover] **
** **
** Service ID : 0x00 **
** **
** Sync/Async : Synchronous **
** **
** Reentrancy : Non-Reentrant **
** **
** Parameters(in) : Config - Pointer to all cores CAN driver configuration **
** **
** Parameters (out) : none **
** **
** Return value : none **
** **
*******************************************************************************/
對于bootloader來說，這里只需要三個接口
初始 化，收，發
void CAN_Configuration_init(uint32_t BaudRate);
uint8_t CAN_WriteData(CanTxMsg *TxMessage);
uint16_t Read_CAN_Address(void);
03 內存驅動
首先看一下內存分配
PFLASH
DFLASH
一般來說 被刷的軟件格式是Hex 或S19. 針對這兩種格式就不說了。
code 和 data 可以根據主機廠需求分為兩個或多個Hex.
所以這里需要對Pflash 和 DFlash 都進行操作。
需要注意的是兩個不同的flash 操作的 扇區大小是不一樣的。Mcal提供的接口已經做了相對應的處理。
對于bootloader來說，需要的接口 擦除 和 寫入。
/*******************************************************************************
** Syntax : FlsLoader_ReturnType FlsLoader_Write( **
** const FlsLoader_AddressType TargetAddress, **
** const FlsLoader_LengthType Length, **
** const uint8* const SourceAddressPtr) **
** **
** Service ID : 0x31 **
** **
** Sync/Async : Synchronous **
** **
** Reentrancy : Non Reentrant **
** **
** Parameters(in) : Length: Number of bytes to be written. It should be **
** multiple of the following page sizes of the **
** selected Flash for write. **
** PFlash: 32 Bytes **
** DFlash: 8 Bytes **
** SourceAddressPtr: Pointer to source data buffer **
** TargetAddress: Target address in Flash memory. **
** It should be aligned to the following page sizes **
** of the selected Flash for write. **
** PFlash: 32 Bytes **
** DFlash: 8 Bytes **
** **
** Parameters (out) : None **
** **
** Return value : FLSLOADER_E_OK: Successful execution. **
** FLSLOADER_E_BUSY: Flash is busy with erase/write **
** operation. **
** FLSLOADER_E_NOT_OK: Returned when DET, Sequence error, **
** Program/Erase verify errors occur, SourceAddressPtr is**
** null pointer. **
** FLSLOADER_E_LOCKED: Programming a locked sector. **
** **
** Description : This function is used to program a page of internal **
** Flash. Sectors of PFlash and DFlash can be programmed. **
*******************************************************************************/
/*******************************************************************************
** Syntax : FlsLoader_ReturnType FlsLoader_Erase( **
** const FlsLoader_AddressType TargetAddress, **
** const FlsLoader_LengthType Length **
** ) **
** **
** Service ID : 0x32 **
** **
** Sync/Async : Synchronous **
** **
** Reentrancy : Non Reentrant **
** **
** Parameters(in) : Length: Number of Flash (PFlash or DFlash) sectors to **
** be erased. Note: Number of sectors should lie within **
** single Flash bank. Erase operation across the Flash **
** banks is not supported. **
** TargetAddress: Target address in Flash memory. It **
** should be aligned to the following sector sizes of the **
** selected Flash for erase. **
** PFlash: 16 Kbyte **
** DFlash: 4 Kbyte **
** **
** Parameters (out) : None **
** **
** Return value : FLSLOADER_E_OK: Successful completion. **
** FLSLOADER_E_BUSY: Flash is busy with erase/write **
** operation. **
** FLSLOADER_E_NOT_OK: Returned when DET, Sequence error, **
** Erase verify errors occur. **
** FLSLOADER_E_LOCKED: Sector is protected. **
** **
** Description : This function erases the logical sectors of the **
internal Flash. The completion of this operation is **
denoted by clearing of busy status flag or error. **
04 額外需求庫
這里比如需要對數據進行CRC 校驗
需要對數據包進行數據解密用到的加密算法
等等
05 交互邏輯 上層應用
根據具體的OEM 需求實現的功能。比如說。配置參數的交換，與APP軟件的有效位相互校驗，等等需求。這里無法給出對應代碼。
總結 一張圖
工商網監
評論