第4章 CAN总线错误处理

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

各位好，今天我们来聊聊CAN总线里一个特别重要的话题——错误处理。说实话，我刚开始做CAN开发时，总觉得错误处理是“锦上添花”的东西。直到有一次，我在一个车载项目中，因为没处理好总线关闭状态，导致整个ECU“失联”了三个小时……嗯，从那以后，我再也不敢小看这个章节了。

CAN总线的设计哲学很有意思：它不追求“永不犯错”，而是追求“犯错后能快速恢复”。你想想看，在汽车这种高噪声环境里，电磁干扰、线缆老化、接插件松动，错误几乎是必然的。所以CAN协议设计了一套非常精巧的错误检测与恢复机制。

CAN协议定义了五种错误类型。我个人习惯把它们分成两类：“我能检测到的”和“别人能检测到的”。咱们一个一个来看。

这是最直观的错误。发送节点在发送位的同时，会监控总线电平。如果它发送的是显性位（0），但读回来是隐性位（1），那就说明出问题了。反之亦然。

关键点：仲裁阶段不会触发位错误。因为仲裁时多个节点同时发送显性位是正常行为。

我在项目中遇到过一种情况：某个节点的CAN收发器驱动能力不足，导致显性位电平不够低，被误判为隐性位。排查了整整两天才找到原因。

CAN协议规定：连续发送5个相同电平的位后，必须插入一个相反电平的填充位。如果接收节点检测到连续6个相同电平，就报填充错误。

为什么要这么做？说白了就是为了保证时钟同步。没有电平跳变，接收节点的锁相环就会失锁。我曾经见过一个新手工程师，在自定义CAN帧时手动去掉了填充位，结果整个网络直接瘫痪。

发送节点会计算15位CRC校验码，放在帧尾。接收节点重新计算一遍，如果不匹配，就报CRC错误。

这里有个细节：CRC只覆盖数据场和CRC场本身，不覆盖SOF、仲裁场、控制场。为什么？因为这些字段在仲裁时可能被修改。嗯，设计者考虑得很周全。

如果接收节点检测到帧格式中的固定位（比如CRC分隔符、ACK分隔符、EOF等）不是隐性电平，就报格式错误。

我记得有一次调试，发现某个节点总是报格式错误。后来发现是它的晶振精度不够，导致位采样点偏移，把EOF的最后一个位采样成了显性电平。换了个高精度晶振就解决了。

发送节点在ACK槽位等待一个显性位。如果它读到的是隐性位，说明没有其他节点正确接收到该帧，于是报应答错误。

注意：应答错误不代表帧内容有错，只是说明没有接收节点确认。比如总线上只有一个节点在发送，没有接收节点，就会一直报应答错误。

每个CAN节点都有两个计数器：发送错误计数器（TEC）和接收错误计数器（REC）。根据这两个计数器的值，节点处于三种状态之一。

状态	条件	行为
主动错误	TEC ≤ 127 且 REC ≤ 127	正常通信，检测到错误时发送主动错误标志（6个显性位）
被动错误	TEC > 127 或 REC > 127	只能发送被动错误标志（6个隐性位），且发送前需等待8个隐性位
总线关闭	TEC > 255	完全脱离总线，不发送任何帧

计数规则其实不复杂，但细节很多。我总结成几句话：

避坑指南：我曾经在项目中遇到一个节点频繁进入被动错误状态。排查后发现是它的CAN控制器配置错误，导致位时序参数不对，总是在采样点附近采样到噪声。调整了同步跳转宽度（SJW）后问题解决。

你想想看，如果一个节点频繁出错，它会从主动错误逐渐降级到被动错误，最后被总线关闭。这其实是一种“故障隔离”机制——不让一个坏节点拖垮整个网络。

但这里有个坑：被动错误节点发送的被动错误标志是隐性位，其他节点可能检测不到。所以被动错误节点实际上处于“半死不活”的状态——它以为自己还在通信，但别人可能已经忽略它了。

我建议在应用层增加一个心跳机制。每个节点定期发送一个心跳帧，如果连续几个周期没收到某个节点的心跳，就认为它出问题了。这样即使CAN控制器进入了被动错误状态，上层应用也能及时发现。

最后，分享几个我在项目中积累的经验：

不要依赖硬件自动恢复。有些CAN控制器在总线关闭后会自动尝试恢复（等待128个11个隐性位）。但这个过程可能长达几百毫秒，对于实时性要求高的系统来说太长了。
监控错误计数器。在诊断协议中，我通常会读取TEC和REC的值。如果发现某个节点的错误计数器持续增长，就要提前干预，而不是等到它总线关闭。
区分瞬时错误和永久错误。如果错误计数器增长后又降下来，说明是瞬时干扰。如果只增不减，说明硬件有问题（比如收发器损坏、线缆短路）。

好了，关于CAN总线的错误处理，我们就聊到这里。下一章我会讲CAN的位时序与同步，那是理解CAN通信稳定性的关键。咱们下次见。