企业官网建设流程全解析

CanNm 从休眠唤醒后重复消息报文的周期与数量分析

现象

调试 CAN 网络管理状态机时，观察到两种唤醒方式进入重复消息模式后的 NM 报文表现不同：

抓包使用周立功设备，且只连接了这一条 CAN 总线。因此分析仪显示的Rx是分析仪接收到总线报文的方向；这些帧可按 ECU 发到总线上的报文进行分析。

原始抓包截图：

两种唤醒路径的区别

CAN 网络报文唤醒：按普通 NM 周期发送

CAN 网络报文唤醒属于网络侧唤醒。ECU 从休眠相关状态被唤醒后进入重复消息状态，NM 报文按普通消息周期发送。

若普通周期配置为 500 ms，重复消息状态持续约 1.6 s，那么在这个时间窗口内看到约 4 帧是合理的：首帧及后续周期帧受状态切换时刻、定时器调度和抓包窗口边界影响，实际帧数不一定简单等于1.6 s / 0.5 s的整数结果。

KL15 唤醒：启动快速发送

KL15 唤醒是本节点主动唤醒网络。项目启用了 CanNm 的快速 NM 发送功能，配置的快速发送次数为 5、周期为 20 ms，因此抓到 5 帧、间隔约 20 ms，与这组参数相符。

在 CanNm 实现中，进入重复消息状态时会检查节点是否主动请求网络；满足条件时设置快速发送计数并启动发送。后续每次成功发送都会递减计数，计数结束后恢复普通消息周期。因此，快速发送次数和重复消息状态的持续时间是两个不同概念：前者控制唤醒后的快速帧数，后者控制重复消息状态持续多久。

原理示意图

网络报文唤醒： NM ──500 ms── NM ──500 ms── NM ──500 ms── NM ... 普通 MsgCycleTime；Repeat Message 状态到期后退出 KL15 唤醒： NM ─20 ms─ NM ─20 ms─ NM ─20 ms─ NM ─20 ms─ NM 快速发送 5 帧；快速计数结束后恢复普通周期

上图表达的是发送机制。抓包帧数还会受首帧触发时刻、定时器调度和测量窗口边界影响；排查时应结合 ECU 实际加载的配置和完整抓包窗口判断。

在代码中的对应逻辑

项目 CanNm 实现位于：

• Proj_Code/_01_BSW/Src/CanNm/CanNm.c
• CanNm_TransitionToRepeatMessage()：进入重复消息状态时启动 Repeat Message 定时器；若节点主动请求网络且快速发送功能启用，则设置快速发送计数并启动发送。
• 消息定时器处理逻辑：快速发送计数大于零时，按快速周期发送；快速计数结束后切换到普通MsgCycleTime。

KL15 唤醒来源标记和 NM 用户数据更新位于Proj_Code/_02_CDD/NmCdd/NmCdd.c。状态切换回调会根据 KL15 标记区分唤醒来源，并更新 NM 用户数据中的唤醒原因和重复消息标志。

排查时发现：ECUC 与生成代码参数不一致

对比 ECUC 配置和当前生成代码，发现参数值存在差异：

因此，虽然抓包中的 500 ms 和 20 ms 与 ECUC 配置吻合，但当前仓库的生成文件仍是另一组旧参数。可能原因包括：生成代码未重新生成、编译时使用了不同的生成目录，或烧录固件并非由当前这份生成代码构建。

建议的核对步骤

1. 确认实际构建使用的GENDATA_DIR，以及编译输入的CanNm_Cfg.c路径。
2. 从当前 ECUC 配置重新生成 CanNm 配置代码，确认生成文件中的普通周期、快速周期和重复消息时间分别为 500 ms、20 ms 和 1.6 s。
3. 完整编译并烧录后重新抓包，核对两种唤醒路径的报文周期和数量。
4. 记录固件版本或构建产物，确保抓包结果能对应到实际烧录的配置。

结论

两种唤醒方式进入重复消息模式后，报文表现不同，主要是因为它们触发了不同的发送节奏：网络报文唤醒走普通 NM 周期；KL15 主动唤醒触发配置的快速发送序列。当前应优先解决 ECUC 与 CanNm 生成代码参数不一致的问题，并确认实际编译和烧录使用的配置。