前言
本文将介绍在使用 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 的流程框图。