第4章 CAN总线错误处理

第4章 CAN总线错误处理：错误类型、错误计数器、错误状态机、总线关闭恢复

各位同学，咱们今天聊聊CAN总线的错误处理。说实话，这是CAN协议里最核心、也最容易让人头疼的部分。我刚开始做CAN开发那会儿，就被总线关闭坑过好几次。嗯，咱们一步步来拆解。

4.1 错误类型：CAN总线上的五种“事故”

CAN协议定义了五种错误类型。你想想看，一个通信系统要能在恶劣环境下稳定工作，必须能识别各种异常。这五种错误，我挨个说。

4.1.1 位错误（Bit Error）

这个最简单。发送节点在总线上发送一个位，同时监控总线电平。如果发的是显性（0），却读到隐性（1），或者反过来，那就出问题了。我在项目中遇到过，某次线束接触不良，导致发送节点频繁报位错误，查了半天才发现是接插件松了。

4.1.2 填充错误（Stuff Error）

CAN协议规定，连续发送5个相同电平后，必须插入一个相反电平。这叫位填充。如果接收节点发现连续6个相同电平，那就是填充错误。说白了，这是为了保持同步。我记得有次调试，一个节点因为晶振漂移，发送数据时填充位位置算错了，整个网络都被它带偏。

4.1.3 循环冗余校验错误（CRC Error）

每个CAN帧尾部都有15位CRC校验码。接收节点会重新计算CRC，跟发送的CRC比对。对不上？那就是CRC错误。这个错误最常见于总线干扰严重的场景。我建议你在做EMC测试时，重点关注这个错误计数。

4.1.4 帧格式错误（Form Error）

CAN帧的某些位段是固定电平的。比如CRC界定符必须是隐性位。如果这些固定位段出现错误电平，就是帧格式错误。嗯，这里要注意：这种错误通常意味着协议实现有bug，而不是物理层问题。

4.1.5 应答错误（ACK Error）

发送节点在ACK槽位等待接收节点拉低总线（显性）。如果没人应答，那就是ACK错误。为什么会这样？要么总线上没有其他节点，要么接收节点都处于错误被动状态，无法发送应答。

4.2 错误计数器：两个“记分牌”

每个CAN节点都有两个错误计数器：发送错误计数器（TEC）和接收错误计数器（REC）。它们不是简单的加减，而是有一套规则。

事件	TEC变化	REC变化
发送成功	-1	不变
接收成功	不变	-1（若REC>0）
发送错误	+8	不变
接收错误	不变	+1
主动错误标志	+8	不变

注意看，发送错误一次加8分，接收错误一次只加1分。为什么？因为发送节点对总线的影响更大。你想想看，一个乱发数据的节点，比一个收错数据的节点危害大多了。

关键点：错误计数器不是无限增长的。TEC最大255，REC最大127。超过这个值，计数器就饱和了。

4.3 错误状态机：三种状态切换

CAN节点根据错误计数器的值，处于三种状态之一。我习惯把这个状态机画成一张图，每次调试都对照着看。

4.3.1 错误主动（Error Active）

这是正常状态。TEC < 128 且 REC < 128。节点可以正常收发，检测到错误时发送主动错误标志（6个显性位）。说白了，就是“我错了，我大声喊出来”。

4.3.2 错误被动（Error Passive）

当 TEC ≥ 128 或 REC ≥ 128 时，节点进入错误被动状态。这时候，节点发送错误标志时只能发6个隐性位。为什么？因为怕影响其他节点。我曾经调试过一个项目，某个节点频繁进入错误被动，导致它的报文总是被其他节点覆盖，数据一直收不全。

4.3.3 总线关闭（Bus Off）

当 TEC > 255 时，节点进入总线关闭状态。这时候，节点完全脱离总线，不发送任何数据，也不接收任何数据。嗯，这是最严重的状态。

避坑指南：我曾经遇到过一个案例，某个节点因为软件bug，在总线关闭后没有正确执行恢复流程，导致整个系统瘫痪。记住：总线关闭不是终点，恢复机制同样重要。

4.4 总线关闭恢复：如何“起死回生”

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

4.4.1 自动恢复

节点检测到总线空闲状态，连续出现128次11个隐性位（即128个总线空闲序列），就会自动恢复。这个过程不需要软件干预，完全由CAN控制器硬件完成。我建议你在设计时，把自动恢复时间考虑进去。128个位时间，在500kbps速率下大约是256微秒。

4.4.2 手动恢复

有些应用场景，比如安全关键系统，不允许节点自动恢复。这时候需要软件主动复位CAN控制器。我习惯在代码里加一个恢复计数器，记录节点进入总线关闭的次数。如果短时间内频繁关闭，说明问题严重，需要报警。

// 总线关闭恢复示例代码
void CAN_BusOffRecovery(void)
{
    // 检查是否处于总线关闭状态
    if (CAN_GetStatus() & CAN_STATUS_BUSOFF)
    {
        // 记录总线关闭次数
        g_busOffCount++;
        
        if (g_busOffCount > MAX_BUSOFF_COUNT)
        {
            // 频繁总线关闭，触发系统报警
            System_Alarm(ALARM_CAN_BUSOFF);
            return;
        }
        
        // 手动复位CAN控制器
        CAN_DeInit();
        delay_ms(10);  // 等待复位完成
        CAN_Init(&canConfig);
        
        // 清除错误计数器
        CAN_ClearErrorCounters();
        
        printf("CAN总线已恢复\n");
    }
}

个人经验：我建议你在测试阶段，故意制造总线关闭场景，验证恢复逻辑是否可靠。比如短接CAN_H和CAN_L，或者拔掉终端电阻。这些操作在实车上可能不会遇到，但测试时一定要覆盖。

4.5 实战建议：错误处理的测试策略

说了这么多理论，咱们聊聊怎么测试。我总结了几条经验：

错误注入测试：用CAN工具（比如PCAN、Kvaser）主动注入各种错误，观察节点的反应。我习惯先注入位错误，再注入CRC错误，最后测试总线关闭恢复。
边界条件测试：测试错误计数器在127、128、255这些边界值时的行为。很多bug就出在边界上。
恢复时间测试：测量从总线关闭到恢复的时间，确保满足系统要求。我记得有个项目要求恢复时间小于1ms，结果发现硬件自动恢复需要256μs，加上软件处理时间，差点超标。
压力测试：持续注入错误，看节点能否稳定运行。我曾经连续跑过72小时的压力测试，发现某个芯片在高温下错误计数异常增长。

好了，关于CAN总线错误处理，咱们就聊到这儿。下一章我会讲CAN的位定时与同步，那是理解CAN通信速率的关键。有问题随时问我。

📚 课程目录