前言

基于EcuBus-Pro實現CAN UDS升級

上文介紹了如何使用EcuBus-Pro實現CAN UDS升級的上位機，本文基于EcuBus-Pro監控的數據，詳細介紹下S32K144官方CAN UDS Bootloader的流程。

筆者沒有UDS的實戰經驗，所以文章內容是參考《GB/T 40822-2021》和一些網絡上的培訓資料完成，如果有不對的地方，還請幫忙評論區指出。

1.概述

通常車廠提高的DBC文件中有三類報文，如下所示：

• 應用報文，用于多個ECU之間交互功能，比如執行開轉向燈功能。
• 診斷報文，用于Tester讀取ECU端存儲的故障信息，程序升級等。
• 網絡管理報文，用于協調多個ECU進行有序的休眠喚醒。

下文要介紹的CAN UDS刷寫，使用的就是診斷報文。

1.1 診斷報文

Tester端和ECU端使用診斷報文傳輸的流程圖如下：

可以看到診斷報文的使用也是按照OSI模型來的，如下圖所示：

2.協議數據單元(N_PDU)

按上文描述，診斷報文需要經過網絡層進行組包拆包，所以需要了解網絡層的協議格式，即N_PDU的組成,如下圖所示。

其中，N_AI，N_PCI，N_Data的說明如下圖所示。

2.1 尋址信息（N_AI）

尋址方式按通信對象分為功能尋址和物理尋址；按地址格式分為常規尋址、常規固定尋址、擴展尋址、混合尋址四種方式。

另外，下文提到的SA和TA的意義如下：

• 源地址(SA):發送節點地址
• 目標地址(TA):接收節點地址

2.1.1 物理尋址

物理尋址，即Tester和ECU一對一通信，示例圖如下：

2.1.2 功能尋址

功能尋址，即Tester向多個ECU發出同一功能的診斷請求，示例圖如下：

2.1.3 常規尋址（Normal addressing）

常規尋址，使用11位CAN ID，將N_AI映射到消息幀的CAN ID區域，但是沒有規定N_AI與CAN ID的具體映射關系，如下圖所示。

常規尋址是最常見的尋址方式，對于常規尋址：

• 如果使用物理地址，每個ECU需要分配兩個CAN ID，一個用于請求，一個用于響應。

• 如果使用功能地址，同一個組的ECU共用一個CAN ID用于請求。

2.1.4 常規固定尋址（Normal fixed addressing）

常規固定尋址，使用29位CAN ID，與混合尋址編排方式類似，完整定義了N_AI如何映射到29位CAN ID，格式如下圖所示。

下文介紹的S32K1 CAN UDS升級流程，就是使用的這種尋址方式。

2.1.5 擴展尋址（Extended addressing）

擴展尋址，使用11位CAN ID，N_AI中的N_TA映射到CAN數據幀的第一個字節，其它域映射到CAN ID，格式如下圖所示。

2.1.6 混合尋址（Mixed addressing）

混合尋址，僅用于遠程診斷，格式如下圖所示。

2.2 協議控制信息(N_PCI)

PCI的結構如下圖所示，根據后續發送的N_Data長度分為單幀和多幀兩種。

2.2.1 單幀（SF）

當N_Data的長度在7個字節以內，選擇單幀發送。

上圖中的SF_DL代表N_Data的長度，<=7個字節，一個單幀的示例如下圖：

2.2.2 多幀

當N_Data的長度超過7個字節，需要選擇多幀發送。一個多幀的示例如下圖：

多幀報文需要用到三種報文：

• 第一幀FF，其中FF_DL代表N_Data的長度，>7個字節，<=4095個字節。單獨的FF示例如下：

• 連續幀CF，其中SN用于0-F循環計數。單獨的CF示例如下：

• 流控幀FC，相關的參數有FS、BS和STmin，參數說明和單獨的FC示例如下：

參數	值	含義
FS	0	繼續發送。讓發送方繼續發送接下來的連續幀，表示接收方已經準備好了接收最大為BS數量的連續幀。
	1	等待。發送方等待下一幀流控幀并重置自己的計時。一般用于接收方沒有處理完上一次接收到的連續幀。
	2	過載。發送方打算發送的數據長度超過了接收方的儲存能力。
BS	1~FF	表示發送方在發送BS數值的連續幀之后，需要等待接收方的流控幀。
	0	表示不需要任何流控幀，直接發送全部數據。
STmin	00~7F	單位為ms
	F1~F9	表示0.1~0.9ms
	0	按照發送方最快的速度發送

3.診斷服務

N_Data和應用層的關系對應關系如下：

• N_Data的第一個字節對應診斷服務ID
• N_Data的第二個字節對應診斷服務的子功能或者數據參數（不具有子功能的診斷服務）

接下來介紹Tester和ECU基于診斷服務的交互方式，以及常見的診斷服務。

3.1 請求和響應

診斷服務的交互模式一般是是Tester發起服務請求，ECU端對服務進行響應。

3.1.1 流程圖

診斷服務的請求和響應的流程圖如下：

3.1.2 消息流格式

流程圖中的消息流對應的格式如下圖所示：

3.1.3 抑制肯定響應

有些時候為了提高傳輸效率，有些服務不回復肯定響應報文，即抑制肯定響應，通過設置請求消息流的子功能參數的bit7，如下圖所示：

3.1.4 NRC

常見的NRC如下圖所示，更多NRC的描述,查閱《GB/T 40822-2021》。

3.2 常見服務

下圖是常見的服務以及支持的會話模式。

下面詳細介紹下S32K1官方CAN UDS升級例程使用到的幾種服務。

DiagnosticSessionControl(診斷會話控制)($10)服務

服務描述

DiagnosticSessionControl(診斷會話控制)服務用于在服務端中啟用不同的診斷會話。

請求/響應

請求/響應消息格式如下：

數據參數定義如下：

該服務支持的NRC如下：

ECUReset(ECU 復位)($11)服務

服務描述

客戶端使用ECUReset(ECU 復位)服務來請求服務端復位。

該服務請求服務端根據嵌入在ECU 復位請求消息中的復位類型參數值的內容有效地執行服務端復位。可以在服務端中執行復位之前或之后發送ECU 復位肯定響應消息(如果需要)。建議在執行ECU 復位之前發送ECU 復位肯定響應消息。

請求消息

請求消息的定義如下：

請求消息子功能的定義如下：

響應消息

肯定響應消息的定義如下：

支持的NRC如下：

SecurityAccess(安全訪問)($27)服務

服務描述

該服務的目的是提供訪問數據和/或診斷服務的手段,這些服務由于保密、排放或安全的原因而受到限制。

該用于將例程或數據下載或上傳到服務端和從服務端讀取指定的內存位置的診斷服務,可能需要在SecurityAccess(安全訪問)的情況下進行。

下載到服務端的非正常例程或數據可能會損壞電子設備或其他車輛部件,或者影響車輛排放、保密或安全標準的符合性。保密概念利用了種子和密鑰之間的關系。

使用該服務的典型示例如下所示

• 客戶端請求“種子”;
• 服務端發送“種子”;
• 客戶端發送“密鑰”(與接收的種子配對);
• 服務端響應“密鑰”有效,并且它將自行解鎖。

主機廠一般會設置不同的安全等級，用于執行后續不同的功能。安全級別切換的常見方式如下：

請求消息

請求消息的定義如下：

子功能參數的定義如下：

requestSeed(請求種子)值與sendKey(發送密鑰)值具有固定關系:

• “requestSeed=01”確定了“requestSeed=01”和“sendKey=02”之間的固定關系;
• “requestSeed=03”確定了“requestSeed=03”和“sendKey=04”之間的固定關系。

數據參數的定義如下：

響應消息

肯定響應消息的定義如下：

支持的NRC如下：

CommunicationControl(通信控制)($28)服務

服務描述

該服務的目的是開啟/關閉服務端(例如應用程序通信消息)某些消息的發送和/或接收。

請求消息

請求消息的定義如下：

子功能參數的定義如下：

數據參數的定義如下：

響應消息

肯定響應消息的定義如下：

支持的NRC如下：

WriteDataByIdentifier(通過標識符寫數據)($2E)服務

服務描述

通過標識符寫數據服務允許客戶端向服務端中給定數據標識符指定的內部位置寫入信息。

請求消息

請求消息的定義如下：

數據參數包含的值定義太多，文章篇幅有限，有興趣的建議查看《GB/T 40822-2021》的附錄C.1。

響應消息

肯定響應消息的定義如下：

支持的NRC如下：

RoutineControl(例程控制)($31)服務

服務描述

客戶端使用RoutineControl(例程控制)服務執行指定的步驟的序列并且獲得任何相關結果。

該服務具有較大靈活性,但一般用途包括擦除內存、重置或學習自適應數據、運行自測試、覆蓋正常服務端控制策略、控制服務端值隨時間變化以及預定義序列(比如關閉敞篷車頂)等。

客戶端使用RoutineControl(例程控制)服務進行如下操作：

• StartRoutine(啟動例程)；
• StopRoutine(停止例程)；
• 請求例程結果。

使用2字節routineIdentifier(例程標識符)。

請求消息

請求消息的定義如下：

子功能參數的定義如下：

數據參數的定義如下：

響應消息

肯定響應消息的定義如下：

肯定響應消息的數據參數定義如下：

支持的NRC如下：

RequestDownload(請求下載)($34)服務

服務描述

客戶端利用“requestDownload(請求下載)”服務啟動客戶端到服務端之間的數據傳輸(下載)。

服務端收到“requestDownload(請求下載)”請求消息后,應在其發送肯定響應消息之前采取必要行動接收數據。

請求消息

請求消息的定義如下：

數據參數的定義如下：

響應消息

肯定響應消息的定義如下：

肯定響應消息的數據參數定義如下：

支持的NRC如下：

TransferData(傳輸數據)($36)服務

服務描述

客戶端利用傳輸數據服務從客戶端向服務端(下載)或從服務端向客戶端(上傳)傳輸數據。

請求消息

請求消息的定義如下：

數據參數的定義如下：

響應消息

肯定響應消息定義如下：

肯定響應消息的數據參數定義如下：

支持的NRC如下：

RequestTransferExit(請求傳輸終止)($37)服務

服務描述

客戶端利用此服務終止客戶端與服務端之間的數據傳輸(上傳或下載)

請求消息

請求消息的定義如下：

數據參數的定義如下：

響應消息

肯定響應消息定義如下：

肯定響應消息的數據參數定義如下：

支持的NRC如下：

4.刷寫流程

整個刷寫流程分三步，分別是預編程階段、編程階段以及后編程階段。

4.1 預編程階段

預編程階段主要做一些程序升級前的準備工作，包括禁用DTC設置以及非診斷通信等。

預編程階段的流程圖如下所示，左側的標準步驟是必須要實現的。

從EcuBus-Pro抓取的該階段的數據如下所示。

MCU例程沒有DTC設置的功能，所以未使用$85服務關閉DTC設置。

4.2 編程階段

編程階段是對MCU程序進行升級的主要階段。

編程階段的流程圖如下所示。

從EcuBus-Pro抓取的該階段的數據如下所示。

$36服務傳輸的數據量太大，下圖隱藏了大量的傳輸數據。如果需要查看完整數據，可以去前文提供的gitee倉庫查看log表格。

4.2.1 $31服務

其它服務內容的實現細節，可以通過前文提到的EcuBus-Pro工程的腳本文件詳細查看；關于例程控制($31)服務，下面簡單描述下。

S32K1官方demo使用的$31服務包含了三種RoutineID,如下圖所示。

三種RoutineID實現的功能如下圖：

• Routine=0xFF00，實現Flash擦除功能
• Routine=0x0202，發送CRC校驗碼，用于確認傳輸數據的完整性，即傳輸過程中數據是否有丟包或被篡改。
• Routine=0xFF01，編程依賴性檢查，確認傳輸的固件是否合法有效，即上位機給過來的固件是否來源可靠，功能是否驗證過。

4.3 后編程階段

后編程階段用于在MCU程序升級完成后進行硬件復位，以及將編程會話切換到默認會話。

后編程階段的流程圖如下所示。

從EcuBus-Pro抓取的該階段的數據如下所示。

---

如果覺得這篇文章對你有用，幫忙給個一鍵三連！！！