Bootloader是所有支援重程式設計的ECU必須具備的軟體功能，在ECU運作過程中，執行的是應用軟體和應用資料，僅當應用軟體或應用資料無效時，或者要求對其進行更新或特殊測試的時候，Bootloader軟體才被激活。
應用軟體和應用資料可以同時程式設計或者互相獨立程式設計，不允許重新程式設計時更新Botloader軟體。Bootloader軟體存儲于被保護的存儲器區域，即使發生潛在錯誤時，控制器始終保證可重新程式設計。
- 2.1.1 安全機制
為確定下載下傳的安全，ECU需設計安全機制，避免以下幾種情況：
a. 來自非法源的下載下傳動作；
b. 目前重新整理條件不滿足；
c. 下載下傳錯誤的應用軟體或應用資料到ECU；
d. 軟體之間不相容；
1.2.1.1.1安全通路
ECU通過SEED&KEY機制進行安全通路服務限制，保證ECU免遭未授權的程式設計動作影響。
1.2.1.1.2 重新整理預條件
ECU確定重新整理時處于安全狀态，條件不滿足（如高壓上電或車輛運作）時，重新整理服務請求将被拒絕。
1.2.1.1.3 完整性校驗
ECU對即将下載下傳到存儲器的程式或資料進行完整性檢查，當一個邏輯子產品下載下傳後，使用CRC32算法驗證目前邏輯塊的所有資料位元組是否被正确傳輸和寫入。通過“檢查程式設計完整性”例程控制激活ECU完整性校驗。當ECU接收到此服務請求時，Bootloader将計算下載下傳資料位元組的CRC32值，并将計算結果與診斷儀請求封包中發送的校驗值進行比較。
1.2.1.1.4 一緻性檢查
不相容的軟體不能配合使用，如果配合使用可能會使功能異常或産生緻命性錯誤。為此，ECU通過驗證軟體相容性來檢查重新整理程式的一緻性，包括應用軟體與Bootloader軟體、應用資料與應用軟體檢驗等。
1.2.1.1.5 有效性檢查
ECU内部有一個标志位，用于辨別應用軟體是否有效。如果重新整理完整性檢查和一緻性檢查都正确時，ECU才會設定應用軟體的标志位為有效。隻有标志位為有效時，應用軟體才可以運作。
- 2.1.2 重新整理檔案格式
重新整理檔案格式為Intel格式(*.hex)。
- 2.1.3 ECU啟動時序
在每次上電/複位後，ECU首先執行Bootloader代碼。Bootloader首先執行一些基本的初始化，然後檢查重新整理請求标志位是否為有效，如果重新整理請求标志位有效，即使應用程式是有效的，Bootloader也會繼續運作。如果目前沒有重新整理請求，即重新整理請求标志位為無效，則檢查應用軟體的狀态，如果應用軟體是有效的，則應用軟體代碼将被執行，如果應用軟體是無效的，則繼續執行Bootloader代碼。
圖3-2 ECU啟動時序
- 2.1.4 重新整理流程
- 2.1.4.1 Bootloader啟動時序
圖3-3描述了Bootloader啟動時序。在應用模式下，使用了兩種不同的診斷會話模式：預設會話模式和擴充會話模式。
在Bootloader模式下，使用了三種不同的診斷會話模式：預設會話模式，擴充會話模式和重新整理會話模式。
如果ECU在正确的條件下收到“10 02”指令，ECU将外部重新整理請求标志位設定為有效，并執行ECU重新開機。
圖3-3 Bootloader啟動時序
上電/複位後，ECU首先執行Bootloader引導代碼，然後檢查外部重新整理請求标志位：
- 如果外部重新整理請求标志位為有效，那麼即使應用程式是有效的，Bootloader也會繼續進一步執行，在此情況下，ECU直接進入程式設計會話模式。
- 如果外部重程式設計請求标志位為無效，則繼續檢查應用軟體的标志位狀态：
• 如果應用軟體是有效的，則啟動應用模式；
• 如果應用軟體無效，ECU停留在Bootloader模式下的預設會話模式。
在Bootloader模式下，有以下幾種方式，會導緻ECU重新開機：
Ø 無論目前處于何種會話模式，“11h 01h”都會引導ECU重新開機；
Ø 在擴充會話模式或程式設計會話模式下，S3定時器逾時會導緻ECU重新開機；
Ø 在程式設計會話模式下，“10h 01h”會導緻ECU重新開機。
- 2.1.4.2 重新整理時序
重新整理時序分為三個程式設計步驟：
- 預重新整理步驟：重新整理前的CAN網絡準備；
- 主重新整理步驟：下載下傳應用軟體或應用資料；
- 後重新整理步驟：重同步CAN網絡。
如果在預重新整理、主重新整理和後重新整理步驟過程中，任何實體尋址的請求及響應不滿足要求，則全部時序需被再次執行。
- 預重新整理步驟
預重新整理步驟用來為要下載下傳的ECU做重重新整理前的CAN網絡準備。此步驟也包含了提高下載下傳速度的準備。此步驟的請求封包能采用的是實體尋址，或功能尋址。預重新整理步驟，如圖3-4所示。
圖3-4 預重新整理步驟
- a) 診斷會話控制10h 03h：為了禁止ECU間的正常通信和控制DTC設定，預重新整理需要啟動非預設會話模式。通過使用會話類型為擴充會話模式的診斷會話控制（10h）服務來完成。此請求使用一個單幀請求封包，通過功能尋址發送給所有的ECU。
- b) 例程控制“檢查重新整理預條件”31h01h FFh 02h：通過此例程來檢查ECU重新整理條件，進而確定系統安全，如果有任何不安全的因素，ECU将拒絕重新整理。
注意：如果ECU在未收到“檢查重新整理預條件”例程（31h 01h FFh 02h）的情況下，收到“10h 02h”請求，ECU将拒絕進入Bootloader模式，并且發送否定響應。
- c) 控制DTC設定85h 02h：診斷儀通過DTC設定類型設為“關閉”的控制DTC設定服務請求。此請求使用一個單幀請求封包，通過功能尋址發送給所有的ECU。
- d) 通信控制28h 03h 03h：診斷儀通過通信控制（28h）服務請求，禁止非診斷封包的發送和接收。請求中的控制類型參數置為“disable the transmissionand the reception”，通信類型置為“application and network management messages”。此請求使用一個單幀請求封包，通過功能尋址發送給所有的ECU。
- e) 讀取資料22h xxh yyh：在禁止正常通信後，讀取被重新整理的ECU的狀态（如：重新整理的應用軟體和資料）。從被重新整理的ECU讀取伺服器辨別資料，如應用軟體辨別、應用資料辨別、Bootloader軟體辨別。
- 2) 主重新整理步驟
在預重新整理步驟之後，是主重新整理步驟。主重新整理時序是單個ECU重新整理事件的應用，是以所有服務的請求都使用實體尋址。
圖3-5描述了在主重新整理步驟中執行的各個服務。
圖3-5 主重新整理步驟
- a) 診斷會話控制10h 02h：在收到一個尋址方式為實體尋址，子功能為重新整理會話的診斷會話控制（10h）服務後，ECU啟動Bootloader，并配置設定重新整理所需的所有資源。ECU需先發送肯定響應再執行跳轉到重新整理模式動作。
- b) 安全通路27h 03h/04h：重新整理事件必須通過安全通路。安全通路（27h）服務在排放相關和安全系統中是強制的。其它系統不要求使用該服務。下載下傳前，通過安全通路過程是強制的，確定隻有合法的診斷儀能對ECU進行下載下傳操作。
為了縮短重重新整理時間，上電可直接執行安全通路服務。
圖3-3描述了Bootloader啟動時序。在應用模式下，使用了兩種不同的診斷會話模式：預設會話模式和擴充會話模式。
在Bootloader模式下，使用了三種不同的診斷會話模式：預設會話模式，擴充會話模式和重新整理會話模式。
如果ECU在正确的條件下收到“10 02”指令，ECU将外部重新整理請求标志位設定為有效，并執行ECU重新開機。
圖3-3 Bootloader啟動時序
上電/複位後，ECU首先執行Bootloader引導代碼，然後檢查外部重新整理請求标志位：
• 如果應用軟體是有效的，則啟動應用模式；
• 如果應用軟體無效，ECU停留在Bootloader模式下的預設會話模式。
在Bootloader模式下，有以下幾種方式，會導緻ECU重新開機：
Ø 無論目前處于何種會話模式，“11h 01h”都會引導ECU重新開機；
Ø 在擴充會話模式或程式設計會話模式下，S3定時器逾時會導緻ECU重新開機；
Ø 在程式設計會話模式下，“10h 01h”會導緻ECU重新開機。
重新整理時序分為三個程式設計步驟：
如果在預重新整理、主重新整理和後重新整理步驟過程中，任何實體尋址的請求及響應不滿足要求，則全部時序需被再次執行。
預重新整理步驟用來為要下載下傳的ECU做重重新整理前的CAN網絡準備。此步驟也包含了提高下載下傳速度的準備。此步驟的請求封包能采用的是實體尋址，或功能尋址。預重新整理步驟，如圖3-4所示。
圖3-4 預重新整理步驟
注意：如果ECU在未收到“檢查重新整理預條件”例程（31h 01h FFh 02h）的情況下，收到“10h 02h”請求，ECU将拒絕進入Bootloader模式，并且發送否定響應。
在預重新整理步驟之後，是主重新整理步驟。主重新整理時序是單個ECU重新整理事件的應用，是以所有服務的請求都使用實體尋址。
圖3-5描述了在主重新整理步驟中執行的各個服務。
圖3-5 主重新整理步驟
為了縮短重重新整理時間，上電可直接執行安全通路服務。
單個應用軟體或資料塊可能需要多個資料傳輸（36h）請求封包來完成傳輸（當資料塊長度超出網絡層緩存大小時，就會出現這種情況）。
通過ECU複位服務請求将使ECU結束重重新整理過程，傳回到正常的操作模式。記憶體驅動代碼必須從RAM緩存中完全清除，避免意外激活這些可能會進行非預期的記憶體擦除或程式操作的代碼。
圖3-6 後重新整理步驟
- c) 驅動下載下傳34h，36h，37h，31h：當ECU的非易失性存儲單元中沒有存儲記憶體驅動時，将執行記憶體驅動的下載下傳。下載下傳應該按照如下時序來進行：請求下載下傳、傳輸資料、請求傳輸退出。下載下傳完所有位元組後，用“檢查重新整理完整性”例程（31h 01h F0h 01h）來檢查所有的位元組都正确傳輸。
- d) 寫入資料2Eh F1h 5Ah：在擦除記憶體例程之前，将“指紋”寫到ECU記憶體中是強制的。“指紋”辨別了是哪個診斷儀對ECU記憶體做了修改。使用F1h5Ah資料辨別符而不是引導軟體指紋、應用軟體指紋、應用資料指紋這些資料辨別符。每個邏輯塊（除了驅動）下載下傳前，診斷儀将首先寫“指紋”，在下載下傳完邏輯塊後，ECU将識别之前下載下傳的程式是哪個邏輯塊（即邏輯塊序号），并根據邏輯塊的序号将它存儲。在追蹤指紋資訊時，診斷儀将發封包“22hF1h 5Bh”，ECU将通過“62h F1h 5Bh…”，傳回每一個邏輯塊的指紋資訊。
- e) 例程控制——“擦除記憶體”31h 01h FFh 00h：為了允許應用軟體和資料下載下傳，ECU的記憶體将被擦除。此步驟通過例程控制服務（31h）來執行擦除記憶體。如果擦除記憶體例程被調用執行，那麼應用軟體的标志位将被置為無效。
- f) 下載下傳過程34h，36h，37h：應用軟體或者資料的每一個連續的資料塊（也叫段，可能是一個完整的應用軟體或者資料，也可能是應用軟體或者資料的一部分）下載下傳到ECU非易失性記憶體中，都是遵循下面的服務順序完成數傳輸：
- Ø 請求下載下傳（34h）；
-
Bootloader
Bootloader是所有支援重程式設計的ECU必須具備的軟體功能，在ECU運作過程中，執行的是應用軟體和應用資料，僅當應用軟體或應用資料無效時，或者要求對其進行更新或特殊測試的時候，Bootloader軟體才被激活。
應用軟體和應用資料可以同時程式設計或者互相獨立程式設計，不允許重新程式設計時更新Botloader軟體。Bootloader軟體存儲于被保護的存儲器區域，即使發生潛在錯誤時，控制器始終保證可重新程式設計。
- 2.1.1 安全機制
-
為確定下載下傳的安全，ECU需設計安全機制，避免以下幾種情況：
a. 來自非法源的下載下傳動作；
b. 目前重新整理條件不滿足；
c. 下載下傳錯誤的應用軟體或應用資料到ECU；
d. 軟體之間不相容；
3.2.1.1.1安全通路
ECU通過SEED&KEY機制進行安全通路服務限制，保證ECU免遭未授權的程式設計動作影響。
3.2.1.1.2 重新整理預條件
ECU確定重新整理時處于安全狀态，條件不滿足（如高壓上電或車輛運作）時，重新整理服務請求将被拒絕。
3.2.1.1.3 完整性校驗
ECU對即将下載下傳到存儲器的程式或資料進行完整性檢查，當一個邏輯子產品下載下傳後，使用CRC32算法驗證目前邏輯塊的所有資料位元組是否被正确傳輸和寫入。通過“檢查程式設計完整性”例程控制激活ECU完整性校驗。當ECU接收到此服務請求時，Bootloader将計算下載下傳資料位元組的CRC32值，并将計算結果與診斷儀請求封包中發送的校驗值進行比較。
3.2.1.1.4 一緻性檢查
不相容的軟體不能配合使用，如果配合使用可能會使功能異常或産生緻命性錯誤。為此，ECU通過驗證軟體相容性來檢查重新整理程式的一緻性，包括應用軟體與Bootloader軟體、應用資料與應用軟體檢驗等。
3.2.1.1.5 有效性檢查
ECU内部有一個标志位，用于辨別應用軟體是否有效。如果重新整理完整性檢查和一緻性檢查都正确時，ECU才會設定應用軟體的标志位為有效。隻有标志位為有效時，應用軟體才可以運作。
- 2.1.2 重新整理檔案格式
- 重新整理檔案格式為Intel格式(*.hex)。
- 2.1.3 ECU啟動時序
- 在每次上電/複位後，ECU首先執行Bootloader代碼。Bootloader首先執行一些基本的初始化，然後檢查重新整理請求标志位是否為有效，如果重新整理請求标志位有效，即使應用程式是有效的，Bootloader也會繼續運作。如果目前沒有重新整理請求，即重新整理請求标志位為無效，則檢查應用軟體的狀态，如果應用軟體是有效的，則應用軟體代碼将被執行，如果應用軟體是無效的，則繼續執行Bootloader代碼。 圖3-2 ECU啟動時序
Bootloder開發方案(基于UDS) - 2.1.4 重新整理流程
- 2.1.4.1 Bootloader啟動時序
- 如果外部重新整理請求标志位為有效，那麼即使應用程式是有效的，Bootloader也會繼續進一步執行，在此情況下，ECU直接進入程式設計會話模式。
- 如果外部重程式設計請求标志位為無效，則繼續檢查應用軟體的标志位狀态：
- 2.1.4.2 重新整理時序
- 預重新整理步驟：重新整理前的CAN網絡準備；
- 主重新整理步驟：下載下傳應用軟體或應用資料；
- 後重新整理步驟：重同步CAN網絡。
- 預重新整理步驟
- a) 診斷會話控制10h 03h：為了禁止ECU間的正常通信和控制DTC設定，預重新整理需要啟動非預設會話模式。通過使用會話類型為擴充會話模式的診斷會話控制（10h）服務來完成。此請求使用一個單幀請求封包，通過功能尋址發送給所有的ECU。
- b) 例程控制“檢查重新整理預條件”31h01h FFh 02h：通過此例程來檢查ECU重新整理條件，進而確定系統安全，如果有任何不安全的因素，ECU将拒絕重新整理。
- c) 控制DTC設定85h 02h：診斷儀通過DTC設定類型設為“關閉”的控制DTC設定服務請求。此請求使用一個單幀請求封包，通過功能尋址發送給所有的ECU。
- d) 通信控制28h 03h 03h：診斷儀通過通信控制（28h）服務請求，禁止非診斷封包的發送和接收。請求中的控制類型參數置為“disable the transmissionand the reception”，通信類型置為“application and network management messages”。此請求使用一個單幀請求封包，通過功能尋址發送給所有的ECU。
- e) 讀取資料22h xxh yyh：在禁止正常通信後，讀取被重新整理的ECU的狀态（如：重新整理的應用軟體和資料）。從被重新整理的ECU讀取伺服器辨別資料，如應用軟體辨別、應用資料辨別、Bootloader軟體辨別。
- 2) 主重新整理步驟
- a) 診斷會話控制10h 02h：在收到一個尋址方式為實體尋址，子功能為重新整理會話的診斷會話控制（10h）服務後，ECU啟動Bootloader，并配置設定重新整理所需的所有資源。ECU需先發送肯定響應再執行跳轉到重新整理模式動作。
- b) 安全通路27h 03h/04h：重新整理事件必須通過安全通路。安全通路（27h）服務在排放相關和安全系統中是強制的。其它系統不要求使用該服務。下載下傳前，通過安全通路過程是強制的，確定隻有合法的診斷儀能對ECU進行下載下傳操作。
- c) 驅動下載下傳34h，36h，37h，31h：當ECU的非易失性存儲單元中沒有存儲記憶體驅動時，将執行記憶體驅動的下載下傳。下載下傳應該按照如下時序來進行：請求下載下傳、傳輸資料、請求傳輸退出。下載下傳完所有位元組後，用“檢查重新整理完整性”例程（31h 01h F0h 01h）來檢查所有的位元組都正确傳輸。
- d) 寫入資料2Eh F1h 5Ah：在擦除記憶體例程之前，将“指紋”寫到ECU記憶體中是強制的。“指紋”辨別了是哪個診斷儀對ECU記憶體做了修改。使用F1h5Ah資料辨別符而不是引導軟體指紋、應用軟體指紋、應用資料指紋這些資料辨別符。每個邏輯塊（除了驅動）下載下傳前，診斷儀将首先寫“指紋”，在下載下傳完邏輯塊後，ECU将識别之前下載下傳的程式是哪個邏輯塊（即邏輯塊序号），并根據邏輯塊的序号将它存儲。在追蹤指紋資訊時，診斷儀将發封包“22hF1h 5Bh”，ECU将通過“62h F1h 5Bh…”，傳回每一個邏輯塊的指紋資訊。
- e) 例程控制——“擦除記憶體”31h 01h FFh 00h：為了允許應用軟體和資料下載下傳，ECU的記憶體将被擦除。此步驟通過例程控制服務（31h）來執行擦除記憶體。如果擦除記憶體例程被調用執行，那麼應用軟體的标志位将被置為無效。
- f) 下載下傳過程34h，36h，37h：應用軟體或者資料的每一個連續的資料塊（也叫段，可能是一個完整的應用軟體或者資料，也可能是應用軟體或者資料的一部分）下載下傳到ECU非易失性記憶體中，都是遵循下面的服務順序完成數傳輸：
- Ø 請求下載下傳（34h）；
- Ø 傳輸資料（36h）；
- Ø 請求退出傳輸（37h）。
- g) 例程控制——“檢查重新整理完整性”31h 01h F0h 01h：此例程用來檢查邏輯塊的完整性。
- h) 例程控制——“檢查重新整理一緻性”31h 01h FFh 01h：一旦完成所有的應用軟體或資料塊/子產品的下載下傳，診斷儀将開始一個例程來觸發ECU檢查重重新整理的一緻性。
- i) 電控單元複位11h 01h：診斷儀使用實體尋址，發送一個複位類型為硬複位的ECU複位（11h）服務請求封包到CAN網絡上。
- 後重新整理步驟
- a) 診斷會話控制10h 01h：診斷儀發送一個會話類型為預設會話的診斷會話控制（10h）服務請求封包到CAN網絡上。所有的ECU接收到診斷會話控制（10h），而進入到預設會話模式。此請求通過功能尋址發送，請求發送給所有包含在程式設計事件中或是以而進入非預設會話模式的ECU。跳轉到預設會話模式，表示通信控制（28h）服務和控制DTC設定（85h）服務也将複位到預設狀态。
- b) 清除診斷資訊14h FFh FFh FFh：如果重程式設計ECU在程式設計步驟被重新開機，當程式設計ECU運作在預設會話模式時，網絡上其它的ECU仍然在不能正常通信狀态，此時，一些可能被存儲在程式設計ECU中的診斷資訊就應該通過實體尋址的清除診斷資訊（14h）服務來清除。
- Ø 傳輸資料（36h）；
- Ø 請求退出傳輸（37h）。
單個應用軟體或資料塊可能需要多個資料傳輸（36h）請求封包來完成傳輸（當資料塊長度超出網絡層緩存大小時，就會出現這種情況）。
- g) 例程控制——“檢查重新整理完整性”31h 01h F0h 01h：此例程用來檢查邏輯塊的完整性。
- h) 例程控制——“檢查重新整理一緻性”31h 01h FFh 01h：一旦完成所有的應用軟體或資料塊/子產品的下載下傳，診斷儀将開始一個例程來觸發ECU檢查重重新整理的一緻性。
- i) 電控單元複位11h 01h：診斷儀使用實體尋址，發送一個複位類型為硬複位的ECU複位（11h）服務請求封包到CAN網絡上。
通過ECU複位服務請求将使ECU結束重重新整理過程，傳回到正常的操作模式。記憶體驅動代碼必須從RAM緩存中完全清除，避免意外激活這些可能會進行非預期的記憶體擦除或程式操作的代碼。
- 後重新整理步驟
圖3-6 後重新整理步驟
- a) 診斷會話控制10h 01h：診斷儀發送一個會話類型為預設會話的診斷會話控制（10h）服務請求封包到CAN網絡上。所有的ECU接收到診斷會話控制（10h），而進入到預設會話模式。此請求通過功能尋址發送，請求發送給所有包含在程式設計事件中或是以而進入非預設會話模式的ECU。跳轉到預設會話模式，表示通信控制（28h）服務和控制DTC設定（85h）服務也将複位到預設狀态。
- b) 清除診斷資訊14h FFh FFh FFh：如果重程式設計ECU在程式設計步驟被重新開機，當程式設計ECU運作在預設會話模式時，網絡上其它的ECU仍然在不能正常通信狀态，此時，一些可能被存儲在程式設計ECU中的診斷資訊就應該通過實體尋址的清除診斷資訊（14h）服務來清除。