瑞萨 RL78/F13 MCU 的 CAN 滤波机制介绍以及调试经验分享

在车载电子系统中，CAN 总线几乎无处不在。多个 ECU (Electronic Control Unit，电子控制单元) 通过 CAN 总线交换控制命令、状态信息以及诊断数据，实现整车各功能模块之间的协同工作。

众所周知，CAN 总线采用广播通信机制。当某个 ECU 发送一帧 CAN 报文时，总线上的所有节点都能够接收到该报文。然而，并非所有报文都与每个 ECU 相关。如果 MCU 对所有接收到的报文都进行存储、解析和处理，不仅会占用宝贵的 CPU 资源，还会增加中断处理负担，影响系统实时性和整体运行效率。

为了解决这一问题，CAN 控制器通常提供硬件报文过滤功能。在报文进入接收缓冲区之前，控制器会根据预先配置的过滤规则对报文进行筛选，仅允许符合条件的报文进入后续处理流程，从而显著降低软件处理压力。

对于瑞萨 RL78/F13 而言，其 CAN 模块提供了灵活的 Receive Rule Table (接收规则表) 机制，可在硬件层面完成报文过滤、分类和存储管理。本文将结合实际项目经验，对 RL78/F13 的 CAN 接收过滤机制进行介绍，并分享开发过程中遇到的典型问题及排查思路。

为了对接收到的报文进行过滤，需要配置接收规则表 (Receive Rule Table)，这是 CAN 报文过滤很重要的一环。通过接收规则表执行的数据处理后，符合条件的报文将被存储到指定的缓冲区中。

接收规则表的数据处理功能包括：

• 接收过滤处理 (Acceptance Filter Processing)
• DLC 过滤处理 (DLC Filter Processing)
• 路由处理 (Routing Processing)
• 标签添加 (Label Addition)
• 镜像功能 (Mirror Function)

配置接收规则时，需要指定以下内容：

• 接收规则数量 (Number of Receive Rules)
• IDE 位、RTR 位以及 CAN ID
• 接收规则的目标报文 (Messages Target for the Receive Rules)
• IDE 掩码、RTR 掩码以及 ID 掩码
• DLC 检查功能 (DLC Check Function)
• 接收规则标签 (Receive Rule Labels)
• 报文存储目标缓冲区 (Buffers to Store Messages)

关于 CAN 接收规则表的配置的代码形式可以参考如下：
 

#if CAN_RX_RULE_NUM > 0

const uint16_t g_rxrule_table[CAN_RX_RULE_NUM][6] = {

    /* IDL,   IDH,   ML,     MH,     PL,     PH */

    { 0x0123U, 0x0000U, 0xFFFFU, 0x0000U, 0x0000U, 0x0000U },   // 标准帧 0x123 → Buffer0

};

#endif

以上代码的第一维表示接收规则编号 (Rule0~RuleN)，第二维表示该规则对应的 6 个 GAFL 配置寄存器 (IDL、IDH、ML、MH、PL、PH)。初始化时，程序会将数组中的内容逐条写入 CAN 模块的 Receive Rule 寄存器，从而建立完整的接收过滤规则表。

IDL+IDH 合起来其实就是一整个 ID 的信息，前 16 位是 IDL 部分，后 16 位是 IDH 部分。其中 IDL 的 0-15 位全是报文 ID 的 ID 大小，在标准帧只有 11 位的情况下，IDL 部分足以涵盖标准帧 ID 的大小。如果是扩展帧的话，则 IDL 的 16 位不够用，需要再加上 IDH 部分的低 13 位，一共 29 位 ID 长度。

剩下的 3 位功能如下：

Bit 13：选择收信规则目标，如果是 1 可以接收自己节点发送的 ID 报文，如果是 0 只能接收外部报文。

Bit 14：RTR 选择，如果是 1 则该帧被标记为远程帧。

Bit 15：选择是不算扩展帧，如果是为 1，否则为标准帧为 0。

ML 和 MH 部分这两个是掩码部分对应的寄存器，比较简单粗暴，其实就是和 ID 进行每一位的比对，如果是 1 表示要比，0 则不用比较。

该部分寄存器的主要功能是当某条过滤规则匹配成功后，决定报文要存到哪里。

Bit 15：控制是否使用 Receive Buffer

Bit 14~8：指定写入哪个 Receive Buffer

Bit 7~5：预留位，只能写 0

Bit 4：控制是否写入 Transmit/Receive FIFO0

Bit 3~2：预留位，只能写 0

Bit 1：控制 Receive FIFO0，0 是不使用，1 是写入使用

该寄存器主要负责决定报文有什么附加属性。

Bit 15~12：DLC 检查，检查报文携带多少字节数据

Bit 11~0：Label 标签，给进入的报文携带额外的标签

项目调试过程中，使用 PCAN 抓取总线数据时，发现总线上持续出现两条来源不明的 CAN 报文，但是其他系统中有的报文也都正常出现。由于当前环境未搭建其他 ECU 仿真节点，系统中也未配置远程帧 (Remote Frame)，因此初步判断该现象属于软件配置异常。

由于项目硬件设计与上一代产品基本一致，因此首先从软件配置差异入手进行比对。经过逐步定位，最终发现问题出现在 CAN Receive Rule Table 的配置上。瑞萨 RL78/F13 最多仅支持 16 条接收规则，而新项目中实际配置了 18 条接收规则，超出了硬件允许范围。

如上图 (图9) 显示，F13 和 F14 最多为 16 个规则 (0~15)。

因为在旧项目共使用 15 个 CAN ID，因此接收规则数量为 15 条。新项目增加了部分功能报文，CAN ID 总数增加至 18 个，但在移植代码过程中，开发人员直接按照报文数量配置了 18 条接收规则，导致超出了硬件限制。超出的规则区域覆盖了后续寄存器空间，从而导致系统出现异常接收现象，最终表现为 PCAN 中出现两条“幽灵帧”。

Dummy 了两个 ID 过滤规则后，幽灵帧报文不再出现。

如果有 18 个 ID，但是最大只能 16 的情况下如何变通？

可以通过修改掩码配置，将两条 ID 合并到一条的方式去过滤，设置成符合 16 个数目，但是实际上对应着 18 条的规则。

通过以上设定，最终幽灵帧消失，一切正常，且原有的 18 条报文也正常出现在 PCAN 上。

CAN 接收过滤机制是 RL78/F13 CAN 模块的重要特性之一。合理利用 Receive Rule Table 不仅能够降低 MCU 负载，提高系统实时性，还能够有效优化接收资源的分配。在实际项目开发过程中，除了关注过滤逻辑本身外，也需要特别注意接收规则数量、Buffer 配置以及 Mask 的使用方式，避免因配置超限而引发难以定位的问题。通过充分理解硬件过滤机制，可以让 CAN 网络设计更加高效、稳定和可靠。

欲了解关于更多瑞萨相关方案或技术信息，请与骏龙科技当地的办事处联系或点击下方「联系我们」，提交您的需求，骏龙科技公司愿意为您提供更详细的技术解答。