4、CAN总线错误帧与过载帧：错误帧类型、错误帧产生机制、过载帧作用、总线关闭状态
大家好，我是老周。做嵌入式这些年，尤其是搞电梯控制系统，我见过太多因为CAN总线错误处理不当导致的「灵异事件」——电梯莫名其妙急停、通讯时断时续、甚至整个系统瘫痪。说白了，很多问题都出在错误帧和过载帧的理解上。今天咱们就把这块硬骨头啃下来。
4.1 错误帧的类型
CAN总线上的错误帧，其实就两种：主动错误帧和被动错误帧。嗯，这里要注意，很多人以为错误帧只有一种，其实不是。
| 错误帧类型 | 发送条件 | 标志位形式 | 总线影响 |
|---|---|---|---|
| 主动错误帧 | 节点处于主动错误状态 | 6个连续显性位 | 强制破坏当前报文 |
| 被动错误帧 | 节点处于被动错误状态 | 6个连续隐性位 | 仅当总线空闲时生效 |
我刚开始搞电梯CAN通讯时，就踩过这个坑。当时发现某个节点老是发错误帧，但波形上看又不像标准的6个显性位。后来一查，原来是节点已经进入被动错误状态了，发的被动错误帧是隐性位，示波器上根本看不明显。你想想看，这要是没搞清楚，排查三天三夜也找不到原因。
4.2 错误帧的产生机制
错误帧不是无缘无故冒出来的。CAN控制器内部有一套严格的错误检测机制，说白了就是「五道关卡」：
- 位错误：发送节点监控总线，发现自己发的和总线上的不一致。比如你发了个显性位，但总线上是隐性，那就出问题了。
- 填充错误：CAN协议规定，连续5个相同电平后必须插入一个相反电平。如果接收方发现连续6个相同电平，直接报错。
- CRC错误：接收方计算的CRC校验和与发送方的不匹配。这个在电梯长距离通讯中特别常见，线缆质量不好就容易出。
- 格式错误：帧格式不对，比如固定为隐性位的位变成了显性。我记得有一次调试，发现某个国产CAN收发器在高温下会把EOF位拉低，导致格式错误频发。
- 应答错误：发送方没收到应答信号。说白了就是没人理它。
核心要点：任何节点检测到上述五种错误之一，就会立即发送错误帧。这个错误帧会在当前位结束后发出，破坏正在传输的报文，迫使所有节点重新仲裁。
为什么会设计成「立即破坏」？我个人习惯的理解是：CAN总线讲究的是「宁可错杀一千，不可放过一个」。一旦发现错误，必须立刻让所有人知道，防止错误数据被当成有效数据使用。这在电梯系统里尤其重要——你想想，如果楼层信息错了，电梯可能把门开在两层楼之间。
4.3 过载帧的作用
过载帧和错误帧长得有点像，但用途完全不同。过载帧说白了就是节点在喊：「慢点慢点，我跟不上了！」
过载帧的产生条件有两个：
- 接收节点内部缓冲区满了，来不及处理，需要发送方暂停一下。
- 总线空闲时，检测到第一个显性位之前有个干扰信号（这个情况比较少见）。
我在项目中遇到过一件事：某款电梯控制板用的MCU主频较低，CAN接收中断处理时间太长。当电梯高速运行时，多个轿厢同时上报状态，这个板子就频繁发过载帧。结果整个CAN网络效率骤降，通讯延迟从原来的2ms飙升到50ms。后来怎么解决的？把接收中断优先级调高，同时优化了数据处理流程。
实战建议：过载帧是系统的「求救信号」。如果你发现总线上过载帧很多，别急着查硬件，先看看是不是某个节点的处理能力不够。我曾经遇到过，换了个性能更强的MCU，过载帧就消失了。
4.4 总线关闭状态
这是CAN节点最严重的状态，相当于被「踢出群聊」了。
CAN节点有三个状态：主动错误、被动错误、总线关闭。状态切换的逻辑是这样的：
- 每个节点有两个计数器：发送错误计数器（TEC）和接收错误计数器（REC）。
- TEC或REC超过127，节点从主动错误进入被动错误状态。
- TEC超过255，节点进入总线关闭状态。
⚠️ 重要警告：总线关闭状态下，节点完全脱离总线，既不发送也不接收任何数据。要恢复，必须等待128个总线空闲信号（11个隐性位算一个空闲信号），或者硬件复位。在电梯系统中，这意味着该节点彻底失联——比如某个楼层的呼梯按钮全部失效。
我曾经处理过一个现场问题：某栋写字楼的电梯，每天早上8点到9点高峰期，总有几个楼层的按钮没反应。查了三天，发现是某个楼层控制器的CAN收发器有轻微短路，导致它频繁发送错误帧，TEC一路飙升到255，然后总线关闭。等过了高峰期，它又自己恢复了。你想想看，这种间歇性故障多难排查。
所以我的建议是：在设计电梯CAN网络时，一定要给每个节点设计「总线关闭恢复机制」。比如在检测到总线关闭后，主动延迟一段时间再复位，而不是立即复位。否则所有节点同时复位，总线会乱成一锅粥。
嗯，关于错误帧和过载帧，今天就聊到这儿。记住一句话：错误帧是「发现问题」，过载帧是「请求帮助」，总线关闭是「彻底掉线」。搞清楚了这三者的区别和联系，你在电梯CAN总线调试中至少能少走一半弯路。