UDS 协议中 0x34 服务（Request Download）详解
一、0x34 服务概述
作用：启动从诊断设备到 ECU 的数据传输，主要用于固件升级（FOTA）或大块数据写入。
使用场景：ECU 需切换至编程会话（0x02）并通过安全访问（0x27）解锁后，方可执行该服务。
二、请求报文格式（Tester → ECU）
| 参数 | 字节长度 | 含义 | 示例值 |
|---|---|---|---|
| SID | 1 Byte | 服务标识符，固定为 0x34 | 0x34 |
| DFI（DataFormatIdentifier） | 1 Byte | 高 4 位：压缩方法（0 = 无压缩）；低 4 位：加密方法（0 = 无加密） | 0x00 |
| ALFID（AddressAndLengthFormatID） | 1 Byte | 高 4 位：MemorySize 的字节数（n）；低 4 位：MemoryAddress 的字节数（m） | 0x44（m=4, n=4） |
| MemoryAddress | m Bytes | 数据写入的起始地址（大端序，MSB 在前） | 0x0800_0000 |
| MemorySize | n Bytes | 待传输数据的总字节数（未压缩大小） | 0x0001_0000（64KB） |
示例报文：
34 00 44 08 00 00 00 00 01 00 00
含义：向地址 0x08000000 写入 64KB 数据，无压缩加密，地址和长度各占 4 字节。
三、响应报文格式（ECU → Tester）
1. 肯定响应（0x74）
| 参数 | 字节长度 | 含义 | 示例值 |
|---|---|---|---|
| SID+0x40 | 1 Byte | 响应标识符，固定为 0x74（0x34 + 0x40） | 0x74 |
| LFID（LengthFormatID） | 1 Byte | 高 4 位：MaxBlockLength 的字节数；低 4 位：保留（固定 0） | 0x20 |
| MaxBlockLength | 可变长度 | 单次传输（0x36 服务）允许的最大数据块大小（含协议开销） | 0x0402（1026 字节） |
注：实际有效数据量 = MaxBlockLength - 2（扣除 0x36 服务的帧序号占 2 字节）。
示例响应：
74 20 04 02
含义：允许每次传输最大 1026 字节（实际数据 1024 字节）。
2. 否定响应（0x7F）
常见否定响应码（NRC）：
-
0x13：报文长度错误（参数缺失）
-
0x22：条件不满足（如未预擦除内存）
-
0x31：参数无效（地址 / 长度超范围）
-
0x33：安全访问未解锁
-
0x70：内存写入失败（如地址只读）
四、通信流程与关键机制
分块传输机制
-
ECU 通过
MaxBlockLength控制每次 0x36 服务的数据量（例如 1024 字节 / 包）。 -
诊断设备需按此分块发送数据，最后一块可小于最大值。
完整性校验
-
ECU 比较
MemorySize与实际传输总量，确保数据完整。 -
传输结束需调用 **0x37 服务（RequestTransferExit）** 提交校验。
安全设计
-
内存地址可包含标识符（如 0x08 表示 Flash），防止地址冲突。
-
必须通过 0x27 服务解锁高安全等级（Level 3）才能写入关键区域。
五、实际应用案例
场景：更新 64KB 固件到 ECU Flash（起始地址 0x08000000）。
-
请求下载：
34 00 44 08 00 00 00 00 01 00 00（地址 8 字节，长度 4 字节） -
ECU 响应：
74 20 04 02（允许 1026 字节 / 包，含 2 字节头） -
数据传输：
分 64 包发送（每包 1024 字节 + 0x36 帧头），最后调用 0x37 服务结束传输并校验。分 64 包发送（每包 1024 字节 + 0x36 帧头），最后调用 0x37 服务结束传输并校验。
六、配置注意事项
地址对齐
- 内存地址需符合 ECU 的写入对齐要求（如 4 字节对齐）。
内存保护
-
确保目标区域可写（非 Bootloader 保护区）。
-
提前执行擦除操作（0x31 服务触发擦除例程）。
超时设置
- 传输过程中需配置
P2*_Timeout（建议≥5000ms），避免网络延迟导致中断。
UDS 协议中 0x36 服务（Transfer Data）详解
一、服务概述
0x36 服务（Transfer Data）是 UDS 协议中负责数据分块传输的核心服务，主要用于在诊断设备和 ECU 之间传输大量数据，配合 0x34 服务使用。在 ECU 通过 0x34 服务确认数据传输参数（如地址、长度、块大小）后，诊断设备通过 0x36 服务按指定块大小向 ECU 发送数据。
二、请求报文格式（Tester → ECU）
| 参数 | 字节长度 | 含义 | 示例值 |
|---|---|---|---|
| SID | 1 Byte | 服务标识符，固定为 0x36 | 0x36 |
| BlockSequenceNumber | 1 Byte | 块序号，用于标识数据块的顺序，初始值为 0，每发送一块递增 1 | 0x00（第一块），0x01（第二块） |
| DataBlock | 可变长度 | 实际传输的数据块，长度不超过 0x34 服务响应中指定的MaxBlockLength - 2
| 若MaxBlockLength为 1026 字节，则 DataBlock 最长 1024 字节
|
示例报文：
36 00 41 42 43 ...（第一块，块序号 0x00，数据部分示例为41 42 43 ...）
36 01 44 45 46 ...（第二块，块序号 0x01，数据部分示例为44 45 46 ...）
三、响应报文格式（ECU → Tester）
1. 肯定响应（0x76）
| 参数 | 字节长度 | 含义 | 示例值 |
|---|---|---|---|
| SID+0x40 | 1 Byte | 响应标识符，固定为 0x76（0x36 + 0x40） | 0x76 |
| BlockSequenceNumber | 1 Byte | 确认接收的数据块序号，与请求报文中的序号一致 | 与请求报文序号相同，如 0x00 |
示例响应：
76 00（确认接收块序号为 0x00 的数据块）
2. 否定响应（0x7F）
常见否定响应码（NRC）：
-
0x13：报文长度错误（数据块超出指定大小）
-
0x24：条件不满足（如 ECU 未准备好接收数据）
-
0x72：故障处于活动状态（传输过程中 ECU 检测到故障）
四、数据传输机制
块序号管理
诊断设备按顺序递增块序号发送数据，ECU 通过响应中的序号确认接收顺序，若序号不连续或重复，ECU 将返回否定响应。
流控制
部分场景下，若 ECU 处理速度跟不上数据接收速度，会通过否定响应或其他机制（如 ISO-TP 协议流控制）要求诊断设备暂停或调整发送速率。
最后一块标识
诊断设备发送最后一块数据时，可通过设置特殊标志（如块序号达到最大值）或结合数据长度判断，通知 ECU 数据传输即将结束。
五、与 0x34 服务的协同关系
0x34 服务为数据传输做准备，确定传输的基本参数；0x36 服务则负责实际的数据分块发送。两者配合实现完整的数据传输流程：
-
诊断设备发送 0x34 服务请求，ECU 返回允许的
MaxBlockLength。 -
诊断设备按
MaxBlockLength分块，通过 0x36 服务依次发送数据。 -
数据传输完成后，调用 0x37 服务提交校验，确认传输成功。
UDS 协议中 0x37 服务（Request Transfer Exit）详解
一、服务概述
0x37 服务（Request Transfer Exit）用于在数据传输完成后，由诊断设备向 ECU 发送请求，通知 ECU 数据传输已结束，并触发 ECU 进行数据完整性校验和后续处理。它是 0x34、0x36 服务流程中的收尾环节，确保数据传输的完整性和可靠性。
二、请求报文格式（Tester → ECU）
| 参数 | 字节长度 | 含义 | 示例值 |
|---|---|---|---|
| SID | 1 Byte | 服务标识符，固定为 0x37 | 0x37 |
示例报文：
37
三、响应报文格式（ECU → Tester）
1. 肯定响应（0x77）
| 参数 | 字节长度 | 含义 | 示例值 |
|---|---|---|---|
| SID+0x40 | 1 Byte | 响应标识符，固定为 0x77（0x37 + 0x40） | 0x77 |
示例响应：
77
含义：ECU 确认接收到数据传输结束请求，且数据校验通过，准备进行后续操作（如写入 Flash、重启等）。
2. 否定响应（0x7F）
常见否定响应码（NRC）：
-
0x13：报文长度错误（不符合 0x37 服务格式要求）
-
0x24：条件不满足（如 ECU 尚未接收完所有数据）
-
0x72：故障处于活动状态（传输过程中出现未处理的故障，导致校验失败）
-
0x73：安全访问未解锁（若后续操作涉及敏感区域写入，需提前解锁）
四、与其他服务的协同流程
-
前置准备：诊断设备先通过 0x34 服务请求数据传输，获取 ECU 允许的最大数据块长度（
MaxBlockLength）。 -
数据传输：按
MaxBlockLength分块，使用 0x36 服务将数据逐块发送给 ECU，ECU 接收并缓存数据。 -
传输结束：诊断设备发送 0x37 服务请求，通知 ECU 数据已全部发送完毕。
-
校验与处理：ECU 接收到 0x37 请求后，对接收的数据进行完整性校验（如 CRC 校验），若校验通过，执行后续操作（如将数据写入目标内存区域、更新固件版本号）；若校验失败，返回否定响应并附带错误码。
五、实际应用注意事项
数据校验依赖
ECU 对数据的校验方式（如 CRC 算法、校验范围）需与诊断设备预先约定，确保双方对数据完整性判断一致。
操作权限管理
若 0x37 服务触发的后续操作（如固件写入）涉及敏感区域，需确保 ECU 已通过安全访问（0x27 服务）解锁相应权限。
超时处理
诊断设备发送 0x37 请求后，需设置合理的超时时间等待 ECU 响应，若超时未收到肯定回复，需重新检查传输过程或发起重试机制。
通过合理使用 0x34、0x36、0x37 服务，可在 UDS 协议框架下构建完整、可靠的 ECU 数据传输与更新流程，满足汽车电子系统固件升级、参数配置等多种应用需求。
扫一扫
3285
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
