【UDS诊断实战】0x35 RequestUpload：从协议解析到车载数据上传的工程实践
1. 0x35 RequestUpload服务基础解析
第一次接触UDS诊断协议时，看到0x35这个服务编号确实有点懵。但实际在车载诊断中，RequestUpload就像是我们日常用的"文件传输助手"——它负责在ECU（电子控制单元）和诊断设备之间建立数据传输通道。比如当4S店需要更新你的车机系统时，技师电脑首先发出的就是这条指令。
这个服务的核心功能可以用快递场景来理解：
- 寄件人（客户端）：诊断设备发出"我要取件"请求
- 收件人（服务端）：ECU准备好待传输的数据包
- 快递单（报文）：包含取件地址、包裹大小等关键信息
在实际项目中，我经常用这个服务做两件事：
- ECU软件刷写时获取固件分区信息
- 故障诊断时读取ECU内部日志数据
2. 请求报文深度拆解
2.1 报文结构实战分析
先看一个真实案例中的请求报文示例：
# 读取ECU 0x08000000地址开始的1MB数据 request = [ 0x35, # SID 0x00, # 不压缩不加密 0x44, # 地址4字节/长度4字节 0x08, 0x00, 0x00, 0x00, # 内存地址 0x00, 0x10, 0x00, 0x00 # 数据长度(1MB) ]这里最关键的addressAndLengthFormatIdentifier参数（第3字节）就像快递单上的规格说明：
- 高4位(0x4)：表示后续memorySize占4字节
- 低4位(0x4)：表示memoryAddress占4字节
新手常踩的坑是：
- 地址/长度字节数计算错误（比如32位地址却只写了3字节）
- 大小端问题（ARM架构常用小端模式）
- 忘记包含内存标识符（多核ECU需要额外字节区分存储区域）
2.2 数据格式标识符的玄机
dataFormatIdentifier这个单字节参数实际上是个位掩码：
7 6 5 4 | 3 2 1 0 --------+-------- 压缩方法 | 加密方法最近帮客户调试时遇到个典型问题：他们用0x01表示"不压缩但AES加密"，结果ECU一直返回NRC_0x31（请求超出范围）。后来发现该车型的加密标识位实际是反着定义的。所以切记：
不同主机厂的位定义可能不同，一定要查阅具体车型的诊断规范
3. 响应报文处理技巧
3.1 肯定响应实战解码
收到肯定响应时，重点看这两个参数：
// 示例响应报文 0x75, // 响应SID 0x10, // 块长度占1字节 0x40 // 最大块长度64字节这里lengthFormatIdentifier的0x10表示：
- 高4位(1)：maxNumberOfBlockLength占1字节
- 低4位必须为0（协议强制要求）
maxNumberOfBlockLength=0x40意味着：
- 后续TransferData服务每次最多传输64字节
- 包括SID和校验等开销（实际数据可能只有60字节）
3.2 否定响应排查指南
去年调试新能源车VCU时，我整理过常见NRC的处理流程：
| NRC代码 | 触发场景 | 解决方案 |
|---|---|---|
| 0x13 | 报文长度错误 | 检查addressAndLengthFormatIdentifier |
| 0x22 | 已有上传会话 | 先执行0x37终止当前传输 |
| 0x31 | 地址越界 | 确认ECU内存映射表 |
| 0x33 | 安全认证未通过 | 先执行0x27安全解锁 |
| 0x70 | 存储介质故障 | 检查Flash状态 |
特别提醒：有些ECU在返回NRC_0x31时，会附带有效地址范围在附加数据里，这个信息对调试非常有用。
4. 工程实践中的高阶应用
4.1 多核ECU的特殊处理
在域控制器开发中，我们常遇到这样的内存布局：
0x00000000-0x00FFFFFF : Cortex-M4代码区 0x01000000-0x01FFFFFF : Cortex-A7共享内存这时RequestUpload需要这样构造：
request = [ 0x35, 0x00, 0x54, # 地址5字节（含1字节核标识） 0x01, # 核标识 0x00, 0x10, 0x00, 0x00, # 地址 0x00, 0x01, 0x00, 0x00 # 长度 ]4.2 大数据量分块传输
当读取100MB的日志数据时，建议采用分片策略：
- 先获取ECU支持的最大块长度（通常128-512字节）
- 分段发送RequestUpload（每次请求1-4MB）
- 用0x36 TransferData分块接收
- 最后用0x37 RequestTransferExit结束
这样做的优势：
- 避免单次传输超时
- 支持断点续传
- 降低内存占用
5. 典型故障案例分析
最近处理的一个棘手问题：某车型OTA升级失败，诊断仪显示NRC_0x22（条件不满足）。经过抓包分析发现：
异常流程：
- 发送RequestUpload → 成功
- 直接再次发送RequestUpload → 失败
根本原因：
- ECU要求在两个RequestUpload之间必须执行0x31 RoutineControl擦除操作
解决方案：
sequenceDiagram 诊断仪->>ECU: RequestUpload(初始化) ECU-->>诊断仪: 0x75(成功) 诊断仪->>ECU: 0x31(擦除Flash) ECU-->>诊断仪: 0x71(成功) 诊断仪->>ECU: RequestUpload(再次初始化) ECU-->>诊断仪: 0x75(成功)这个案例告诉我们：一定要仔细阅读厂商特定的诊断流程说明，协议标准只是基础，各家的实现可能有特殊要求。