4、CAN总线错误处理：错误类型与错误状态机
大家好，我是老张。今天咱们聊聊CAN总线里一个特别重要、但很多人容易忽略的话题——错误处理。
说实话，我刚入行那会儿，总觉得CAN总线挺稳定的，错误处理嘛，无非就是重发一下。直到有一次，我在一个商用车项目上，整车网络莫名其妙地掉线，查了三天三夜，最后发现是一个节点的错误计数器爆了，直接进入了Bus Off状态。从那以后，我再也不敢小看错误处理机制了。
CAN总线的错误处理，说白了就是一套自我诊断和恢复的机制。它不需要额外的诊断线，完全靠硬件自动完成。你想想看，这在汽车这种高可靠性场景下，有多重要。
4.1 五种错误类型
CAN协议定义了五种错误类型。我习惯把它们分成两类：一类是“格式问题”，另一类是“内容问题”。咱们一个一个来看。
4.1.1 位错误（Bit Error）
定义：发送节点在发送位时，会同时监控总线电平。如果监控到的电平与自己发送的不一致，就产生位错误。
嗯，这里要注意：只有发送节点才会检测位错误。接收节点不干这事儿。
举个例子：你发送了一个显性位（逻辑0），但总线上实际是隐性位（逻辑1）。这说明总线被其他节点干扰了，或者你的发送电路有问题。
我在项目中遇到过一种情况：某个节点的CAN收发器供电不稳，导致发送的显性位驱动能力不足，总线电平被其他节点的隐性位拉低。结果就是频繁报位错误，节点反复重发，最后把自己搞进Bus Off。
4.1.2 填充错误（Stuff Error）
CAN总线采用NRZ编码，为了防止时钟同步丢失，协议规定：连续发送5个相同电平的位后，必须插入一个相反电平的位。这就是位填充规则。
填充错误：如果接收节点检测到连续6个相同电平的位，就认为发生了填充错误。
我的小技巧：调试时如果看到填充错误，先别急着怀疑硬件。有时候是软件配置的CAN控制器模式不对，比如把CAN 2.0的节点接到了CAN FD网络上，位填充规则不一样，就会报错。
4.1.3 CRC错误（CRC Error）
CRC（循环冗余校验）是检查数据完整性的。发送节点会计算一个15位的CRC校验码，放在数据帧里。接收节点收到后，重新计算CRC，如果和自己算出来的不一致，就报CRC错误。
说白了，这就是个“对账”的过程。你发过来的数据和校验码对不上，那肯定是传输过程中出了问题。
| 错误类型 | 检测方 | 常见原因 |
|---|---|---|
| 位错误 | 发送节点 | 总线干扰、收发器故障 |
| 填充错误 | 接收节点 | 位填充规则违反、协议不匹配 |
| CRC错误 | 接收节点 | 电磁干扰、数据损坏 |
| 格式错误 | 接收节点 | 帧格式异常、位时序偏差 |
| 应答错误 | 发送节点 | 无节点应答、ACK槽被覆盖 |
4.1.4 格式错误（Form Error）
格式错误检测的是帧的固定格式部分。比如CRC界定符、ACK界定符、EOF（帧结束）等，这些位在协议里是固定电平的。如果接收节点发现它们不是预期的电平，就报格式错误。
为什么会这样？我遇到过一种情况：某个节点的晶振偏差太大，导致位采样点偏移，把正常的位采样成了错误电平。结果就是格式错误满天飞。
4.1.5 应答错误（ACK Error）
这个最容易理解。发送节点在发送完数据后，会在ACK槽等待接收节点的应答。如果总线上没有节点发送显性位来确认，发送节点就报应答错误。
注意：应答错误不一定代表总线坏了。有时候是总线上只有一个节点在发，没有其他节点接收，自然就没有应答。这在单节点测试时很常见。
4.2 错误状态机
好了，五种错误类型讲完了。但光知道错误类型还不够，你得知道CAN控制器是怎么处理这些错误的。这就引出了错误状态机。
每个CAN节点内部都有两个计数器：
- 发送错误计数器（TEC）：记录发送错误次数
- 接收错误计数器（REC）：记录接收错误次数
这两个计数器决定了节点处于哪个状态。状态机一共三个状态：
4.2.1 错误主动（Error Active）
这是正常状态。TEC和REC都小于127。节点可以正常收发，检测到错误时发送主动错误帧（6个显性位）。
4.2.2 错误被动（Error Passive）
当TEC或REC超过127，但小于255时，节点进入错误被动状态。此时节点仍然可以收发，但检测到错误时只能发送被动错误帧（6个隐性位）。
说白了，就是“我犯错了，但我小声说”。被动错误帧不会干扰其他节点的通信。
4.2.3 总线关闭（Bus Off）
当TEC超过255时，节点进入总线关闭状态。此时节点完全断开与总线的连接，不发送也不接收任何数据。
避坑指南：我曾经在一个项目中，某个节点频繁进入Bus Off，然后又自动恢复。查了半天，发现是软件里没有处理Bus Off恢复的延迟。CAN协议规定，节点进入Bus Off后，必须等待128个总线空闲位才能恢复。但有些控制器允许软件配置这个恢复时间。如果你配置得太短，节点就会反复进入Bus Off，造成网络抖动。
4.3 错误处理流程
咱们用一段伪代码来展示错误处理的核心逻辑：
// 错误处理伪代码
if (检测到错误) {
if (发送错误) {
TEC += 8; // 发送错误，TEC加8
} else {
REC += 1; // 接收错误，REC加1
}
if (TEC > 255) {
进入Bus Off状态;
断开总线连接;
等待128个总线空闲位;
恢复通信;
} else if (TEC > 127 || REC > 127) {
进入Error Passive状态;
发送被动错误帧;
} else {
保持Error Active状态;
发送主动错误帧;
}
}
// 成功发送或接收时，计数器递减
if (成功发送) {
TEC -= 1;
}
if (成功接收) {
if (REC > 0) {
REC -= 1;
}
}你看，这个机制设计得很巧妙。错误计数器不是简单的累加，成功时还会递减。这就给了节点“改过自新”的机会。只要总线环境恢复正常，节点就能慢慢回到Error Active状态。
4.4 实战建议
最后，我给大家几个实战中的建议：
- 监控错误计数器：在诊断工具里，一定要能读出每个节点的TEC和REC值。这是定位总线问题的第一手信息。
- 区分错误类型：如果全是CRC错误，多半是电磁干扰。如果全是位错误，可能是收发器或电源问题。如果全是格式错误，先查晶振和位时序配置。
- 注意Bus Off恢复：有些应用场景不允许节点长时间离线，比如安全气囊系统。这时候需要软件主动干预，比如在检测到Bus Off后，手动复位CAN控制器。
- 不要忽视被动错误：很多工程师只关注Bus Off，觉得Error Passive无所谓。其实Error Passive状态下的节点，发送的被动错误帧可能会被其他节点忽略，导致数据丢失。
嗯，关于CAN总线的错误处理，今天就聊到这儿。下一章咱们讲讲CAN总线故障定位的实战工具和方法，到时候我会分享一些我亲手用过的调试案例。