4、ECU复位服务（0x11）：复位类型、时序要求与数据保持

说到0x11服务，我脑子里第一个蹦出来的词就是「重启大法好」。做嵌入式这么多年，遇到奇奇怪怪的bug，很多时候复位一下就好了。但在车载诊断里，复位可不是简单粗暴地拉一下电源。

0x11服务，说白了就是让ECU重新来一遍。但这里面的门道，比你想象的多得多。我刚开始做UDS协议栈时，觉得复位嘛，调用个系统函数就完事了。结果第一次上车测试，客户说「你这复位把标定数据全丢了」，我才意识到事情没那么简单。

4.1 复位类型：三种复位，三种脾气

UDS规范里定义了三种复位类型，每种都有自己的应用场景。我个人习惯把它们分成「温柔型」「暴力型」和「中间型」。

复位类型	子功能ID	典型应用
硬复位 (Hard Reset)	0x01	完全重新上电，类似拔掉电池再插上
钥匙复位 (Key Off/On Reset)	0x02	模拟点火开关关闭再打开
软复位 (Soft Reset)	0x03	仅复位应用层，不重新初始化硬件

硬复位（0x01）：这是最彻底的复位方式。ECU会重新执行完整的初始化流程，包括硬件寄存器、外设、操作系统内核等。我在项目中遇到过一个问题：某次硬复位后，CAN控制器重新初始化需要时间，导致复位后第一条诊断请求超时了。嗯，这里要注意，硬复位后要留足等待时间。

钥匙复位（0x02）：这个很有意思。它模拟的是车辆熄火再点火的过程。ECU会保持某些关键电源（比如RTC、SRAM）不断电，但会重新初始化应用层。我记得有一次，客户要求钥匙复位后必须保留故障码，但清除学习值。这就需要在复位前把数据分类保存好。

软复位（0x03）：说白了就是「假装重启」。只复位应用层任务，底层硬件不动。这种复位最快，但风险也最大。你想想看，如果某个硬件状态已经异常了，软复位根本清不掉。我曾经踩过这个坑：一个ADC采样值漂移，软复位后问题依旧，最后发现是硬件寄存器没重新配置。

4.2 复位时序要求：时间就是生命

复位不是瞬间完成的。ECU从收到复位请求到恢复正常工作，中间有一系列步骤。我个人习惯把时序分成三个阶段：

1. 响应阶段：ECU必须在收到请求后50ms内发送肯定响应。注意，是「发送」不是「执行」。
2. 执行阶段：发送完响应后，ECU开始执行复位操作。这个阶段通常持续10-100ms。
3. 恢复阶段：复位完成后，ECU重新初始化，直到可以正常通信。这个时间因ECU而异，快的50ms，慢的可能要500ms。

为什么会这样分阶段？因为诊断仪需要知道复位已经开始了。如果ECU先复位再发响应，那响应就发不出去了。所以标准规定：先发响应，再执行复位。

这里有个时序图，我习惯用文字描述一下：

诊断仪发送 0x11 03 → ECU收到请求
         ↓
ECU发送肯定响应 (0x51 03)
         ↓
ECU等待50ms（确保响应被总线接收）
         ↓
ECU执行复位操作
         ↓
ECU重新初始化
         ↓
ECU发送「上电报文」或「应用就绪报文」
         ↓
诊断仪可以开始新的诊断会话

4.3 复位后行为：数据该不该留？

这是0x11服务最让人头疼的地方。复位后，哪些数据要保留？哪些要清零？标准没说死，全靠ECU自己定义。我总结了一个原则：非易失性数据尽量保留，运行时数据全部清零。

具体来说：

• 必须保留的：DTC故障码（除非是特定清除请求）、标定数据、VIN码、生产信息
• 可以保留的：扩展会话状态、安全访问状态（看客户需求）
• 必须清零的：运行时变量、临时缓冲区、诊断会话状态

我记得有一次，客户要求「钥匙复位后，安全访问状态必须保留」。这就意味着ECU在复位过程中不能丢失RAM中的数据。解决方案是：给安全访问相关的RAM区域单独供电，或者用备份寄存器保存状态。

4.4 代码实现：一个简单的复位处理框架

下面是我常用的复位处理代码框架。注意，这只是示意，实际项目中要复杂得多。

// 复位服务处理函数
void DiagService_Reset(uint8_t subFunction) {
    // 1. 检查子功能是否支持
    if (!IsResetTypeSupported(subFunction)) {
        SendNegativeResponse(NRC_SUBFUNCTION_NOT_SUPPORTED);
        return;
    }
    
    // 2. 保存需要保留的数据
    SavePersistentData(subFunction);
    
    // 3. 发送肯定响应
    SendPositiveResponse(0x51, subFunction);
    
    // 4. 等待响应发送完成
    WaitForTxComplete();
    
    // 5. 执行复位
    switch(subFunction) {
        case 0x01: // 硬复位
            NVIC_SystemReset();
            break;
        case 0x02: // 钥匙复位
            App_KeyOffOnReset();
            break;
        case 0x03: // 软复位
            App_SoftReset();
            break;
        default:
            break;
    }
}

你想想看，这个框架里最关键的是第2步和第4步。第2步决定了数据会不会丢，第4步决定了响应能不能发出去。我刚开始做的时候，经常把第4步漏掉，结果就是诊断仪收不到响应，以为ECU死机了。

4.5 避坑指南：我踩过的那些坑

做0x11服务这么多年，我总结了几条血泪教训：

• 不要在执行复位前关闭CAN控制器：否则响应发不出去。先发响应，再复位。
• 注意看门狗：复位过程中如果看门狗超时了，ECU会被强制复位，导致时序混乱。我建议在复位前暂停看门狗。
• 数据保持要考虑掉电情况：如果复位过程中电源不稳定，数据可能写坏。用CRC校验或者双备份机制保护关键数据。
• 复位后要重新注册诊断服务：有些协议栈在复位后需要重新调用初始化函数，否则诊断请求会无响应。