上位机刷写hex文件报文|及EOL文件刷写log文件解析

刷写报文解析

                                                                                                                                            本人原创

本文档旨在提供一个系统化的学习路径以帮助快速掌握UDS（统一诊断服务）报文的解读，首先介绍地址格式；然后简要介绍包括缩略语、寻址方式、请求格式、肯定响应抑制、响应格式及会话模式在内的基础概念；接着列出常用服务请求与响应的实例；最后聚焦于帧格式，并通过一个完整的EOL刷写流程报文案例逐条解析。遵循此路径，从理解地址格式开始，查看各章节示例直至全流程解析，可以有效提升对UDS报文的理解能力。

由于各章节均配有示例小节，如果想要快速构建UDS报文解析能力建议读者直接学习各章的示例小节与末章全流程案例，有疑问再根据目录查阅想要了解的地方。需要说明的是，本文侧重建立协议认知框架与实操导向的报文解析能力，相关技术细节可通过延伸阅读各章节参考资料进行拓展学习。

地址格式：

注意CANID的构成较为复杂且有丰富的含义，这里仅根据个人经验，基于实用的角度解释，可以简单理解为：

地址：前2字节为UDS地址 || 第3字节：目标地址 || 最后1字节：源地址

假设参数设置：

UDS物理地址：0x19AB     UDS功能地址：0x19AD

Flasher 上位机通过诊断CAN向ECU芯片刷写hex时：

控制器物理地址：0x06  控制器功能地址：0x66 上位机物理地址：0x32 

诊断仪通过诊断CAN向ECU芯片刷写EOL时（同UDS服务测试时）：

控制器物理地址：0x0A  控制器功能地址：0x66 诊断仪物理地址：0xF4  

示例：

19ABF406 代表物理寻址方式，ECU向诊断仪发送响应报文。

19AB06F4 代表物理寻址方式，诊断仪向ECU发送请求报文。

19AD66F4 代表功能寻址方式，诊断仪向ECU发送请求报文。

19ADF466 代表功能寻址方式，ECU向诊断仪发送响应报文。

(注意：但在UDS服务中，应规范要求，当诊断仪以功能寻址发送请求时，ECU仍以物理寻址方式响应，即收到19AD66F4时，ECU回复19ABF406）

DeepSeek介绍 CAN ID：

在SAE J1939标准下，扩展帧标识符 19AB06F4 的源地址和目的地址分布如下：

---

1. 标识符分解

将十六进制 19AB06F4 转换为二进制并按字段划分：

字段	十六进制值	十进制值	说明
优先级 (P)	0x1	1	优先级为1（范围0-7，0最高）
保留位 (R)	0	0	固定为0
数据页 (DP)	0x1	1	使用扩展参数组
PDU格式 (PF)	0xAB	171	PF=171（<240，PS为目标地址）
PDU特定 (PS)	0x06	6	目标地址（DA）= 6
源地址 (SA)	0xF4	244	源地址（SA）= 244

---

2. 关键规则

• PF < 240：PS字段表示目标地址（DA），用于点对点通信。

• 地址范围：DA和SA均为8位，有效范围 0-254（0xFF保留）。

---

3. 通信场景

• 标识符 19AB06F4 表示：

  • 优先级为1的报文。

  • 由地址244的节点（SA=0xF4）发送。

  • 目标地址为6的节点（DA=0x06）。

  • 参数组编号（PGN）为 0x01AB00（由PF=171和DP=1计算得出）。

---

4. 总结

• 源地址（SA）：由标识符末尾的8位（0xF4）直接表示。

• 目的地址（DA）：当PF < 240时，由PDU特定字段（0x06）表示。

通过这种结构，CAN网络实现了高效的地址分配和优先级管理。

UDS报文格式以及基础概念

缩略语：

SID—服务ID  标识不同的服务。

FID—功能ID  标识一个服务下不同的子功能。

NRC—否定相应码 当ECU不能做出肯定响应时，NRC提示测试人员给出否定响应的原因。

寻址方式：

可参考：UDS诊断服务—物理寻址，功能寻址区别_物理寻址和功能寻址的区别-CSDN博客

支持功能寻址的服务：10\11\3E\85\14。

全都支持物理寻址。

请求格式：

通常为SID + FID，首字节是服务号，后面加之服务需要的信息，比如0x27安全访问服务，0x01，表示在扩展会话下请求种子，比如0x28通信控制服务，后面加0x00开启服务，0x03 表示要开启与什么相关的通信。

肯定响应抑制：

可参考：抑制肯定响应位的解释与理解_肯定响应抑制位-CSDN博客

抑制肯定响应是指在服务请求中，通过设置特定位来减少服务器对某些服务请求的正向响应。具体概念如下：

1. 抑制肯定响应位位于子功能字节的高位。（0x1000 = 8 发现子功能高字节是8x时就是肯定响应抑制位置1了，比如3E 80/10 82。）
2. 只有支持Subfunction的服务才可能支持肯定响应抑制位。
3. 当肯定响应抑制位为1时，要求所有的肯定响应都不再发送。
4. 当肯定响应抑制位为0时，肯定响应不被抑制。

响应格式：

1. 肯定响应：SID+0x40 比如0x10服务响应0x50，0x31服务响应0x71，首字节后面或许跟着子功能和附加数据（比如响应0x22读服务的回读数据），或者不跟（比如14清故障服务）。在肯定响应抑制时ECU不回复响应报文，zcanpro会显示响应超时。
2. 否定响应：一般情况是7F（表示否定响应）+SID+NRC。特殊的：按照规范，在功能寻址时(仅支持10\11\3E\85\14)的情况下，NRC为0x7E\0x7F\0x11\0x12\0x31时ECU不回复响应报文，即zcanpro会显示响应超时，与肯定响应抑制时实表现相同。

会话介绍：

可参考：[UDS诊断 03- 诊断会话控制(0x10)]-深度解读_uds 10 03-CSDN博客

诊断会话模式由诊断服务层用于访问受限于特定会话的不同诊断服务。

物理寻址下，服务和会话的对应关系，详见规范。

NRC否定响应码

#define NRC_GR      0x10 //GeneralReject（一般错误）

#define NRC_FNS     0x11 //FunctionNotSupported（不支持该服务）

#define NRC_SFNS    0x12 //Sub-functionNotSupported（不支持该子命令）

#define NRC_IMLOIF  0x13 //IncorrectMessageLengthOrInvalidFormat（长度或格式错误）

#define NRC_RTL     0x14 //ResponseTooLong（信息长度超过协议规定）

#define NRC_BRR     0x21 //BusyRepeatRequest（忙请重复指令）

#define NRC_CNC     0x22 //ConditionsNotCorrect（条件不正确）

#define NRC_RSE     0x24 //RequestSequenceError（请求顺序错误）

#define NRC_NRFSC   0x25 //NoResponseFromSubnetComponent（子设备没有响应）

#define NRC_FPEORA  0x26 //FailurePreventsExecutionOfRequestedAction（由于故障请求未执行）

#define NRC_ROOR    0x31 //RequestOutOfRange（请求超出范围）

#define NRC_SAD     0x33 //SecurityAccessDenied（安全访问未授权）

#define NRC_IK      0x35 //InvalidKey（密码错误）

#define NRC_ENOA    0x36 //ExceededNumberOfAttempts（超过尝试次数）

#define NRC_RTDNE   0x37 //RequiredTimeDelayNotExpired（未达要求的延时）

#define NRC_UDNA    0x70 //UploadDownloadNotAccepted（上传/下载不接受）

#define NRC_TDS     0x71 //TransferDataSuspended（数据传输暂停）

#define NRC_GPF     0x72 //GeneralProgrammingFailure（一般编程故障）

#define NRC_WBSC    0x73 //WrongBlockSequenceCounter（块序号错误）

#define NRC_RCRRP   0x78 //RequestCorrectlyReceived-ResponsePending（请求正确但响应挂起）

#define NRC_SFNSIAS 0x7E //Sub-functionNotSupportedInActiveSession（在当前阶段不支持该子命令）

#define NRC_SNSIAS  0x7F //ServiceNotSupportedInActiveSession（在当前阶段不支持该服务）

UDS常用服务请求与响应报文示例

阅读UDS报文信息时，为快速了解故障点，只需要关注在哪里发生了否定响应，响应码是什么，然后根据规范文件检查是否是请求顺序、请求格式、请求内容发生错误。

SID (Hex)	FID 诊断服务名	请求与响应示例
10	[DST] 0x01， 0x02， 0x03 诊断会话控制，切换会话	10 01 请求进入默认会话 50 01 肯定响应 7F 10 NRC
11	[RT]   0x01 ECU控制器重启，模拟服务器断开电源后通常执行的开机顺序	11 01 请求ECU软复位的方式重启 肯定响应特殊处理：(1)7F 11 78 (2) 51 01 否定响应：7F 11 NRC
27	[SAT] 0x01 0x02 扩展模式下安全访问 0x09 0x0A 编程会话下安全访问 安全访问服务，判断是否授予客户端安全访问权限	27 01 扩展会话下请求种子 67 01 SEED 响应种子 27 02 KEY 请求解锁 67 02 成功结果 编程会话下同理，否定响应不再举例
28	[CT]   0x00，0x03 [CT] 0x03 通信控制，开启/关闭某通信类型的报文通信	28 00 03 开启所有与应用程序或网络管理相关通信 28 03 03 关闭所有与应用程序或网络管理相关通信（OTA刷写时，用于禁掉报文，避免阻塞升级）
3E	[ZSF] 0x00 待机访问，用于维持会话请求	如果ECU长时间没有收到请求，会话会自动恢复为默认会话，为了维持当前的会话，所以设置这个服务，当收到时ECU无条件返回7E 00。当然3E 80是抑制肯定响应的。
85	[DTCST] 0x01，0x02 DTC故障码控制设置，在14清故障前要关闭故障更新	85 01 开启诊断故障代码更新 C5 01 肯定响应 85 02关闭诊断故障代码更新
22	[DID] 通过DID标识读数据	22 01 00 读取配置信息 62 01 00 后续跟0100对应变量定义的字节大小，16字节。
2E	[DID NewVal] 通过DID标识写数据	2E 01 00后续必须跟16字节 写配置信息 6E 01 00
14	[GroupOfDTC] DTC/0xFFFFFF 清除诊断信息，通过DTC标识清除相应故障记录	14 31 74 01 清除电驱控制器硬件故障 ECU删除快照队列中该DTC相关的快照并将故障状态位置为0 肯定响应 54
19	[FID] 0x01，0x02，0x03，0x04，0x0A 读故障信息，按故障状态选读取想要的故障	19 01报告DTC数目 19 02 01/08/09报告当前故障/历史故障/当前和历史的DTC以及DTC状态 19 03 返回所有已存储的DTC快照记录的DTC快照信息标志 19 04 输出所有服务器存储的DID快照数据
31	[RCT] 0x01 0x02 0x03 例程控制，启动或停止例程，获取例程结果	31 01/02/03 RID 71 01/02/03 RID [额外的记录]

刷写流程中体现的例程如下表：

0x0202	校验
0xFF01	检查编程一致性
0x0203	检查编程预条件

帧格式

在ISO 15765-2中对于网络层协议数据单元N_PDU有4种类型，分别为单帧SF、首帧FF、连续帧CF、流控帧FC，并且在帧格式上区分CAN和CANFD。

可参考：

单帧、首帧、续帧、流控帧-手把手分析报文

https://zhuanlan.zhihu.com/p/657883665

简单介绍以及示例：

单帧（数据内容长度<=7字节）

示例：

19AB06F4         CAN Frame   Rx   8     04 31 01 FF 01 AA AA AA

意义：诊断仪以物理寻址方式向ECU请求31服务，报文长0x04字节，内容为：31 01 FF 01，诊断仪的CAN报文填充码为0xAA。

19ABF406        CAN Frame   Rx   8     05 71 01 FF 01 04 CC CC

意义：ECU以物理寻址方式向诊断仪响应31服务，05-报文长度（字节）内容：0x71=0x31+0x40为31服务的肯定响应，子功能及RID:01 FF 01，routineStatusRecord 例程状态记录：04，CC-填充码，ECU的CAN报文内未定义的数据填充为CC。

多帧：首帧-流控帧-连续帧-流控帧

可以看出，发送端想把多帧数据发送给接收端，分为以下几步：

1.首帧发送： 发送端构建首帧，其中包括数据总长度和诊断服务标识符等信息。首帧中还包含了第一个小块数据。然后，发送首帧到接收端。

1X XX 首帧（X XX代表FF_DL数据长度信息），后续字节自动填充。

示例见步骤5之后。

2.等待流控制帧： 接收端收到首帧后，常紧跟在首帧之后发送流控制帧，用于控制发送方的发送速率及确认其准备好接收更多数据，但具体发送时机取决于接收方的处理能力和网络状态。报文包括接收端可以接受的连续帧数量。发送端需要等待流控制帧以确定可以继续发送多少连续帧。

示例-Flasher刷写hex（CANape Trace观测）：

19ABF406         CAN Frame   Rx   8     30 24 01 CC CC CC CC CC 

解读：

(1)地址：4字节 前2字节为UDS地址||第3字节：发送方||最后1字节：接收方

UDS物理地址(0x19AB) UDS功能地址(0x19AD)

控制器物理地址：0xF4  诊断仪物理地址：0x06

综上，ECU以物理寻址的方式向诊断仪发送UDS报文。

(2)流控帧:30 24 01

0x30：3：该报文为流控帧。0：流状态为继续发送。

0x24：允许一次连续发送连续帧的数量为0x24=36。

0x01：STmin = 1，发送方在发送连续帧时，必须在每发送一个连续帧后等待至少 1 毫秒。

3.连续帧发送： 根据流控制帧中指示的可接受连续帧数量，发送端构建连续帧并发送到接收端。每个连续帧都包含下一个小块数据。

2X 续帧（X代表SN序号信息）

注意： 首次续帧是0x21【原因：数据传输中，首帧SF数据作为第一个数据传输序列号SN为0】

最多16个续帧，溢出后从0重新开始。测试中，若续帧数量达到2F后仍有没有发完的续帧，则循环从20开始发送剩余的续帧报文。

4.重复步骤 2 和 3： 连续帧的发送过程会重复，直到所有小块数据都被发送完毕。（根据流控帧的参数也可以一直重复3）

5.数据重组： 接收端接收到连续帧后，会将这些小块数据重新组合成原始的较长数据。

以31 服务为例结合各帧格式解读：

69.713596     CAN 4    19AB06F4          CAN Frame   Rx   8     10 08 31 01 02 02 B1 D6

意义：诊断仪以物理寻址方式向ECU发送请求报文。

首字节1X 代表是首帧，0x008代表数据长度为8字节，接下来是数据内容。

SID = 0x31，FID = 0x01，代表31服务启动例程。RID = 02 02，代表是校验例程。剩下四字节包括：首帧中的B1 D6，连续帧的81 BB，为启动该例程的额外参数。

69.714200     CAN 4    19ABF406         CAN Frame   Rx   8     30 FF 01 00 00 00 00 00

意义：ECU以物理寻址方式向诊断仪发送流控帧。

首字节3X代表流控帧，0表示流状态为继续发送，0xFF表示允许一次连续发送连续帧的数量为0xFF=255，0x01表示 STmin = 1，即，发送方在发送连续帧时，必须在每发送一个连续帧后等待至少 1 毫秒。

69.716206     CAN 4    19AB06F4         CAN Frame   Rx   8     21 81 BB 00 00 00 00 00

意义：诊断仪以物理寻址方式向ECU发送连续报文。

2X 代表连续帧，此处0x21代表连续帧的第1个报文，数据内容太是88 8B。

69.716996     CAN 4    19ABF406          CAN Frame   Rx   8     05 71 01 02 02 00 00 00

意义：ECU以物理寻址方式向诊断仪响应报文。

首字节非1x非2x非3x，这里是单帧，05表长度，内容为：71 01 02 02 00，71 01 02 02代表31服务请求校验例程启动得到了肯定响应，00代表routineStatusRecord例程状态记录。

刷写流程报文自上而下解读：

可参考：UDS（十）应用层 34/36/37_uds 34服务-CSDN博客

在用上位机刷写hex文件时可以读取到的报文内容如下。

1.数据下载和校验

注意：在UDS刷写流程中，34（RequestDownload）、36（TransferData）、37（RequestTransferExit）三个服务主要负责数据段传输，而程序段（即固件在ECU中的实际写入过程）的物理刷写操作在服务层面通常不会直接体现。

0x34 请求下载0x00000032B的数据到内存逻辑地址0x802D5D00处。

0x36 数据传输

图片左为刷写图片右侧hex对应的EOL文件时canape观测到的报文，可见在刷写数据段时，传输的数据内容即hex内容。（但不包括未定义的内容，这在hex显示为04 00）

0x36结束，得到肯定响应

0x37服务用于退出上传下载，即诊断仪通过该诊断服务停止与ECU之间的数据传输。如果之前的34和36服务都顺利执行完成，那么37服务就可以得到ECU的positive response。否则ECU会负响应NRC 0x7F 37 24，表示诊断序列执行有错误。

0x37和0x34、0x31校验的次数是相同的。

2.后续

31 -11 -10 – 28 – 85 – 10 - 14

log文件解析

canape上报文与log中报文的差异

在《刷写报文解析》的基础上，可以很容易理解log文件，因为我们关注的地方是不变的。

需要注意的是，在UDS诊断服务中，通常使用ISO 15765-2（也称为ISO-TP）作为传输层协议。ISO-TP的作用是将较长的UDS消息分割成适合CAN总线传输的小帧（CAN标准帧的最大数据负载为8字节）。因此，在实际通信中，每个UDS报文会被分割成多个CAN帧，并通过ISO-TP进行重组。而日志记录格式日志文件中的报文可能包含了额外的信息，例如：时间戳、序列号或其他元数据。特定设备或工具（如VCI诊断仪）添加的额外字段（比如aa和55），用于调试或追踪。日志文件中显示的是完整的UDS报文（经过ISO-TP重组后的结果），而不是单独的CAN帧。

综上，CAN报文在log文件与canape观测的差异来源：

1. ISO-TP的分帧与重组。
2. 日志工具对原始数据的扩展和解析。
3. 诊断仪特定的标识符。

观察启动刷写EOL时的报文，可以得出以下结论：

1.aa和55是可能是诊断仪自定义的标识符，用于区分发送和接收方向。aa…55代表诊断仪是发送方，反之55…aa代表其为接收方，报文中的地址也可以佐证这一点。

2.第二字节固定为00；

3.第三子节为报文的数据内容的长度；

07:52:17.291: 启动有线通信控制器服务器线程

07:52:18.713: 无线通信控制器上线 IP:xx句柄:xx

07:52:19.731: 设置CAN线可配置引脚

07:52:19.731: 准备发送网络数据

07:52:19.731: 发送至通信控制器 aa 00 05 01 29 10 1b 55 55

07:52:19.731: 设置响应报文       55 00 04 01 29 10 00 AA

可以借助带下划线的文字注释了解CAN总线上进行的设置，报文中的数据内容用加粗体现。

阅读UDS报文信息时，为快速了解故障点，只需要关注在哪里发生了否定响应，响应码是什么，然后根据规范文件检查是否是请求顺序、请求格式、请求内容发生错误。

所以，可以尝试在文件中搜索7F，不过如果是在刷写EOL过程中遇到问题，难以由于自身操作造成错误，可能重启诊断仪多试几次就好了。（刷写过程遭遇错误，诊断仪会从头再试一次，报错后停止。）

10 03->31 01 02 03->85 02 ->28 03 03-> 10 02->27 09 –>27 0A

我们可以忽略地址之前的部分，直接看报文。可以认为，地址后固定为0x08 ,随后的是报文内容，比如单帧的：02 3E 00，05 71 01 02 03 00，连续帧的21 6A BB……

aa 00 14 43 4b 10 19 AB 06 f4 08 04 31 01 ff 01 00 00 00 00 00 00 00 55 

2E -> 31 -> 34 -> 36 -> 37 ->到31重复该过程直到完成所有数据的传输与下载

31 -11 -10 – 28 – 85 – 10 - 14