36服务刷写完成后如何通过响应码判断？

Question

在基于UDS（统一诊断服务）的ECU刷写过程中，36服务（请求下载）执行后，如何通过响应码准确判断操作结果？常见问题包括：响应码0x78表示成功等待后续操作，而0xXX中的否定响应码如0x22、0x31、0x13等分别代表条件不满足、编程条件未达成或写入失败。实际应用中，若未正确解析响应码，可能导致刷写流程中断或误判。如何结合P2服务器时间与响应码进行状态判断，是确保后续37服务（传输数据）顺利执行的关键。

Answer 1

基于UDS的ECU刷写中36服务响应码解析与状态判断机制

1. UDS 36服务（请求下载）基础概念

在统一诊断服务（Unified Diagnostic Services, UDS）标准ISO 14229-1中，服务ID为0x36的服务称为“请求下载”（Request Download）。该服务用于启动从诊断工具向电子控制单元（ECU）传输固件数据的流程。执行此服务后，ECU会返回一个响应报文，其中包含服务确认状态和可能的附加信息。

响应格式通常如下：

• 正响应：0x76 + 地址和长度格式标识符 + 最大块长度（可变字节）
• 负响应：0x7F + 0x36 + 否定响应码（NRC）

例如，若ECU准备就绪并允许下载，则返回0x76开头的正响应；否则返回0x7F 0x36 NRC的形式。

2. 常见响应码及其含义解析

准确理解响应码是确保刷写流程顺利推进的前提。以下是常见的响应码分类及实际意义：

响应码（Hex）	类型	含义	典型场景
0x00	正响应	成功，进入数据传输阶段	ECU已准备好接收数据
0x78	待定响应（Pending）	处理中，需等待后续响应	内部初始化耗时较长
0x22	否定响应	条件不满足（Conditions Not Correct）	未进入编程会话或安全访问未解锁
0x31	否定响应	请求超出范围（Request Out Of Range）	地址或长度非法
0x13	否定响应	写入失败（Write Error）	Flash写保护未关闭或硬件故障
0x24	否定响应	请求序列错误（Invalid Format）	参数编码不符合规范
0x12	否定响应	子功能不支持	子功能字段值无效
0x33	否定响应	安全访问拒绝	未通过Seed-Key认证
0x27	否定响应	安全访问次数超限	连续尝试密钥失败
0x10	否定响应	通用拒绝	未明确原因的拒绝

3. 响应码0x78的特殊处理机制

当ECU返回0x78（即“pending”状态）时，表示其正在内部准备资源（如擦除Flash、配置DMA通道等），尚未完成初始化。此时不应立即发送37服务（传输数据），而应启动P2服务器定时器进行等待。

P2* timer定义了从请求发出到收到完整响应的最大允许时间。对于0x78响应，需启用P2*扩展时间（Extended P2 Server Timeout），其值由ECU动态提供或预设于诊断配置文件中。

// 示例：C语言伪代码判断0x78响应并延时处理
if (response[0] == 0x7F && response[1] == 0x36 && response[2] == 0x78) {
    uint32_t extended_p2_time = get_extended_p2_timeout(); // 单位ms
    sleep_ms(extended_p2_time);
    retry_request_download();
}

4. 结合P2服务器时间的状态机设计

为了稳健地处理各种响应情况，建议采用有限状态机（FSM）模型管理36服务后的流程控制。以下使用Mermaid语法描述该逻辑：

stateDiagram-v2 [*] --> Send_RequestDownload Send_RequestDownload --> Check_Response Check_Response --> Positive: If NRC=0x00 or pending handled Check_Response --> Wait_Pending: If NRC=0x78 Wait_Pending --> Check_Response: After P2* timeout Check_Response --> Negative: If NRC != 0x00 Negative --> Handle_Error Handle_Error --> Retry_OR_Abort Positive --> Proceed_to_37_Service

5. 实际应用中的典型问题分析

1. 误判0x78为失败：部分开发者将0x78视为错误，直接终止流程，导致刷写失败。正确做法是识别该码并等待P2*超时后再重试或继续。
2. P2时间设置不合理：若P2过短，可能在ECU未完成准备前就判定超时；过长则影响整体刷写效率。建议根据ECU型号实测典型准备时间，并留出20%余量。
3. 忽略安全访问依赖：许多ECU要求在编程会话+安全访问解锁后才允许36服务。未执行27服务可能导致持续返回0x22或0x33。
4. 地址/长度越界：传递的内存地址不在允许范围内，或数据长度超过单次最大传输块限制，引发0x31错误。
5. Flash驱动未初始化：某些MCU需显式调用底层API开启编程模式，否则即使协议层合规也会返回0x13。
6. 多核同步问题：在多核ECU中，主核执行36服务时，从核仍在运行任务，造成资源冲突。
7. Bootloader版本兼容性：旧版Bootloader对新格式SREC/BIN支持不足，导致解析失败。
8. 通信总线负载过高：CAN总线拥堵可能导致响应延迟超过P2，被误判为无响应。
9. 电源不稳定：低电压下Flash操作易失败，表现为间歇性0x13错误。
10. 未清除历史错误标志：之前刷写残留的错误状态未清零，影响当前流程。

6. 解决方案与最佳实践

针对上述问题，提出以下工程级解决方案：

• 建立完整的NRC映射表，并集成至诊断库中，实现自动翻译与日志记录。
• 引入自适应P2机制：首次使用默认值，后续根据实测响应时间动态调整。
• 在请求下载前强制执行会话切换（10服务）与安全访问（27服务）校验。
• 添加地址合法性检查模块，验证目标区域是否属于可编程段（如App区域而非Boot区）。
• 使用双缓冲机制提升数据吞吐效率，在等待P2期间预加载下一块数据。
• 增加异常恢复策略：如遇0x78多次重复，尝试复位ECU或重启通信链路。
• 启用调试日志输出，捕获完整CAN帧序列以便离线分析。
• 实施分级超时机制：P2_normal用于常规响应，P2_extended专用于pending状态。