基于NXP例程学习CAN UDS刷写流程

前言

基于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抓取的该阶段的数据如下所示。

---

如果觉得这篇文章对你有用，帮忙给个一键三连！！！