【EK-RA8M1测评】02CAN FD Lite 内部回环与数据校验

在 EK-RA8M1 上，我使用 FSP 的 CAN FD Lite 驱动完成了单板内部回环：按100 ms间隔尝试发送一帧标准 ID 0x321、16字节的模拟车辆数据，再通过接收回调检查内容。实板记录中，发送、接收和有效接收计数能够共同增长。本文说明这套演示的配置和实现方式，便于理解后续在线与离线判断的数据来源。

一、完成控制器内部的收发实验

本次使用通道0和内部回环模式，测试信号在 CAN FD 控制器内部完成发送与接收。内部回环适合先检查控制器、驱动、回调和报文解析。

项目在 FSP 中选择 r_canfdlite 模块。官方 CAN FD 驱动文档同时覆盖 r_canfd 和 r_canfdlite，可用来核对接口、缓冲区和测试模式。[2] 阅读例程时仍应结合具体 MCU 与当前 FSP 版本，不能只按模块名称猜测配置。

本次使用 e² studio 2026-07、FSP 6.6.0 和 Arm LLVM 22.1.0，工程为 Bare Metal。应用代码位于 src/hal_entry.c；FSP 参数保存在 configuration.xml，修改配置后需要重新执行 Generate Project Content，再构建工程。

本次 FSP 配置的关键项

生成代码中的标称位速率和数据位速率分别对应上述设置。这是本次控制器的设定值，未通过外部波形测量；也不能把内部回环结果写成外部总线已经在500 kbit/s与2 Mbit/s下通过验收。

接收过滤规则只接受标准 ID 0x321 的数据帧，并送入 RX FIFO 0。应用层还会继续检查 FD、BRS、长度和载荷，因此过滤器的作用是限定接收入口，最终有效性仍由接收回调判断。

                                                                                           图1 FSP 中 CAN FD Lite 通道与位速率配置

二、初始化与周期发送

应用先调用 R_CANFD_Open 打开实例，再调用模式切换接口进入内部回环。模式切换的核心调用如下：

R_CANFD_ModeTransition(&g_canfd0_ctrl,
    CAN_OPERATION_MODE_NORMAL,
    CAN_TEST_MODE_LOOPBACK_INTERNAL);

SysTick 提供毫秒计时，主循环按100 ms间隔尝试发送。当前版本使用一个发送缓冲，只有 pause_tx=0 且发送缓冲不忙时，才组装并提交下一帧。R_CANFD_Write 返回成功后增加 tx_count；发送完成回调增加 tx_complete_count，并释放忙标志。

因此，tx_count 增长首先说明驱动接受了请求。要继续确认完成事件和接收结果，需要同时看 tx_complete_count、rx_count 和 valid_rx_count。只把发送函数放在循环中，再在同一处累加“接收计数”，无法验证实际接收回调是否执行；本工程的接收计数来自 RX 完成事件。

16字节模拟车辆数据怎样组织

报文中的车速、转向角和扭矩由软件生成，用于观察编码与解析，不来自真实传感器或车辆。多字节字段采用小端排列，具体布局如下。

代码中 frame.data_length_code 填写实际长度16，由 FSP 驱动转换为线上 DLC 编码。字段名称包含 code 容易让人误以为这里应直接填写协议编码值，复用接口时应核对当前驱动对长度参数的定义。

末尾固定图样有助于检查数据排列，但不是额外设计的应用 CRC。当前回环实验把接收的全部16字节与最近发送内容逐字节比较；扩展为外部节点协议时，还需要根据实际发送方和更新顺序重新设计校验方式。

                                           图2 报文组装、FD 与 BRS 设置及发送代码（调试截图局部）

接收回调决定哪些帧有效

CAN_EVENT_RX_COMPLETE 到来后，程序增加 rx_count，并保存接收 ID、长度和载荷。随后核对标准帧、数据帧、ID 0x321、16字节长度、FD/BRS 标志，以及全部载荷是否符合本次发送内容。只有通过这些检查，才增加 valid_rx_count、解析字段并刷新最后有效接收时间。

这种划分使“收到一帧”和“收到可接受的一帧”有了不同计数。第一次实板快照中，tx_count、rx_count、valid_rx_count 均为64，error_count 为0，接收 ID 为0x321、长度为16，node_online 为1。继续运行后，三项计数共同增加到634。

这两次快照中，uptime_ms 从6398 增加到63380，间隔56982 ms；三项计数各增加570，error_count 保持为0。按这段时间和帧数估算，平均约每100 ms收到一帧，与设定周期大体一致。

图3为另一轮独立运行中暂停 MCU 后读取的调试快照：tx_count、tx_complete_count、rx_count 和 valid_rx_count 均为923，error_count 为0，rx_id 为801（十进制，即0x321），rx_length 为16，node_online 为1。uptime_ms 为106727，last_rx_time_ms 为106700，两者相差27 ms。

三、构建与观察步骤

在 e² studio 中打开 RA8M1_EEPW 工程，选择 Debug 并执行 Build Project。本次记录为 0 errors、0 warnings，生成 ELF；然后通过 J10 USB DEBUG 连接板载 J-Link，使用工程已有的 RA8M1_EEPW Debug_Flat 配置启动调试。若程序停在 Reset_Handler 或 main，按 Resume 继续执行。

在 Expressions 窗口加入 tx_count、tx_complete_count、rx_count、valid_rx_count、error_count、rx_id、rx_length 和 uptime_ms。运行一段时间后暂停，记录第一组数值；再次继续运行并暂停，比较两组快照。若实时刷新不可用，可用这种暂停读取的方式观察，但暂停期间程序计时不会继续。

正常情况下，先看 tx_count 是否增加，再看 tx_complete_count、rx_count 和 valid_rx_count 是否随运行推进；rx_id 应为 0x321，rx_length 应为16。计数是不同事件的快照，帧处理过程中可能短暂不相等，应等待稳定后再比较。若 error_count 增长，结合 last_fsp_error、last_can_error 和当时操作排查。

图3 内部回环暂停调试结果：四项计数均为923，错误数为0，接收ID为0x321，长度为16字节（原截图局部）

四、从回环功能走向应用验证

现有计数记录支持在观察区间内完成周期提交、控制器内部接收和应用层数据校验；图3进一步直接记录了发送完成计数 tx_complete_count 与发送请求、接收、有效接收计数一致。不过，暂停时刻的计数一致不能证明每帧时延、总线负载上限或长期运行可靠性，也未进行外部多节点仲裁测试。

下一篇会利用 pause_tx 暂停发送，在 MCU 继续运行的情况下观察最后有效接收时间如何影响 node_online，并把调试变量与板载蓝灯、绿灯的实际变化对应起来。

参考资料

[1] Renesas EK-RA8M1 产品与资料入口

[2] Renesas FSP CAN FD 与 CAN FD Lite 驱动文档