can总线rollingcounter_CAN总线错误分析与解决

CAN总线错误分析与解决

背景

写这篇文章是因为我看到网上介绍CAN总线错误处理的文章，清一色的都是生搬照抄教科书或是数据文档的内容，特别是国内很难找到一些有价值的内容，这让一些真正有需要的人很苦恼，包括我自己。这篇不打算对CAN的错误处理机制做进一步的探讨，而是从实际工作中碰到的具体问题来分析一些常见的CAN总线错误和解决办法。

CAN节点数据收发过程

了解CAN节点在总线上数据上的收发过程很重要，之前的一篇文章讲解了一些CAN总线的错误处理机制，但是那些都是理论上的东西，如果不深入了解CAN总线上的数据收发过程，理解那些理论的东西难免有些晦涩。

我们知道CAN总线上的每个节点往总线上发送数据的同时会同时读取总线上的数据，并与自己发送的数据作对比。

CAN信息发送成功后，在这个间隙内，接收节点可以准备要回复的信息，也就是把应答场填充为显性0，在发送时其为隐性1应答过程可能如下：当信息传输到ACK前的Del时，可以认为信息已经传输完毕，接收节点也接收到了足够的信息来检测接收的信息是否正确，所以这时接收节点就会检测信号是否正确，如果正确，就将ACK置位为显性0，注意这时，发送节点因为还在发送而接收节点又将ACK信息置位为1，所以它就会在回读时检测到ACK为0，判断接收成功。注意：这其中有个接收节点用显性覆盖隐性---覆盖ACK位的过程,覆盖+回读。

ACK前后各加一个Del，就是为了考虑到时间误差，让接收节点有足够的时间对ACK确认。这个过程说明，CAN发送是个双向互动的过程，发送节点一边发送，一边对节点进行回收确认数据正确，而接收节点也时刻接收，并在正确的时间将ACK设置为1。

CAN总线错误

CAN总线错误分别有发送和接收错误计数，计数达到一定的累计以后就会产生CAN BUS OFF, 这说明CAN总线上出现了严重的错误。如下图CAN总线产生错误后的状态转换机制：

如果出现了BUS OFF，总线上的节点需要做一些动作，例如重启CAN控制器或是重新上电，但是这些都只是一些补救措施，最根本的还是需要找到引起BUS OFF的根源。

CAN总线分析的一些工具和文档：

CAN分析仪或者逻辑分析仪

数字示波器

相关的软件debug工具

CAN控制器芯片数据手册，这很重要

硬件电路图

CAN协议文档

相关版本的Linux内核源码

CAN节点发送错误不成功

问题描述与分析

挂载在CAN总线上的一个节点向总线上发送数据不成功，用逻辑分析仪也看不到任何波形。PS: 这应该是我碰到的最坑爹的事情了。下面具体来看看怎么不成功。于是调试中断查看CAN_STATUS即CAN状态寄存器显示0xE5, 查看CPU数据手册：

CAN总线状态直接进入了BUS OFF状态，这意味着错误计数已经超限，查看CPU收发寄存器的收发错误计数显示发送错误计数TEC达到248, 接收错误计数为0；这很明显，数据压根没有发送到总线上。

再进一步查看寄存器值LEC即LAST ERROR CODE 最后一个错误代码, 显示是BIT0 ERROR：

查看上面的错误代码表可知，BIT0错误也就是在发送数据期间，虽然CAN节点设备想要发送一个显性位，也就是逻辑0，但是CAN总线同时监听到总线上的数据位为隐性位，即逻辑1。这意味着CAN core往总线上发送的数据第一位就已经出错了，压根没有将数据经过CAN收发器传送到CAN总线上。

一直在使用CAN总线的我厂和我从来没遇到这等奇事，但是由于是新的CPU的开发所以在怀疑硬件的问题的同时也在排查软件问题，但是经过一阵排查，没有发现软件上的问题。回头再分析硬件，又经过一阵排查溯源，发现CPU的CAN收发线与CAN收发气的收发线接反，直接崩溃(PS: 硬件的大哥