4、CAN总线错误处理：错误类型与状态机

大家好，我是你们的讲师。今天我们来聊聊CAN总线里一个特别重要、也特别容易让人头疼的话题——错误处理。

说实话，我刚开始做CAN通信的时候，总觉得只要把数据发出去就行了。直到有一次，我在一个电机控制项目里，总线莫名其妙就罢工了，整个系统像死了一样。排查了整整两天，最后发现是错误状态机出了问题。从那以后，我再也不敢小看错误处理这块了。

4.1 错误类型：总线上的“噪音”从哪来？

CAN总线在设计之初，就考虑到了工业现场的恶劣环境。它有一套非常完善的错误检测机制。说白了，就是让每个节点都能自己发现“出事了”。

常见的错误类型有五种，我一个个说给你听。

4.1.1 位错误（Bit Error）

这是最基础的一种错误。节点在发送数据时，会同时监听总线。如果它发送的电平，和自己监听到的电平不一致，那就说明出问题了。

举个例子：你发送了一个显性位（逻辑0），但总线上却听到了隐性位（逻辑1）。这通常意味着有别的节点也在同时发送，或者总线被干扰了。

我在项目中遇到过一种情况：某个节点的CAN收发器坏了，输出一直卡在隐性电平。结果它自己发送显性位时，总发现电平不对，就一直报位错误。嗯，这种硬件故障排查起来最头疼。

4.1.2 填充错误（Stuff Error）

CAN总线有个规矩：连续发送5个相同电平后，必须插入一个相反电平的位。这叫“位填充”。

为什么要有这个规矩？因为CAN节点是靠电平跳变来同步时钟的。如果长时间没有跳变，时钟就容易漂移。

填充错误，就是接收节点发现连续6个相同电平，没有插入填充位。这说明发送方要么坏了，要么协议实现有bug。

4.1.3 CRC错误（CRC Error）

CRC（循环冗余校验）是CAN帧里的一段校验码，由发送节点计算并附在数据后面。接收节点收到后，会重新计算一遍CRC，跟收到的对比。

如果不一致，那就是CRC错误。这通常意味着数据在传输过程中被干扰了。

你想想看，工业现场电机启停、变频器开关，都会产生强烈的电磁干扰。CRC错误其实是最常见的错误类型之一。

错误类型	检测方	常见原因
位错误	发送节点	总线冲突、收发器故障
填充错误	接收节点	发送方时钟漂移、协议bug
CRC错误	接收节点	电磁干扰、信号衰减
格式错误	接收节点	帧格式不符合规范
应答错误	发送节点	没有节点接收

4.1.4 格式错误（Form Error）

CAN帧的每个字段都有固定的格式。比如CRC界定符必须是隐性位，ACK槽后面必须是隐性位。如果接收节点发现这些固定格式不对，就会报格式错误。

格式错误通常意味着发送节点的协议实现有问题，或者总线被严重干扰导致位翻转。

4.1.5 应答错误（ACK Error）

发送节点在发送完数据后，会等待接收节点在ACK槽里发送显性位作为应答。如果发送节点没收到这个显性位，就报应答错误。

为什么会这样？最常见的原因是总线上没有其他节点在监听。或者接收节点因为某种原因（比如处于总线关闭状态）无法应答。

4.2 错误状态机：从“好孩子”到“被开除”

光检测到错误还不够，还得有办法处理。CAN协议定义了一个错误状态机，每个节点都处于三种状态之一：主动错误、被动错误、总线关闭。

这个状态机是怎么工作的？核心是两个计数器：发送错误计数器（TEC）和接收错误计数器（REC）。

4.2.1 主动错误状态（Error Active）

这是节点的初始状态。在这个状态下，节点检测到错误后，会发送“主动错误标志”——连续6个显性位。这个标志会覆盖总线上的正常数据，强制所有节点知道出错了。

说白了，主动错误状态下的节点，是个“暴脾气”。一发现不对，立刻大喊大叫，让所有人都停下来。

当TEC或REC超过127时，节点就会进入被动错误状态。

4.2.2 被动错误状态（Error Passive）

进入这个状态后，节点就“收敛”了很多。它检测到错误后，只能发送“被动错误标志”——连续6个隐性位。这个标志不会覆盖总线上的正常数据，其他节点可能根本注意不到。

我遇到过最坑的情况：某个节点进入被动错误状态后，它自己还在拼命重发，但其他节点根本不知道它在报错。结果就是那个节点一直在“自言自语”，数据却传不出去。

被动错误状态下，节点在发送完数据后，还要额外等待8个位时间才能开始下一次发送。这叫做“挂起传输”。目的是给其他节点更多机会。

当TEC超过255时，节点就会进入总线关闭状态。

4.2.3 总线关闭状态（Bus Off）

这是最严重的状态。节点会完全断开与总线的连接，不再参与任何通信。说白了，就是被“开除”了。

为什么会这样？因为TEC持续增长，说明这个节点一直在发送错误帧。如果不把它隔离，它会不断破坏总线通信。

总线关闭后，节点怎么恢复？有两种方式：

• 自动恢复：节点检测到128次连续的11个隐性位（即总线空闲状态）后，自动回到主动错误状态。
• 手动恢复：通过软件或硬件复位，强制节点回到主动错误状态。

4.3 错误处理的实际应用

说了这么多理论，我们来点实际的。在嵌入式开发中，怎么用好这些错误机制？

4.3.1 监控错误计数器

大多数CAN控制器都提供了读取TEC和REC的寄存器。我建议你在代码中定期读取这两个值，并设置告警阈值。

// 伪代码示例：监控CAN错误计数器
uint8_t tec = CAN_GetTEC();
uint8_t rec = CAN_GetREC();

if (tec > 96 || rec > 96) {
    // 接近被动错误状态，发出警告
    CAN_LogWarning("Error counter high: TEC=%d, REC=%d", tec, rec);
}

if (tec > 127 || rec > 127) {
    // 已进入被动错误状态，需要处理
    CAN_HandlePassiveError();
}

if (tec > 255) {
    // 总线关闭，需要复位
    CAN_HandleBusOff();
}

4.3.2 错误恢复策略

我个人习惯的做法是：

1. 主动错误状态：正常通信，不需要特殊处理。
2. 被动错误状态：降低该节点的发送频率，同时记录错误日志。如果持续恶化，考虑切换冗余通道。
3. 总线关闭：先检查硬件（收发器、线缆、终端电阻），确认没问题后再手动恢复。不要自动恢复。

4.3.3 常见误区

嗯，这里要注意一点：很多人以为错误帧是坏事。其实恰恰相反，错误帧是CAN总线自我保护的体现。如果一个节点从来不报错，反而说明它可能“聋了”——根本听不到总线上的错误。

我曾经遇到一个项目，客户抱怨总线不稳定。我一看日志，所有节点都频繁报CRC错误，但有一个节点始终“干干净净”。最后发现那个节点的CAN控制器配置错了，接收滤波器把所有错误帧都过滤掉了。它以为自己很完美，其实一直在“装睡”。

好了，这一章的内容就到这里。下一章我们会讲CAN的同步机制和位时序，这是理解CAN速率和总线长度的关键。到时候见。