第4章 ECU复位服务实现

4、ECU复位服务实现：请求与响应格式、正响应与负响应码(NRC)分析

好，咱们接着聊ECU复位。这个服务，说白了就是给ECU发一个「重启」指令。听起来简单吧？但实际项目中，我见过太多因为复位时序没处理好，导致ECU变砖的案例。嗯，咱们今天就把这个服务彻底讲透。

4.1 服务概述与ID

ECU复位服务，服务ID是 0x11。它的作用就是让ECU按照指定的方式重新启动。你想想看，ECU跑着跑着出了故障，或者刷完软件需要激活，这时候就需要它了。

我个人习惯把复位服务分成两类：物理复位和逻辑复位。物理复位就是真的断电再上电，逻辑复位则是软件层面的重启，比如跳转到Bootloader。

4.2 请求格式

请求报文很简单，就两个字节：

| 字节0 | 字节1 |
|-------|-------|
| 0x11  | sub-function |

第一个字节是服务ID，第二个字节是子功能。子功能决定了复位的方式。常用的子功能有：

子功能值	含义	说明
0x01	硬复位	模拟断电再上电，所有RAM数据丢失
0x02	钥匙下电/上电	模拟点火开关OFF再ON，部分ECU保留NVM数据
0x03	软复位	应用程序跳转到Bootloader，或者重启OS
0x04	使能快速编程	复位后进入编程模式，用于刷写
0x05	禁止快速编程	退出编程模式，恢复正常运行

这里要注意，子功能0x04和0x05是UDS扩展的，不是所有ECU都支持。我在一个项目中就遇到过，客户要求用0x04实现「一键刷写」，结果ECU的Bootloader根本没实现这个分支，折腾了两天。

4.3 正响应格式

ECU收到复位请求后，如果一切正常，会先回复一个正响应，然后再执行复位。正响应的格式是：

| 字节0 | 字节1 |
|-------|-------|
| 0x51  | sub-function |

注意，正响应的第一个字节是 0x51，也就是服务ID 0x11 加上 0x40。第二个字节就是请求时的子功能值。

这里有个关键点：ECU必须在复位前发送正响应。为什么？因为诊断仪需要知道ECU已经接受了请求。如果ECU先复位再发响应，那响应就丢了。我曾经调试过一个ECU，它就是在复位后才发响应，结果诊断仪一直报超时。查了三天才发现是时序问题。

4.4 负响应码(NRC)分析

复位服务虽然简单，但NRC可不少。咱们一个一个说。

4.4.1 NRC 0x12 - 子功能不支持

这个最常见。你发了0x11 0x06，但ECU只支持0x01到0x03，那它就回0x12。我建议你在设计阶段就把支持的子功能列表写死在文档里，免得后期扯皮。

4.4.2 NRC 0x22 - 条件不满足

这个有点意思。ECU说：「我现在不能复位，因为条件没达到。」比如，车辆正在行驶中，你发个硬复位，ECU肯定拒绝。我记得有个项目，客户要求在车速大于0时禁止复位，结果测试时发现ECU在P档怠速时也报了0x22，原来是车速信号处理有延迟。

4.4.3 NRC 0x33 - 安全访问拒绝

复位服务通常需要安全访问。如果你没解锁就发复位，ECU会回0x33。嗯，这里要注意，有些ECU的软复位（0x03）不需要解锁，但硬复位必须解锁。具体看各家实现。

4.4.4 NRC 0x37 - 请求序列错误

这个NRC在编程会话中很常见。比如，你正在刷写过程中，突然发个复位，ECU会拒绝。因为刷写是一个有状态的过程，不能随意中断。我曾经遇到过测试人员连续发复位和编程请求，结果ECU卡死在某个状态，最后只能断电恢复。

4.4.5 NRC 0x78 - 请求正确但响应待定

这个NRC比较特殊。ECU说：「我收到请求了，但需要时间处理，你先等着。」然后ECU会发一个0x78，等处理完了再发正响应或负响应。这个机制在复位服务中很少用，因为复位通常很快。但我在一个复杂的网关项目中见过，ECU需要先通知其他节点，再执行复位，这时候就用到了0x78。

4.5 实际项目中的避坑指南

好，理论说完了，咱们聊聊实战。我总结了几条经验：

⚠️ 注意：复位后通信中断

ECU复位后，诊断通信会中断。诊断仪需要重新建立连接。我曾经见过一个测试脚本，复位后立即发下一个请求，结果全部超时。正确的做法是：复位后等待ECU重新上线，再开始新的诊断会话。

💡 技巧：复位前的数据保存

如果你用硬复位（0x01），ECU的RAM数据会丢失。我建议在复位前，把关键数据保存到NVM（非易失性存储器）中。比如DTC状态、故障快照等。否则复位后数据全没了，客户会找你麻烦。

🔑 关键点：子功能0x04和0x05的使用场景

这两个子功能是UDS扩展，用于编程模式切换。0x04使能快速编程，ECU复位后直接进入Bootloader，跳过应用程序的初始化。0x05则相反，复位后进入应用程序。我在一个OTA项目中用过这个，效果很好，刷写时间缩短了30%。

4.6 代码示例

最后，给一个简单的伪代码示例，展示ECU如何处理复位请求：

// ECU接收到诊断请求
if (request[0] == 0x11) {
    sub_function = request[1];
    
    // 检查安全访问
    if (!isSecurityAccessGranted()) {
        sendNegativeResponse(0x33);
        return;
    }
    
    // 检查子功能支持
    if (!isSubFunctionSupported(sub_function)) {
        sendNegativeResponse(0x12);
        return;
    }
    
    // 检查条件
    if (!isConditionMet(sub_function)) {
        sendNegativeResponse(0x22);
        return;
    }
    
    // 发送正响应
    sendPositiveResponse(0x51, sub_function);
    
    // 保存关键数据到NVM
    saveCriticalDataToNVM();
    
    // 执行复位
    performReset(sub_function);
}

嗯，这个代码虽然简单，但涵盖了主要的检查点。实际项目中，你还要考虑多线程、中断、看门狗等问题。不过那是后话了。

好了，ECU复位服务就讲到这里。下一章咱们聊诊断会话控制，那个更有意思。