01

BootLoader概述

1.1 Boot Loader設計目的

車載控制器軟件需要滿足兩方面的要求：

1）、功能方面的需求：用戶需要的基本功能實現；

2）、更新及升級需求：對于售后的要求，車輛上市后針對軟件缺陷修復及后續功能擴展等要求。

刷寫App程序存在兩種方式：

1）、使用仿真器或燒錄器直接燒錄Application；

2）、將Application數據通過總線（CAN、LIN、CANFD或以太網）按照一定格式傳輸給ECU。

對于實車，直接連接燒錄器或仿真器這種方式極不方便且花費較大，再者安全性不高。因此，產品很少存在燒錄接口。從經濟使用的角度來講，普遍采用第二種方式。

1.2 Boot Loader基本功能

Boot Loader又稱為引導加載程序，引導加載程序是系統上電后運行的第一段軟件代碼，常被用來加載系統或者更新系統等。因此，大部分的Boot Loader存在兩種不同的操作模式：

1）啟動模式

啟動加載（BootLoading）模式也稱為自主模（Autonmous）式，即BootLoader從目標機上某個固態存儲設備上將操作系統加載至RAM中運行，整個過程中并沒有用戶的介入。

2）下載模式

在下載（DownLoading）模式下，目標機上的Boot Loader將通過串口連接或者網絡連接等通信手段下載文件，如下載內核映像和根文件系統映像等。通常文件會保存在RAM中，然后將其寫入目標地址完后系統的更新等。

02

BootLoader基本需求設計

2.1 Boot Loader功能概述

兩個SWC：

1）、啟動管理——控制器的啟動管理等

2）、應用程序——ECU軟件下載升級及標定數據再編程等

四個服務模塊：

1）、內存管理——軟件更新主要是將Flash中的Application及標定數據重編程，內存擦除與重寫驅動必不可少的模塊；

2）、CAN協議棧——軟件更新媒介

3）、看門狗模塊——軟件運行保護

4）、安全模塊——軟件數據保護，下載數據校驗等

2.2 ECU啟動時序

Bootloader是所有支持重編程的ECU必須具備的軟件功能，在ECU運行過程中，執行的是應用軟件和應用數據，僅當應用軟件或應用數據無效時，或者要求對其進行升級或特殊測試時，Bootloader軟件才被激活。啟動過程如下圖所示：

2.3 軟件執行安全機制設計

2.3.1 應用軟件運行安全性

應用軟件和應用數據可以同時編程或者相互獨立編程，不允許Boot Loader在軟件運行時被非法修改。因此，Bootloader軟件存儲于被保護的存儲器區域，即使發生潛在錯誤時，控制器始終保證可重新編程。

基于軟件運行安全性考慮，flash diver不會存在放在flash中，避免正常程序在發生錯誤時可能的非法修改。在需要執行應用程序或應用數據需要時，首先將flash diver下載至ram中，然后執行相應的更新。

基于以上考慮，將Boot Loader劃分為：

PBL（Primary Boot Loader）：用于啟動過程中的狀態管理及下載軟件等，下載 SBL、更新應用軟件及應用數據

SBL（Secondary Boot Loader）：本質為Flash Diver（可被用來修改寫在flash中生產信息校驗信息等），下載完成后重新啟動將會被清除

##SBL也可是運行在RAM中的另一個完整Boot Loader，以上將其認為flash driver

2.3.2 軟件更新安全機制設計

為確保下載的安全，ECU需設計安全機制，避免以下幾種情況：a. 來自非法源的下載動作；b. 當前編程條件不滿足；c. 下載錯誤的應用軟件或應用數據到ECU；d. 軟件之間不兼容；

解決措施：

1）、安全訪問——ECU通過SEED&KEY機制進行安全訪問服務限制，保證ECU免遭未授權的編程動作影響。

2）、預編程條件——ECU確保編程時處于安全狀態，條件不滿足（如高壓上電或車輛運行）時，編程服務請求將被拒絕。

3）、完整性校驗——ECU對即將下載到存儲器的程序或數據進行完整性檢查，當一個邏輯模塊下載后，使用CRC32算法驗證當前邏輯塊的所有數據字節是否被正確傳輸和寫入。通過“檢查編程完整性”例程控制激活ECU完整性校驗。當ECU接收到此服務請求時，Bootloader將計算下載數據字節的CRC32值，并將計算結果與診斷儀請求報文中發送的校驗值進行比較。

4）、一致性檢查——不兼容的軟件不能配合使用，如果配合使用可能會使功能異常或產生致命性錯誤。為此，ECU通過驗證軟件兼容性來檢查編程程序的一致性，包括應用軟件與Bootloader軟件、應用數據與應用軟件檢驗等。

5）、有效性檢查——ECU內部有一個標志位，用于標識應用軟件是否有效。如果編程完整性檢查和一致性檢查都正確時，ECU才會設置應用軟件的標志位為有效。只有標志位為有效時，應用軟件才可以運行。

03

BootLoader重編程流程設計

3.1 BootLoader重編程會話跳轉設計

在應用模式下，使用了兩種不同的診斷會話模式：默認會話模式和擴展會話模式。

在Bootloader模式下，使用了三種不同的診斷會話模式：默認會話模式，擴展會話模式和編程會話模式。

如果ECU在正確的條件下收到“$10 $02”指令，ECU將重編程請求標志狀態位設為有效，并執行ECU重啟。

上電/復位后，ECU首先執行Bootloader引導代碼，然后檢查外部編程請求標志位：

1）、如果外部編程請求標志位為有效，那么即使應用程序是有效的，Bootloader也會繼續進一步執行，在此情況下，ECU直接進入編程會話模式。

2）、如果外部重編程請求標志位為無效，則繼續檢查應用軟件的標志位狀態：（a）、 如果應用軟件是有效的，則啟動應用模式；（b）、如果應用軟件無效，ECU停留在Bootloader模式下的默認會話模式。

在Bootloader模式下，ECU重啟方式：

1）、無論當前處于何種會話模式，“$11 $01”都會引導ECU重啟；

2）、 在擴展會話模式或編程會話模式下，S3定時器超時會導致ECU重啟；

3）、在編程會話模式下，“$10 $01”會導致ECU重啟。

3.2 BootLoader重編程時序設計

編程時序分為三個編程步驟：

預編程步驟：編程前的CAN網絡準備；

主編程步驟：下載應用軟件或應用數據；

后編程步驟：重同步CAN網絡。

如果在預編程、主編程和后編程步驟過程中，任何物理尋址的請求及響應不滿足要求，則全部時序需再次執行。

3.2.1 預編程步驟

預編程步驟用來為要下載的ECU做重編程前的CAN網絡準備。此步驟也包含了提高下載速度的準備。此步驟的請求報文能采用的是物理尋址，或功能尋址。如下圖所示：

a）、診斷會話控制 $10 $03：為了禁止ECU間的正常通信和控制DTC設置，預編程需要啟動非默認會話模式。通過使用會話類型為擴展會話模式的診斷會話控制（$10）服務來完成。此請求使用一個單幀請求報文，通過功能尋址發送給所有的ECU。

b）、例程控制“檢查編程預條件” $31 $01 $XXXX：通過此例程來檢查ECU編程條件，從而確保系統安全，如果有任何不安全的因素，ECU將拒絕編程。

注意：如果ECU在未收到“檢查編程預條件”例程（$31 $01 $XXXX）的情況下，收到“$10 $02”請求，ECU將拒絕進入Bootloader模式，并且發送否定響應。

c）、控制DTC設置 $85 $02：診斷儀通過DTC設置類型設為“關閉”的控制DTC設置服務請求。此請求使用一個單幀請求報文，通過功能尋址發送給所有的ECU。

d）、通信控制 $28 $03 $03：診斷儀通過通信控制（$28）服務請求，禁止非診斷報文的發送和接收。請求中的控制類型參數置為“disable the transmission and the reception”，通信類型置為“application and network management messages”。此請求使用一個單幀請求報文，通過功能尋址發送給所有的ECU。

3.2.2 主編程步驟

在預編程步驟之后，是主編程步驟。主編程時序是單個ECU編程事件的應用，因此所有服務的請求都使用物理尋址。

a）、診斷會話控制 $10 $02：在收到一個尋址方式為物理尋址，子功能為編程會話的診斷會話控制（$10）服務后，ECU啟動Bootloader，并分配編程所需的所有資源。ECU需先發送肯定響應，再執行跳轉到編程模式動作。

b）、安全訪問 $27 $XX/XX：編程事件必須通過安全訪問。安全訪問（$27）服務在排放相關和安全系統中是強制的。其它系統不要求使用該服務。下載前，通過安全訪問過程是強制的，確保只有合法的診斷儀能對ECU進行下載操作。

c）、驅動下載 $34，$36，$37，$31：當ECU的非易失性存儲單元中沒有存儲內存驅動時，將執行內存驅動的下載。下載應該按照如下時序來進行：請求下載、傳輸數據、請求傳輸退出。下載完所有字節后，用“檢查編程完整性”例程（$31 $01 $XX $XX）來檢查所有的字節都正確傳輸。

d）、寫入數據 $2E $XXXX：在擦除內存例程之前，將“指紋”寫到ECU內存中是強制的。“指紋”標識了是哪個診斷儀對ECU內存做了修改。使用XXXX數據標識符而不是引導軟件指紋、應用軟件指紋、應用數據指紋這些數據標識符。每個邏輯塊（除了驅動）下載前，診斷儀將首先寫“指紋”，在下載完邏輯塊后，ECU將識別之前下載的程序是哪個邏輯塊（即邏輯塊序號），并根據邏輯塊的序號將它存儲。在追蹤指紋信息時，診斷儀將發報文“$22 $XXXX”，ECU將通過“$62 $XXXX”，返回每一個邏輯塊的指紋信息。

e）、例程控制——“擦除內存” $31 $01 $XXXX：為了允許應用軟件和數據下載，ECU的內存將被擦除。此步驟通過例程控制服務（$31）來執行擦除內存。如果擦除內存例程被調用執行，那么應用軟件的標志位將被置為無效。

f）、下載過程 $34 $36 $37：應用軟件或者數據的每一個連續的數據塊（也叫段，可能是一個完整的應用軟件或者數據，也可能是應用軟件或者數據的一部分）下載到ECU非易失性內存中，都是遵循下面的服務順序完成數傳輸：請求下載（$34）、傳輸數據（$36）、請求退出傳輸（$37）。

注：單個應用軟件或數據塊可能需要多個數據傳輸（$36）請求報文來完成傳輸（當數據塊長度超出網絡層緩存大小時，就會出現這種情況）。

g）、例程控制——“檢查編程完整性” $31 $01 $XXXX：此例程用來檢查邏輯塊的完整性。

h）、例程控制——“檢查編程一致性” $31 $01 $XXXX：一旦完成所有的應用軟件或數據塊/模塊的下載，診斷儀將開始一個例程來觸發ECU檢查重編程的一致性。

i） 、電控單元復位 $11 $01：診斷儀使用物理尋址，發送一個復位類型為硬復位的ECU復位（$11）服務請求報文到CAN網絡上。

備注：通過ECU復位服務請求將使ECU結束重編程過程，返回到正常的操作模式。內存驅動代碼必須從RAM緩存中完全清除，避免意外激活這些可能會進行非預期的內存擦除或程序操作的代碼。

3.2.3 后編程步驟

a）、診斷會話控制 $10 $01：診斷儀發送一個會話類型為默認會話的診斷會話控制（$10）服務請求報文到CAN網絡上。所有的ECU接收到診斷會話控制（$10），而進入到默認會話模式。此請求通過功能尋址發送，請求發送給所有包含在編程事件中或因此而進入非默認會話模式的ECU。跳轉到默認會話模式，表示通信控制（$28）服務和控制DTC設置（$85）服務也將復位到默認狀態。

b）、清除診斷信息 $14 FF FF FF：如果重編程ECU在編程步驟被重啟，當編程ECU運行在默認會話模式時，網絡上其它的ECU仍然在不能正常通信狀態，此時，一些可能被存儲在編程ECU中的診斷信息就應該通過物理尋址的清除診斷信息（$14）服務來清除。

版權聲明：本文為CSDN博主「摸魚的攻城獅」的原創文章，轉載請附上原文出處鏈接及本聲明。

編輯：jq