UDS 0x34服务详解：ECU刷写流程的数据传输握手协议

UDS协议ECU刷写0x34服务

于 2026-08-01 03:53:31 修改

·本内容遵循CC 4.0 BY-SA版权协议

在汽车电子和嵌入式开发领域，UDS（Unified Diagnostic Services，统一诊断服务）协议是实现车辆诊断、ECU（电子控制单元）刷写和故障排查的核心标准。其中，刷写服务（Programming Session）是UDS协议中最复杂也最关键的环节之一，它直接关系到ECU固件的更新、功能升级和售后维护。而0x34服务（RequestDownload，请求下载）作为刷写流程的起点，负责协商数据传输的参数，其正确配置是整个刷写成功的前提。

本文面向汽车电子工程师、嵌入式软件开发者、诊断工具开发人员以及相关领域的技术爱好者，旨在深入解析UDS 0x34服务的协议细节、工作流程和实际实现。文章将从一个完整的刷写会话切入，详细讲解0x34服务的请求响应格式、关键参数含义、常见错误码（NRC）处理，并给出基于CAN总线（ISO-TP）的具体代码示例和调试方法。通过本文，读者将掌握如何正确构造0x34请求、处理ECU响应，并能够独立排查刷写初始化阶段的典型问题。

1. 理解UDS刷写服务的基本流程和0x34服务的位置

1.1 UDS刷写会话的整体脉络

UDS刷写不是一个单一服务，而是一个严谨的序列化操作。它通常遵循以下基本阶段：

会话控制（0x10服务）：首先需要从默认会话（Default Session）切换到编程会话（Programming Session，通常子功能为0x02）。编程会话会启用一系列高权限服务，并为刷写做好ECU内部准备（如关闭正常通信、初始化内存管理）。
安全访问（0x27服务）：出于安全考虑，刷写操作通常被锁定，需要通过种子-密钥（Seed-Key）算法完成身份认证，解锁刷写权限。
通信控制（0x28服务）：可选步骤，用于控制ECU的常规通信（如关闭非诊断报文），确保总线带宽用于刷写数据传输。
例程控制（0x31服务）：常用于执行特定的预刷写检查或准备工作，如检查编程依赖条件、擦除Flash内存等。
请求下载（0x34服务）：本文核心。在此阶段，诊断工具（Tester）向ECU发起下载请求，告知即将传输的数据大小、内存地址格式和地址长度。ECU确认参数有效后，准备接收数据。
传输数据（0x36服务）：将固件数据分块发送给ECU。
请求退出传输（0x37服务）：数据发送完毕后，通知ECU传输结束。
例程控制（0x31服务）：再次调用，执行刷写后的校验操作，如校验和验证或完整性检查。
会话控制（0x10服务）：切换回默认会话，完成整个刷写流程。

0x34服务正处于整个流程的“临门一脚”位置，它搭建起了诊断工具与ECU之间数据传输的“桥梁”。如果0x34请求的参数不被ECU接受，后续的数据传输（0x36）将无法进行。

1.2 0x34服务（RequestDownload）的核心作用

0x34服务本质上是一个数据传输的“握手”协议。它的主要目的有三个：

协商数据格式：明确后续传输的数据块大小、内存地址的表示方式（是32位地址还是24位地址）以及内存地址本身的长度。
资源预留：ECU在收到合法的0x34请求后，会在内部为即将到来的数据流分配缓冲区等资源。
错误预防：通过在传输开始前检查参数的有效性（如地址是否可写、数据大小是否合理），避免在数据传输中途因参数错误而导致整个流程失败，节省时间和总线资源。

2. 深入解析0x34服务的请求与响应报文

2.1 请求报文（Request Message）结构拆解

一个完整的0x34服务请求报文遵循以下结构：

字节位置	参数名	描述	示例值	解释
0	SID	服务标识符	0x34	固定表示RequestDownload服务。
1	dataFormat	数据格式标识	0x00	高4位表示地址和长度格式标识符，低4位保留（通常为0）。
2	addressAndLengthFormat	地址和内存大小格式	0x44	这是一个关键字节。它被分为两个半字节（nibble）：高4位表示内存地址参数的长度（字节数），低4位表示内存大小参数的长度（字节数）。示例0x44表示地址长度=4字节，内存大小长度=4字节。
3-6	memoryAddress	目标内存地址	0x0800 0000	根据第2字节高4位指定的长度，这里是4字节地址。例如，STM32系列MCU的Flash起始地址常为0x08000000。
7-10	memorySize	要传输的数据总大小	0x0001 0000	根据第2字节低4位指定的长度，这里是4字节大小。例如，表示要下载64KB（0x10000字节）的数据。

关键参数 addressAndLengthFormat 详解：

这个字节的编码规则是：[地址长度-1] << 4 | [内存大小长度-1]。

如果你想用4字节表示地址，那么 地址长度-1 = 4-1 = 3 (0x3)。
如果你想用4字节表示内存大小，那么 内存大小长度-1 = 4-1 = 3 (0x3)。
组合起来：0x3 << 4 | 0x3 = 0x30 | 0x03 = 0x33。

所以，如果你的ECU要求使用4字节地址和4字节内存大小，正确的格式字节应该是 0x33，而不是示例中的 0x44。0x44 对应的是5字节地址和5字节内存大小，这在实践中非常罕见。务必与ECU的诊断规范严格保持一致。

一个典型的请求报文示例（十六进制流）： 34 00 33 08 00 00 00 00 01 00 00

34: SID
00: dataFormat (通常为0)
33: addressAndLengthFormat (4-byte addr, 4-byte size)
08 00 00 00: memoryAddress = 0x08000000
00 01 00 00: memorySize = 0x00010000 (64KB)

2.2 肯定响应报文（Positive Response Message）

如果ECU接受下载请求，它会回复一个肯定响应：

字节位置	参数名	描述	示例值
0	RSID	响应服务标识符	0x74 (0x34 + 0x40)
1	lengthFormatIdentifier	长度格式标识符	0x20
2	maxNumberOfBlockLength	最大块长度	可变

lengthFormatIdentifier：这个字节同样编码了信息。高4位表示maxNumberOfBlockLength参数本身的字节数（通常为1或2），低4位保留（通常为0）。例如，0x20表示maxNumberOfBlockLength用2字节表示。
maxNumberOfBlockLength：这是ECU允许你在后续0x36服务中单次传输的最大数据块大小（字节数）。例如，0x0400表示1024字节。诊断工具在发送0x36服务时，每个数据块不能超过这个值。

一个典型的肯定响应示例： 74 20 04 00

74: RSID
20: lengthFormatIdentifier (2-byte max block length)
04 00: maxNumberOfBlockLength = 0x0400 = 1024 bytes

2.3 否定响应码（Negative Response Code, NRC）及处理

如果请求参数有问题，ECU会回复否定响应（SID=0x7F, 0x34, NRC）。常见的NRC及其含义如下：

NRC值	助记符	含义	可能原因和排查方向
0x13	incorrectMessageLengthOrInvalidFormat	报文长度不正确或格式无效	检查请求报文总长度是否符合ECU规范，特别是`addressAndLengthFormat`字节与后续地址、大小参数的长度是否匹配。
0x22	conditionsNotCorrect	条件不满足	最常见的原因之一。ECU未处于编程会话（0x10 02），或安全访问未解锁（0x27）。检查当前会话状态和安全等级。
0x31	requestOutOfRange	请求超出范围	请求的`memoryAddress`不可写（如地址非法、受保护），或`memorySize`太大（超过可用空间）。核对ECU的内存映射表。
0x33	securityAccessDenied	安全访问被拒绝	安全访问未通过或已超时。重新执行0x27服务。
0x72	generalProgrammingFailure	常规编程错误	ECU内部在准备下载时发生错误，可能是Flash驱动初始化失败、硬件错误等。需要查看ECU内部日志。

3. 基于CANoe/CANalyzer或SocketCAN的实战示例

3.1 环境与工具准备

硬件：带有CAN接口的PC（如PCMCIA卡、USB-CAN适配器）或虚拟CAN环境（vcan）。
ECU/模拟器：真实的ECU硬件、CANoe/CANalyzer的CAPL模拟节点、或运行在开发板（如STM32）上的UDS服务端程序。
软件：
- 商用工具：Vector公司的CANoe或CANalyzer，配合CAPL脚本。
- 开源方案：Linux下的can-utils工具集（cansend, candump）、Python的python-can库、或C/C++的SocketCAN编程。

3.2 使用CAPL脚本发送0x34请求

以下是一个在CANoe/CANalyzer中用于发送0x34请求的CAPL脚本示例。

// 定义消息和变量

variables

{

message 0x731 msg_uds_req; // 假设物理请求ID为0x731

byte request_data[11];

}

// 在某个事件（如按钮按下）中调用此函数

on key 'a'

{

// 构建 0x34 请求报文：下载64KB数据到地址0x08000000

request_data[0] = 0x34; // SID

request_data[1] = 0x00; // dataFormat

request_data[2] = 0x33; // addr和size均为4字节 (0x33 = 4-1<<4 | 4-1)

// 地址 0x08000000 (大端序或Intel小端序取决于ECU，通常为大端序)

request_data[3] = 0x08;

request_data[4] = 0x00;

request_data[5] = 0x00;

request_data[6] = 0x00;

// 大小 0x00010000 (64KB)

request_data[7] = 0x00;

request_data[8] = 0x01;

request_data[9] = 0x00;

request_data[10] = 0x00;

// 将数据赋值给CAN消息并发送

msg_uds_req.dlc = 11; // 数据长度

memcpy(msg_uds_req.data, request_data, 11);

output(msg_uds_req);

write("0x34 RequestDownload sent.");

}

3.3 使用Python-can库发送0x34请求

对于开源环境，可以使用Python进行演示。

PYTHON

import can

import time

# 配置CAN接口，例如 'can0' 对于SocketCAN

bus = can.interface.Bus(channel='can0', bustype='socketcan')

def send_uds_request(arbitration_id, data):

"""发送UDS请求的辅助函数"""

message = can.Message(arbitration_id=arbitration_id, data=data, is_extended_id=False)

try:

bus.send(message)

print(f"Message sent: {data.hex()}")

except can.CanError:

print("Message NOT sent")

# 假设ECU物理请求ID为0x731

tester_id = 0x731

ecu_id = 0x739 # ECU的响应ID

# 构建 0x34 请求数据 (4字节地址，4字节大小)

request_data = [

0x34, # SID

0x00, # dataFormat

0x33, # addr和size均为4字节

0x08, 0x00, 0x00, 0x00, # Address: 0x08000000

0x00, 0x01, 0x00, 0x00 # Size: 0x00010000 (64KB)

]

# 发送请求

send_uds_request(tester_id, request_data)

# 监听响应（简单示例，实际应用需要更复杂的消息过滤和处理循环）

while True:

response = bus.recv(timeout=2.0) # 等待2秒

if response is None:

print("Timeout, no response received.")

break

if response.arbitration_id == ecu_id:

print(f"Response received: {response.data.hex()}")

# 解析响应

if response.data[0] == 0x74: # 肯定响应

print("Positive Response for 0x34")

lfi = response.data[1]

# 解析最大块长度

if lfi == 0x20: # 2字节长度

max_block_len = (response.data[2] << 8) | response.data[3]

print(f"Max number of block length: {max_block_len} bytes")

break

elif response.data[0] == 0x7F and response.data[1] == 0x34: # 否定响应

nrc = response.data[2]

print(f"Negative Response Code (NRC): 0x{nrc:02X}")

break

bus.shutdown()

4. 0x34服务实战中的关键要点与排错指南

4.1 参数配置的常见陷阱

地址和大小格式字节错误：这是最容易出错的地方。务必根据ECU规范计算正确的addressAndLengthFormat值。使用4字节地址和4字节大小是最常见的组合，对应数值0x33。
字节序问题：UDS协议通常使用大端序（Big-Endian，高位字节在前）。确保你的工具或代码在构造地址和大小参数时使用了正确的字节序。有些ECU也可能使用小端序，必须与供应商确认。
内存地址有效性：请求的起始地址必须是对应ECU内存映射中允许写入的地址（如Flash的编程区域）。向Bootloader区域或只读区域写入会导致NRC 0x31。
数据大小超限：请求的memorySize必须与实际要传输的固件文件大小完全一致，且不能超过目标地址空间的大小。

4.2 典型问题排查路径

当0x34请求被否定响应时，可以按照以下顺序排查：

问题现象（NRC）	优先检查项
0x22 (ConditionsNotCorrect)	1. 使用0x10 03（扩展诊断会话）或0x10 02（编程会话）了吗？ 2. 使用0x3E服务保持会话了吗？会话是否超时？ 3. 0x27安全访问成功了吗？密钥计算是否正确？是否超时？
0x31 (RequestOutOfRange)	1. 请求的内存地址是否在ECU规格书定义的可编程地址范围内？ 2. 数据大小是否超过了剩余Flash空间？ 3. 该内存区域是否有写保护（需先通过0x31服务解除）？
0x13 (IncorrectMessageLength)	1. 整个请求报文的长度是否正确？`addressAndLengthFormat`声明的地址长度+内存大小长度+3（SID,dataFormat,FormatByte）是否等于DLC？ 2. 报文数据是否对齐到8字节？是否需要ISO-TP多帧传输？

4.3 调试与验证建议

使用诊断控制台：像CANoe/CANalyzer、Peak CANape等工具提供了强大的诊断控制台，可以图形化地配置和发送UDS服务，并自动解析响应，是初期验证和学习的利器。
开启ECU内部日志：如果可能，让ECU端输出详细的调试日志，记录它如何处理0x34请求，以及为什么返回特定的NRC。
分步验证：确保前序服务（0x10, 0x27）都返回了肯定响应，再尝试0x34服务。
核对ISO-TP通信：确认你的CAN驱动或协议栈正确实现了ISO-TP（ISO 15765-2）协议，能够处理单帧和多帧传输。0x34请求本身通常很短，用单帧即可，但后续的0x36服务几乎肯定需要多帧。

0x34服务是开启ECU刷写大门的钥匙。准确理解其协议格式，谨慎配置内存参数，并建立清晰的排错思路，是成功完成UDS刷写的基础。在掌握了0x34服务之后，下一步就是深入研究0x36数据传输服务，如何根据ECU返回的最大块长度，高效、可靠地将固件数据分块发送出去。