EK-RA8M1 评测三：CAN FD 内部回环的心跳超时与恢复实测

在上一篇 CAN FD Lite 内部回环实验基础上，我通过暂停应用层周期发送，模拟一段时间内没有新有效报文的情况，验证超时离线和恢复在线。实板记录显示，暂停周期发送后，收发计数停止增长，node_online 变为0；恢复发送后，计数重新增长，node_online 变为1。另有实拍视频展示蓝灯亮、绿灯灭，以及恢复后绿灯重新常亮的过程。本文结合记录、截图和视频说明实验结果。

在线状态由最后有效接收决定

本次沿用 EK-RA8M1 单板的 CAN FD Lite 通道 0 与 FSP 6.6.0 工程，通过 J10 USB DEBUG 调试，未接入外部 CAN 节点。程序每 100 ms 尝试发送一帧 16 字节数据；接收回调检查帧格式和载荷，并与最近一次发送的数据逐字节比较，校验通过后更新 last_rx_time_ms。主循环结合 uptime_ms 判断超时，再更新 node_online 和板载 LED。报文中虽有递增心跳字段，在线判断依据仍是最后一次有效接收的时间，而不是单独检查心跳计数是否递增。

已经收到过有效帧，且距最后有效接收不超过500 ms时，node_online 为1；超过500 ms则变为0。启动后尚未收到有效帧时也保持离线。

LED 显示结果由主循环随状态变化更新。实拍视频中，在线时 LED2 绿灯常亮、LED1 蓝灯熄灭；暂停发送并进入离线后，LED1 蓝灯亮、LED2 绿灯熄灭；恢复发送后又回到在线亮灯方式。当前应用没有控制 LED3。配套 GIF 从实拍视频中剪辑，省略了部分等待过程，仅用于展示状态变化，不能作为响应时间测量依据。

图1 实拍视频截图：左为离线时蓝灯亮，右为恢复后绿灯亮

动图：在线、掉线与恢复的实拍过程

先记录正常运行的计数变化

第一次暂停读取时，uptime_ms 为6398，发送、接收和有效接收计数均为64，错误数为0。继续运行后再次暂停，uptime_ms 为63380，三项计数均为634，错误数仍为0。两个快照之间，应用计时增加56982 ms，有效接收增加570帧。

这段约57 s的记录说明回环通信和有效帧校验在观察区间内持续工作，计数变化也与100 ms名义发送周期大体一致。它没有记录每帧时间戳，不能据此计算发送抖动、最大延迟或长时间运行可靠性。

表中数据来自先后暂停读取的快照，不是连续采样曲线。比较计数前应等待当前帧处理完成；发送请求、完成事件和接收回调之间短暂出现计数差异，本身还不足以判断丢帧。

图2 另一次在线状态的调试快照：三项计数均为4484，node_online 为1

暂停发送后观察离线

测试通过 pause_tx 控制发送入口：先暂停调试，在 Expressions 中把 pause_tx 改为1，再继续运行 MCU，等待超过设定超时后读取结果。暂停发送的同时，主循环和 SysTick 仍然执行，才能让“没有新报文”逐渐成为离线条件。

在前述634帧记录的同一轮测试中，暂停发送后读取到 uptime_ms=69410、last_rx_time_ms=63300，发送、接收和有效接收计数仍保持634，node_online=0。两个时间戳相差6110 ms，说明读取时距最后有效接收已经明显超过500 ms。

这组历史记录支持“停止有效接收后能够进入离线”的判断。若需要测量切换延迟，应在 MCU 持续运行时记录事件时间戳，或用 GPIO 与逻辑分析仪同步观察。图3来自另一次独立离线测试：pause_tx=1、node_online=0，三项计数均为51，uptime_ms=9846、last_rx_time_ms=5000；它与634帧记录及实拍视频均不是同一轮。

图3 另一次离线调试快照：pause_tx=1，node_online=0，三项计数均为51

恢复发送后重新在线

在634帧记录的同一轮测试中，随后把 pause_tx 改回0并继续运行。下一次读取时，uptime_ms=73923、last_rx_time_ms=73900，三项计数均增长到679，node_online=1，error_count=0。

另一次独立测试的恢复在线快照见图 4：pause_tx=0，发送、接收和有效接收计数均为 11204，node_online=1，error_count=0。截图是恢复后的一个时刻，不能单独证明切换过程或测量恢复延迟；图 4 与上述 634/679 帧记录不是同一轮测试。

图 4 另一次恢复在线后的调试快照（Expressions 局部）

这个过程通过调试变量暂停和恢复应用发送，没有重新给开发板断电。它验证了本次运行条件下，恢复发送后能收到新的有效帧，并重新满足在线判断。计数增加45帧是两个观察时刻之间的结果，不能用这段间隔推算恢复动作的瞬时延迟。

调试暂停与应用掉线要分清

点击调试器暂停会让 MCU 停止执行，应用中的 SysTick 计时也不再按正常运行方式推进。因此，不能让调试器停住，在电脑上等待数秒，就把这段墙上时间当作已经完成了掉线等待。有效步骤是修改 pause_tx 后恢复执行，再观察 node_online 与 LED。

写入变量时若提示 Failed to write to memory，应先检查连接并重新读回目标值，不能继续把该次操作计入成功实验。

这次实验验证到的范围

本次以 CAN FD 控制器内部回环模拟单个节点，记录了正常收发、停止发送后的超时离线，以及恢复发送后的重新在线。error_count 在观察区间内为0，表示应用没有记录到所监测的校验或驱动错误，不代表所有潜在故障都已覆盖。

当前使用一个发送缓冲。如果发送完成中断丢失，tx_busy 可能一直保持，后续周期发送会停止；这类问题的自动恢复尚未实现。外部 CAN 收发器、线束、终端匹配、其他 ECU、Ethernet 和长时间运行也没有纳入这次实测。

就这次板卡评测而言，最清楚的成果是把真实回调计数、应用时间戳和实物 LED 对应起来。后续连接外部节点时，可以沿用这些观察变量，同时增加总线抓包、异常事件和连续时序记录，让每一个通信结论都有可追溯的数据。

参考资料

[1] Renesas，EK-RA8M1 产品页面及用户手册：https://www.renesas.com/en/design-resources/boards-kits/ek-ra8m1

[2] Renesas，FSP CAN FD 和 CAN FD Lite 驱动文档：https://renesas.github.io/fsp/group___c_a_n_f_d.html