3. CAN总线配置实战：CAN控制器初始化、报文收发与错误处理

好，咱们直接进入正题。CAN总线配置，说白了就是让芯片上的CAN控制器能正常干活。很多刚入行的工程师觉得这步就是填几个寄存器，其实不然。我在项目里见过太多因为初始化参数没配好，导致整车网络通信不稳定的案例。今天咱们就把这块掰开揉碎了讲清楚。

3.1 CAN控制器初始化——波特率与采样点

初始化是第一步，也是最容易踩坑的一步。核心就两个参数：波特率和采样点。

3.1.1 波特率计算

CAN总线的波特率由三个东西决定：时钟源频率、分频系数和时间段配置。公式很简单：

波特率 = 时钟频率 / (分频系数 × (Sync_Seg + Prop_Seg + Phase_Seg1 + Phase_Seg2))

嗯，这里要注意，不同厂家的MCU叫法可能不一样。比如NXP的S32K系列叫PSEG1和PSEG2，而TI的TMS570叫TSEG1和TSEG2。但本质是一样的。

我个人习惯先确定目标波特率，再反推分频系数。比如车载网络常用500kbps，时钟源8MHz，那分频系数和时间段就得搭配好。下面这张表是我常用的配置参考：

3.1.2 采样点设置

采样点决定了在位的哪个位置读取电平。为什么重要？因为总线有传输延迟，采样点太靠前或太靠后，都可能读到错误电平。

我曾经在一个项目中，两路CAN节点距离超过5米，波特率500kbps，默认采样点设在75%。结果总线频繁出现位错误。后来我把采样点调到87.5%，问题就解决了。你想想看，采样点越靠后，留给信号稳定建立的时间就越长。

3.1.3 初始化代码示例

以S32K144为例，初始化CAN控制器的核心代码大概长这样：

// CAN0 初始化，500kbps，采样点 87.5%
void CAN0_Init(void) {
    // 1. 使能时钟
    PCC->PCCn[PCC_FlexCAN0_INDEX] |= PCC_PCCn_CGC_MASK;
    
    // 2. 复位CAN模块
    CAN0->MCR |= CAN_MCR_SOFTRST_MASK;
    while(CAN0->MCR & CAN_MCR_SOFTRST_MASK);
    
    // 3. 进入冻结模式
    CAN0->MCR |= CAN_MCR_FRZ_MASK | CAN_MCR_HALT_MASK;
    while(!(CAN0->MCR & CAN_MCR_FRZ_ACK_MASK));
    
    // 4. 配置波特率：时钟8MHz，分频2，时间段 1+3+3+1
    CAN0->CTRL1 = CAN_CTRL1_PRESDIV(1)   // 分频系数 = 2
                 | CAN_CTRL1_PROPSEG(2)   // Prop_Seg = 3 Tq
                 | CAN_CTRL1_PSEG1(2)     // Phase_Seg1 = 3 Tq
                 | CAN_CTRL1_PSEG2(0)     // Phase_Seg2 = 1 Tq
                 | CAN_CTRL1_RJW(0);      // 同步跳转宽度 = 1 Tq
    
    // 5. 退出冻结模式
    CAN0->MCR &= ~(CAN_MCR_FRZ_MASK | CAN_MCR_HALT_MASK);
    while(CAN0->MCR & CAN_MCR_FRZ_ACK_MASK);
}

3.2 CAN报文收发配置

初始化搞定后，就该让CAN控制器收发报文了。这里涉及邮箱（Mailbox）或消息缓冲（Message Buffer）的配置。

3.2.1 发送配置

发送报文，说白了就是把数据塞进一个空闲的发送邮箱，然后触发发送。步骤很简单：

1. 找一个状态为空闲（Inactive/Empty）的邮箱
2. 写入ID、数据长度（DLC）、数据内容
3. 设置发送请求位
4. 等待发送完成中断或轮询状态

我习惯用中断方式发送，这样CPU不用傻等。下面是一个发送函数的例子：

// CAN0 发送标准帧，ID=0x123，数据=0x01 0x02 0x03 0x04
uint8_t CAN0_SendMsg(uint32_t id, uint8_t *data, uint8_t len) {
    uint8_t mb_idx;
    
    // 找一个空闲邮箱（这里用邮箱0）
    mb_idx = 0;
    
    // 写ID和DLC
    CAN0->MB[mb_idx].CS = CAN_CS_CODE(0x0C)  // 写数据就绪
                         | CAN_CS_IDE(0)      // 标准帧
                         | CAN_CS_RTR(0)      // 数据帧
                         | CAN_CS_DLC(len);
    CAN0->MB[mb_idx].ID = CAN_ID_STD(id);
    
    // 写数据
    for(uint8_t i = 0; i < len; i++) {
        CAN0->MB[mb_idx].DATA_BYTE[i] = data[i];
    }
    
    // 触发发送
    CAN0->IFLAG1 |= (1 << mb_idx);
    CAN0->MB[mb_idx].CS |= CAN_CS_CODE(0x08);  // 发送请求
    
    return 0;
}

3.2.2 接收配置

接收配置比发送稍微复杂一点，因为要处理滤波。如果不做滤波，所有报文都会进邮箱，CPU会被频繁中断。

我个人建议：能用硬件滤波就用硬件滤波。比如只接收ID范围在0x100~0x1FF的报文，或者只接收特定几个ID。这样能大幅降低CPU负载。

3.3 CAN错误处理与Bus-Off恢复

这部分是实战中的重头戏。CAN控制器内部有发送错误计数器（TEC）和接收错误计数器（REC）。根据这两个计数器的值，节点会处于三种状态：

3.3.1 错误处理策略

当节点进入被动错误状态时，其实已经是个隐患了。我一般会在中断里监控错误计数器，一旦超过某个阈值（比如96），就主动记录日志，方便后续排查。

真正要命的是Bus-Off。节点一旦Bus-Off，就彻底失联了。为什么会这样？最常见的原因是：

• 波特率不匹配——两个节点波特率差一点，就会持续产生位错误
• 总线短路——CAN_H和CAN_L短路，或者对电源/地短路
• 终端电阻问题——缺少终端电阻或电阻值不对

3.3.2 Bus-Off恢复机制

CAN协议规定了Bus-Off恢复流程：节点需要检测到128次连续的11个隐性位（即128个空闲帧），才能自动恢复。这个过程叫Bus-Off Recovery。

但实际项目中，我很少依赖硬件自动恢复。为什么？因为如果导致Bus-Off的根本原因没解决，恢复后马上又会Bus-Off，形成震荡。我曾经在一个项目中遇到过这种情况：一个节点因为线束接触不良，反复进入Bus-Off，每次恢复后发几帧又挂了，整个网络都被它拖慢。

3.3.3 Bus-Off恢复代码示例

// Bus-Off 中断处理
void CAN0_BusOff_IRQHandler(void) {
    static uint8_t recover_count = 0;
    
    // 1. 记录错误
    log_error("CAN0 Bus-Off detected!");
    
    // 2. 停止发送
    CAN0->MCR |= CAN_MCR_HALT_MASK;
    
    // 3. 等待总线空闲
    delay_ms(100);
    
    // 4. 复位CAN控制器
    CAN0->MCR |= CAN_MCR_SOFTRST_MASK;
    while(CAN0->MCR & CAN_MCR_SOFTRST_MASK);
    
    // 5. 重新初始化
    CAN0_Init();
    
    // 6. 检查恢复次数
    recover_count++;
    if(recover_count >= 3) {
        // 永久关闭节点
        CAN0_DeInit();
        set_fault_code(0x1234);  // 上报故障码
        recover_count = 0;
    }
}

3.4 本章知识体系总览

下面这张图把本章的核心逻辑串起来了，你可以对照着回顾一下：

嗯，以上就是CAN总线配置实战的核心内容。从初始化到收发，再到错误处理，每一步都有讲究。你在实际项目中遇到问题时，可以回头看看这些要点，尤其是采样点和Bus-Off恢复策略，这两个是现场排查的高频考点。