EcuM 唤醒验证：ECU 为什么会“醒了又睡”？¶
来源：Flomo 原文：EcuM 启动/睡眠/唤醒全流程。本页用于定位思路；具体状态、验证机制和参数以项目采用的 AUTOSAR 版本、供应商实现与 OEM 配置为准。
1. 典型现象¶
ECU 进入低功耗状态后，收到 CAN/LIN 或其他唤醒源活动，随后似乎开始唤醒，却又回到睡眠；也可能表现为总线有活动但应用未启动。
不要先认定是硬件故障。应同时检查唤醒源识别、唤醒验证、EcuM 状态迁移、通信栈恢复和电源稳定时间。
2. 排查路径¶
- 确认唤醒源：检查配置的 Wakeup Source、硬件标志、收发器状态和 EcuM 接收到的事件。
- 确认验证状态：检查项目是否启用唤醒验证、由哪个模块/接口确认、验证开始和结束条件。
- 核对时间参数：验证窗口过短可能在通信或电源尚未稳定时误判失败；过长则可能延长唤醒等待或增加无效唤醒的能耗。不要直接照搬固定毫秒数。
- 检查模式仲裁：核对 EcuM 与 BswM、ComM、CanNm 等模块的模式请求和确认，确认没有其他请求要求 ECU 继续睡眠。
- 抓取状态证据：同步记录唤醒源、EcuM 状态、验证结果、通信状态、供电波形与时间戳，再判断是配置、时序、网络还是硬件问题。
3. 现场检查清单¶
- 唤醒源配置与实际硬件连接一致
- 收发器/总线活动确实能触发唤醒
- 唤醒验证机制、确认方和超时配置已核对
- BswM/ComM/CanNm 的模式转换没有冲突
- 电源稳定时间和通信恢复时间已测量，而非凭经验猜测
- 失败后状态迁移与重新睡眠原因有日志或调试证据
4. 关键提醒¶
唤醒验证失败不一定意味着“超时太短”；也可能是唤醒源未被正确识别、确认方未上报、总线恢复异常或模式仲裁冲突。先用日志和测量定位，再调整参数。