本文將介紹在使用 MM32F0140 系列 MCU 實現 UDS Bootloader 過程中涉及到的 FlexCAN、UDS 和 Bootloader 等相關基本概念。

MM32F0140 簡介

MM32F0140 使用高性能的 Arm? Cortex-M0 內核的 32 位微控制器，最高工作頻率可達 72MHz，內置 64KB Flash 和 8KB SRAM，有豐富的增強型 I/O 端口和包括 FlexCAN 在內等多種外設，適用于汽車診斷儀，后裝汽車協控制器和消防監控等多種應用場合。

圖 1 MM32F1040 簡介

什么是 FlexCAN?

CAN 是控制器域網 (Controller Area Network, CAN) 的簡稱，是一種功能豐富的車用總線標準，被設計用于在不需要主機（Host）的情況下，允許網絡上的單芯片和儀器相互通信。是由研發和生產汽車電子產品著稱的德國 BOSCH 公司開發了，并最終成為國際標準（ISO11898）。是國際上應用最廣泛的現場總線之一。FlexCAN 是 CAN 協議的一個高完成度版本。

MM32F0140 系列 MCU 內嵌的 FlexCAN，符合 ISO 11898-1 標準，支持 CAN 2.0B 版本協議，位速率高達 1 Mbps，具有非常靈活的用于傳輸和接收的郵箱系統，可以接收和發送 11 位標識符的標準幀，也可以接收和發送 29 位標識符的擴展幀，主要被設計用作車載串行總線，可滿足實時處理、車輛在電磁干擾環境下的可靠操作、成本效益、帶寬等要求。

什么是 UDS?

UDS（Unified Diagnostic Services，統一診斷服務）是一種用于汽車電子控制器 ECU (Electronic Control Units) 環境下的一種診斷通信協議，可實現診斷、固件更新、日常測試等功能，在 ISO 14229 中規定了其實現標準。

在本實例中，UDS 通信是在客戶端-服務端關系中執行的。客戶端是上位機下載軟件運行于 PC 機，服務端是 MM32F0140 系列 MCU。例如，將 CAN 總線接口連接到 MCU，并將 UDS 請求發送到 MCU。當 MCU 支持 UDS 服務時，它將根據客戶端發出的請求做出相應的響應。

為什么用 Bootloader？

對于 ECU 而言，如果程序內置有基于FlexCAN Bootloader，則每次更新 ECU 的固件可不必再使用燒錄器進行燒錄，而可直接通過 CAN 總線來更新程序，而且隨著汽車智能化的普及，甚至可以對 ECU 進行遠程升級。有無 Bootloader 功能程序結構對比如圖 2 所示：

圖 2 程序結構對比框圖

為什么要基于 UDS?

為了規范 Bootloader 的全過程。因 UDS 在設計時考慮了 Bootloader 的需求，并為 Bootloader 提供了相關服務以供使用，故主機廠普遍會要求在 UDS 規范的基礎上完成 Bootloader 功能。

使用到哪些 UDS 服務？

● 在 Bootloader 中，使用到 UDS 的 $10、$11、$27 和 $3E 基礎診斷服務，$22、$2E 讀寫 DID 服務，$31、$34、$36 和 $37 固件數據傳輸相關服務。

● 在 APP 中，使用到 UDS 的 $85 和 $28 服務，保證暫停 CAN 正常通信，暫停記錄 DTC，讓被升級設備升級。

UDS 提供的服務概覽如圖 3 所示：

圖 3 UDS 服務概覽

CAN、UDS 和 OSI 模型之間的關系

為了更好的理解 UDS, 讓我們了解一下 CAN 總線、UDS 和 OSI 模型之間的關系。

CAN 對應于 OSI 模型中的數據鏈路層和物理層描述（根據 ISO 11898）。

與 CAN 相比， UDS (ISO 14229) 是一種 “更高層協議”， 在 OSI 模型中使用到會話層和應用層，如下圖 4 所示：

圖 4 UDS 與 OSI 模型對應圖

UDS 的消息結構

PDU

Network_Protocol Data Unit, 網絡層協議數據單元

PDU 是用于建立對等實體間的通信，是一組信息和數據的集合，表示了發送發和接收方對等實體之間傳遞的信息和數據。由地址信息（CAN ID）、協議控制信息(PCI) 和數據構成。

圖 5 為 UDS 消息結構示意圖，圖 6 為 UDS 消極響應示意圖。

圖 5 UDS 消息結構
圖 6 UDS 消極響應示意

PCI

Protocol Control Information，協議控制信息

PCI 字段本身與 UDS 請求本身沒有關系，但是對于在 CAN 總線上發出的診斷 UDS 請求是必需的。PCI 字段可以長達 1 ~ 3 字節，并且包含與傳輸不適合單個 CAN 幀的消息有關的信息。

SID

Service ID，服務標識符

當希望使用特定的 UDS 服務時，UDS 請求消息應該在數據有效負載中包含 UDS 服務標識符 (SID)。標識符分為請求 SID 和響應 SID。

SFB

Sub Function Byte，子函數字節

在一些 UDS 請求幀中使用，在一些 UDS 服務中，如 0x22，子函數字節沒有使用。一般來說，當一個請求被發送到 ECU 時，ECU 可以做出正向或負向的響應。在響應為正向的情況下，測試人員可能想要抑制響應(因為它可能是不相關的)。這是通過在子函數字節中將第 1 位設置為 1 來完成的。負向的反應是無法被抑制的。剩下的7位可以用來定義最多 128 個子函數值。例如，當通過 SID 0x19(讀取診斷信息)讀取 DTC 信息時，子函數字節可用于控制報告類型。

DID

Data Identifier，數據標識符

在大多數 UDS 請求服務中，各種類型的請求數據參數用于提供 SID 和可選子函數字節以外的請求進一步配置。

ISO-TP 標準

ECU 固件更新通常涉及大量有效載荷的通信，而 ISO-TP 標準（ISO 15765 ）就是為了解決基于 CAN 的車輛診斷的大量有效載荷問題而提出。該標準指定了基于CAN 的車輛網絡傳輸協議和網絡層服務，最常見的用例就有 UDS （ISO 14229-1）。

ISO-TP 標準概述了如何通過分段、流量控制和重組來傳輸高達 4096 字節的 CAN 數據有效載荷。ISO-TP 定義了用于通信的 CAN 幀，如下圖 7 所示。

圖 7 ISO-TP 幀類型

通過使用 ISO-TP 標準將 UDS 的消息結構 PDU 分為了四種類型：

SF (Single Frame， 單幀)

描述單幀傳輸。

FF (First Frame， 首幀)

描述多幀傳輸的起始。

CF (Consecutive Frame，連續幀)

用于在多幀傳輸中傳輸數據。

FC (Flow Control Frame，流控幀)

用于在多幀傳輸過程中，對報文流控制。

UDS 的單幀通信和多幀通信：

單幀通信如圖 8 所示：

圖 8 單幀通信

多幀通信過程如圖 9 所示：

圖 9 多幀通信

基于 UDS Bootloader 實現更新 APP 流程框圖

MM32F0140 系列 MCU 使用 FlexCAN 實現基于 UDS Bootloader 更新 APP 的流程框圖如10所示：

圖10 更新 APP 流程

結語

本文以 MM32F0140 系列 MCU 的 FlexCAN 為例，簡要介紹了在使用 MM32F0140 系列 MCU 實現 UDS Bootloader 過程中涉及到的 FlexCAN、UDS 和 Bootloader 等相關基本概念，并介紹了 UDS 的消息結構和 ISO-TP 標準，以及展示了 MM32F0140 系列 MCU 使用 FlexCAN 實現 UDS Bootloader 更新 APP 的流程框圖。

來源：靈動MM32MCU

審核編輯：湯梓紅