<big id="xpxpf"><address id="xpxpf"></address></big>

<meter id="xpxpf"></meter>

<sub id="xpxpf"><address id="xpxpf"></address></sub>

    <big id="xpxpf"></big>

    <rp id="xpxpf"><sub id="xpxpf"></sub></rp>

      <p id="xpxpf"><span id="xpxpf"></span></p>

        <dfn id="xpxpf"></dfn>
        400-821-6015
        行業資訊
        您當前的位置:首頁 ? 行業資訊 ? 行業資訊
        內部資訊行業資訊

        一文了解CAN bootloader的實現過程

        發布日期:2023-07-11
         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芯片示例代碼介紹。


             啟動代碼

             

            

             main 函數

             這里面實現很簡單,只需要判斷是否進入app. 如果不進入app. 就只需要監聽通訊接口的數據,進行相對應的操作即可。

             


        02 通訊驅動

        這里面采用的是比較簡單的CAN 通訊。

        一般來說因為上位機在傳輸數據的時候,速度是很快的。我們bootloader里面的CAN 接收需要采用中斷的模式進行收發。


        對于CAN 的參數配置。

        波特率

             

        可以根據芯片手冊的原理進行配置。

               圖片

        這里面對于Bootloader來說,比較重要的就是波特率和收發報文ID 以及中斷模式。

        因為這些是需要和上位機進行配合的。


        這里給出以下Mcal 代碼初始化CAN時候的形參??梢源蟾趴闯鲂枰跏蓟膬热?/span>

             

        對于bootloader來說,這里只需要三個接口


        初始化,收,發

             


        03 內存驅動

        首先看一下內存分配

        PFLASH

             圖片

          DFLASH


             圖片


        一般來說 被刷的軟件格式是Hex 或S19. 針對這兩種格式就不說了。


        code 和 data 可以根據主機廠需求分為兩個或多個Hex.

        所以這里需要對Pflash 和 DFlash 都進行操作。

        需要注意的是兩個不同的flash 操作的 扇區大小是不一樣的。Mcal提供的接口已經做了相對應的處理。

        對于bootloader來說,需要的接口 擦除 和 寫入。

             

         

              


        04 額外需求庫

        這里比如需要對數據進行CRC 校驗

        需要對數據包進行數據解密用到的加密算法

        等等


        05 交互邏輯 上層應用

        根據具體的OEM 需求實現的功能。比如說。配置參數的交換,與APP軟件的有效位相互校驗,等等需求。這里無法給出對應代碼。

        總結 一張圖

                圖片


        轉自汽車電子與軟件

        上海創程車聯網絡科技有限公司版權所有 滬ICP備11045498號-1   技術支持:網站建設
        欧美黄视频
        <big id="xpxpf"><address id="xpxpf"></address></big>

        <meter id="xpxpf"></meter>

        <sub id="xpxpf"><address id="xpxpf"></address></sub>

          <big id="xpxpf"></big>

          <rp id="xpxpf"><sub id="xpxpf"></sub></rp>

            <p id="xpxpf"><span id="xpxpf"></span></p>

              <dfn id="xpxpf"></dfn>