AUTOSAR NM唤醒流程：从硬件跳变到状态迁移的完整链路拆解
你有没有遇到过这样的现场问题：
ECU明明接收到一帧NM报文，却迟迟不退出休眠？
或者更糟——刚进Bus-Sleep不到1秒，就莫名其妙被“自己”唤醒？
又或者诊断仪读出NmCurrentState = NM_BS_PREPARE_BUS_SLEEP，但后续再无进展，卡死在半路？
这些不是玄学故障，而是AUTOSAR NM唤醒流程中某个环节的隐性断点。它不像CAN通信丢帧那样有显式错误标志，也不像内存越界那样触发HardFault——它安静、隐蔽、且高度依赖配置与时机。本文不讲概念复述，不堆标准条款，而是带你亲手捋一遍从CAN总线电平翻转开始，到应用层电源策略生效为止的每一行关键代码、每一个寄存器位、每一次状态跃迁的真实路径。
为什么“收到NM帧”不等于“完成唤醒”？
先破一个常见误解：
“只要CAN控制器上报RX中断，NM模块就会立刻唤醒。”
错。非常错。
AUTOSAR NM的唤醒不是被动响应，而是一场由硬件触发、软件裁定、协议确认、系统协同的四阶段接力赛：
| 阶段 | 主体 | 关键动作 | 失败表现 |
|---|---|---|---|
| ① 硬件唤醒（HW Wake-up） | CAN收发器 + MCU唤醒引脚 | 检测显性位 → 拉低WAKEUP_N→ MCU退出STOP模式 | MCU完全无响应，电流无变化 |
| ② 协议层接纳（NM Acceptance） | Nm_RxIndicationCb() | 解析SourceAddr → 白名单校验 → 触发状态机调度 | 总线有帧，但Nm_MainFunction()未执行迁移 |
| ③ 软件确认（SW Confirmation） | Nm_Transmit()+NmTxConfirmation | 发送本节点NM PDU → 等待TX Done中断 → 更新状态 | NM_BS_PREPARE_BUS_SLEEP长期驻留，无TX事件 |
| ④ 系统就绪（System Readiness） | BswM + Rte | 根据NM状态调用Dcm_Init()、Rte_Start()等 | 应用任务未启动，诊断服务不可用 |
这四个阶段缺一不可，且存在严格时序依赖。比如第②步若没注册NmPduRxIndication回调，即使硬件已唤醒，NM模块对收到的帧也“视而不见”；第③步若NmRepeatMessageTime设为0，NM PDU根本不会发出，唤醒确认永远无法闭环。
所以，真正的调试起点，从来不是“为什么没唤醒”，而是—— <
