3. CAN错误处理：错误类型、错误状态机、总线关闭恢复机制
大家好，我是你们的嵌入式系统讲师。今天我们来聊聊CAN总线里一个特别重要、也特别容易被忽视的话题——错误处理。
说实话，我刚开始做车载网络那会儿，觉得CAN通信嘛，不就是发发报文、收收数据？直到有一次，一台测试车的仪表盘疯狂报错，总线直接瘫痪。排查了整整两天，最后发现是一个节点的CAN收发器出了点小毛病，触发了总线关闭机制。从那以后，我再也不敢小看错误处理这块了。
3.1 错误类型：CAN总线上的“五宗罪”
CAN协议定义了五种错误类型。你想想看，一个通信协议能定义这么细的错误分类，说明它对自己的可靠性要求有多高。
3.4.1 位错误（Bit Error）
这是最基础的一种错误。说白了，就是节点发送了一个位，但监控到的总线电平跟自己发的不一样。
举个例子：你发了个显性位（逻辑0），但总线上读回来却是隐性位（逻辑1）。那肯定出问题了。我习惯把这种错误叫做“自己打自己脸”——自己说的话，自己都不认了。
关键点：仲裁期间不会触发位错误。因为仲裁时多个节点同时发送，电平冲突是正常的。只有赢得仲裁的节点，才会监控自己的发送位。
3.4.2 填充错误（Stuff Error）
CAN协议有个规矩：连续发送5个相同电平的位后，必须插入一个相反电平的位。这叫位填充机制。
如果接收节点发现连续6个位都是相同的电平，那就报填充错误。嗯，这里要注意：CRC界定符和ACK界定符这些固定格式的场，是不做位填充的。
我曾经遇到过一个案例：某供应商的CAN控制器芯片有bug，在特定温度下会漏掉填充位。结果就是总线上一片混乱，所有节点都在报填充错误。那次教训让我明白——硬件选型真的不能只看价格。
3.4.3 CRC错误（CRC Error）
CRC（循环冗余校验）是检查数据完整性的利器。发送节点会计算一个15位的CRC校验码，放在CRC场里。接收节点收到后，用自己的算法重新算一遍。
如果算出来的结果跟收到的CRC码不一致，那就报CRC错误。说白了，就是数据在传输过程中被“污染”了。
我个人习惯在开发阶段，故意在发送端篡改一个数据位，看看接收端能不能正确检测到CRC错误。这是个很好的自测手段。
3.4.4 格式错误（Form Error）
CAN帧的某些场有固定的格式。比如CRC界定符必须是隐性位，ACK界定符也必须是隐性位。如果检测到这些固定格式的位是显性位，那就报格式错误。
这种错误其实不太常见。但一旦出现，往往意味着硬件时序有问题，或者总线受到了强干扰。
3.4.5 应答错误（ACK Error）
发送节点在ACK槽发送隐性位，然后等待接收节点拉成显性位来确认。如果发送节点没检测到显性位，就报应答错误。
为什么会这样？最常见的原因是总线上没有其他节点在监听。或者接收节点因为某种原因没有正确应答。
小技巧：调试时如果发现某个节点频繁报应答错误，先检查它的终端电阻和总线连接。我遇到过好几次，都是因为线束接触不良导致的。
3.2 错误状态机：从“好孩子”到“坏孩子”
每个CAN节点内部都有一个错误计数器。发送错误计数器（TEC）和接收错误计数器（REC）。这两个计数器决定了节点处于什么状态。
状态机分为三种：错误主动、错误被动、总线关闭。我习惯把它们叫做“好孩子”、“坏孩子”和“被开除的孩子”。
| 状态 | 条件 | 行为特征 |
|---|---|---|
| 错误主动 | TEC ≤ 127 且 REC ≤ 127 | 正常通信，检测到错误时发送主动错误帧（6个显性位） |
| 错误被动 | TEC > 127 或 REC > 127 | 只能发送被动错误帧（6个隐性位），不能主动干扰总线 |
| 总线关闭 | TEC > 255 | 完全断开与总线的连接，不发送任何数据 |
你想想看，为什么要有这个状态机？其实是为了“保护总线”。一个频繁出错的节点，如果不加以限制，它会不断发送错误帧，把整个总线都拖垮。
我记得有个项目，ECU的软件里有个bug，导致它在特定条件下疯狂发送错误帧。结果整个CAN网络都瘫痪了，其他节点根本没法通信。后来我们加了个看门狗机制，一旦检测到节点频繁进入错误被动状态，就强制复位。
3.2.1 错误主动状态
这是节点的正常工作状态。TEC和REC都在127以下。节点检测到错误时，会发送主动错误帧——6个连续的显性位。这个错误帧会覆盖总线上其他节点的数据，强制所有节点都注意到这个错误。
说白了，错误主动状态下的节点，是个“强势”的节点。它发现错误就大声喊出来，不怕干扰别人。
3.2.2 错误被动状态
当TEC或REC超过127，节点就进入错误被动状态。这时候它发送的错误帧是6个隐性位。隐性位不会覆盖显性位，所以它不会干扰其他节点的通信。
嗯，这里要注意：错误被动节点在发送数据前，需要等待8个隐性位的间隔。这叫“暂停传输”（Suspend Transmission）。说白了，就是让这个“坏孩子”先闭嘴一会儿，让其他节点先说话。
避坑指南：我曾经遇到过一个设计，错误被动节点在暂停传输期间，没有正确处理接收到的报文。结果导致接收缓冲区溢出，进一步加剧了错误计数。这是个典型的“雪崩效应”。
3.2.3 总线关闭状态
当TEC超过255，节点就进入总线关闭状态。这时候节点完全断开与总线的连接，不发送任何数据，也不接收任何数据。说白了，就是被“开除”了。
为什么会这样？因为TEC只增不减，说明这个节点一直在发送错误。与其让它继续破坏总线，不如让它彻底闭嘴。
3.3 总线关闭恢复机制：怎么“复学”？
节点进入总线关闭状态后，怎么恢复？有两种方式：自动恢复和手动恢复。
3.3.1 自动恢复
大多数CAN控制器都支持自动恢复。节点在总线关闭后，会等待128个连续的11个隐性位（即128个总线空闲序列）。如果检测到这么长的空闲时间，节点就认为总线已经恢复正常，自动从总线关闭状态恢复到错误主动状态。
我个人习惯把这个等待时间叫做“反省期”。节点需要证明自己“冷静”了，才能重新加入总线。
3.3.2 手动恢复
有些应用场景下，自动恢复可能不合适。比如安全关键系统，节点出错后需要人工介入排查原因。这时候可以通过软件复位或硬件复位来强制恢复。
我曾经做过一个项目，要求节点在总线关闭后，必须通过诊断命令才能恢复。这样做的目的是确保每次总线关闭都有记录，方便后续分析。
关键点：自动恢复的等待时间取决于总线波特率。波特率越高，等待时间越短。比如500kbps的波特率下，128个空闲位大约需要256微秒。但要注意，这个时间是从节点检测到总线空闲开始算的，不是从进入总线关闭开始算的。
3.4 实战建议：如何设计健壮的错误处理
讲了这么多理论，最后给几点实战建议：
- 监控错误计数器：在应用层定期读取TEC和REC的值。如果发现某个计数器持续增长，就要警惕了。我习惯在诊断服务里加一个错误计数器读取功能。
- 设置错误阈值：不要等到节点进入总线关闭才处理。可以在TEC超过200时就触发警告，提前干预。
- 区分错误类型：位错误和填充错误往往跟硬件相关，CRC错误可能跟干扰相关。记录错误类型有助于快速定位问题。
- 测试恢复机制：在开发阶段，故意让节点进入总线关闭状态，验证自动恢复和手动恢复是否正常工作。我每次做项目都会写一个测试用例来验证这个功能。
最后说一句：CAN的错误处理机制设计得非常精妙。它既保证了单个节点出错时不会拖垮整个总线，又给了节点恢复的机会。理解并善用这些机制，是做好车载网络开发的基本功。