4. CAN/LIN通信调试：从收发器到调度表

通信调试，说白了就是让VCU能跟车上其他节点“说上话”。CAN和LIN是两条腿，缺一不可。我刚开始调CAN的时候，总觉得只要把报文发出去就行，结果被错误帧和Bus-Off折磨得够呛。这一章，咱们就把这些坑一个个填上。

4.1 CAN收发器配置与TJA1043状态机

收发器是VCU的“嘴巴”和“耳朵”。TJA1043是咱们最常用的CAN收发器之一，它内部有个状态机，控制着功耗和通信模式。搞不懂这个状态机，你连CAN都唤醒不了。

TJA1043的四个核心状态：

状态切换的关键点：

• Normal → Standby： 通过SPI或硬件引脚设置。我建议在VCU下电前，先发一条“准备休眠”的CAN报文，再切到Standby。
• Standby → Normal： 检测到CAN总线上的唤醒报文（通常为特定ID或显性电平）。
• Standby → Sleep： 需要满足“总线空闲”且“无唤醒请求”的条件，持续一段时间。

4.2 CAN报文发送与接收调试

报文收发是基本功，但调试起来往往最费时间。你想想看，一个报文发不出去，是硬件问题还是软件问题？是ID冲突还是波特率不对？

发送调试步骤：

1. 检查波特率： 用示波器量CAN_H和CAN_L的差分信号，一个位的时间应该是1/波特率。比如500kbps，位时间就是2μs。
2. 检查ID： 确保发送ID没有被其他节点占用，且符合项目定义的DBC文件。
3. 检查发送缓冲区： 很多MCU的CAN控制器有多个邮箱，确保你写的邮箱没有被锁定或优先级设置错误。
4. 检查总线状态： 如果总线处于Bus-Off，发送会被禁止。

接收调试步骤：

1. 配置过滤器： 我习惯把过滤器设置为“接收所有报文”来排查问题，确认能收到后再逐步收紧。
2. 检查中断： 确保CAN接收中断已使能，且中断优先级足够高。
3. 检查FIFO溢出： 如果接收报文频率很高，而你的中断服务程序处理太慢，FIFO会溢出，导致丢帧。

// 发送CAN报文
CAN_TxHeaderTypeDef TxHeader;
uint8_t TxData[8] = {0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08};
uint32_t TxMailbox;

TxHeader.StdId = 0x123;          // 标准ID
TxHeader.ExtId = 0;              // 扩展ID
TxHeader.IDE = CAN_ID_STD;       // 标准帧
TxHeader.RTR = CAN_RTR_DATA;     // 数据帧
TxHeader.DLC = 8;                // 数据长度

if (HAL_CAN_AddTxMessage(&hcan, &TxHeader, TxData, &TxMailbox) != HAL_OK)
{
    // 发送失败处理
    Error_Handler();
}

4.3 CAN错误帧与Bus-Off处理

错误帧是CAN通信的“红灯”，Bus-Off则是“封号”。为什么会这样？说白了，就是某个节点发现总线上的数据跟自己预期的不一致，于是主动拉错，告诉所有人“刚才那帧有问题”。

常见错误类型：

Bus-Off处理策略：

当节点的发送错误计数器超过255，它会自动进入Bus-Off状态，不再参与总线通信。这时候，你必须手动恢复。

• 被动恢复： 检测到128次11个连续的隐性位（总线空闲），节点自动恢复。但这个过程很慢，不适合实时系统。
• 主动恢复： 我建议在VCU中实现一个“Bus-Off快速恢复”机制。检测到Bus-Off后，立即复位CAN控制器，并重新初始化。

4.4 LIN通信调度表调试

LIN通信是CAN的“小弟”，成本低，速度慢，主要用于车窗、车门、座椅等低速设备。LIN通信的核心是“主从架构”，主节点（通常是VCU或BCM）负责调度，从节点（如车窗电机）只能应答。

调度表的结构：

调度表本质上是一个“时间表”，主节点按照这个表依次发送帧头，从节点在帧头后发送响应。我习惯把调度表设计成循环执行的，每个周期包含所有需要通信的从节点。

调试要点：

• 检查帧间隔： LIN总线要求帧与帧之间至少有“帧间空间”，通常是几个位的长度。如果调度表安排得太紧，从节点来不及处理，会导致通信失败。
• 检查从节点响应超时： 主节点发送帧头后，必须在规定时间内收到从节点的响应。我一般设置10ms的超时，超时后重发一次，如果还失败，则记录故障。
• 检查唤醒序列： LIN总线唤醒时，主节点需要发送一个“唤醒脉冲”（显性电平持续250μs~5ms）。如果脉冲宽度不对，从节点可能无法唤醒。