CAN报文的busoff基础和测试实战

---

1、错误界定

在介绍busoff内容之前，需要先介绍错误界定，了解CAN控制器是怎么进入busoff状态的。为了避免总线被永久错误节点卡死，需要一种机制来进行鉴别并限制其功能，当节点报错到达一定状态后允许其退出总线通信进行busoff状态，这就是错误界定。
定义：每个节点都含有REC和TEC。REC：接收错误计数器；TEC：发送错误计数器。

• 发送错误产生，TEC增加；正确发送一帧，TEC减少；
• 接收错误产生，REC增加；正确接收一帧，REC减少；
• 节点复位时，两者清0。

这里需要注意的是TEC/REC错误累计规则，不能简单的理解为出错+1，正确-1。具体错误累计规则如下表。

2、节点状态

CAN节点分为三种状态：主动错误、被动错误、总线关闭。三种状态间的切换条件在下图中做出了说明。

不同状态下的节点特性如下表：

3、busoff测试分析

背景：硬件上选用VN6501进行，通过在vTESTstudio中搭建自动化测试脚本进行busoff测试。使用CANoe进行干扰DUT发送的所有报文，使DUT连续4次busoff。实际制造4次busoff失败。

思考：Trace窗口的log可以看出制造busoff时刻都是TxErr，只有几帧RxErr。思考为什么制造BUSOFF会有TxErr？

分析：理论上想要仿真制造DUT busoff状态，在唤醒DUT后需要对DUT发出的报文进行干扰（对CANoe来说就是Rx报文）。按照测试脚本逻辑，制造busoff时会停发仿真报文（Tx报文停发），此时总线上仍然存在TxErr可能是IG模块中在仿真发送报文。检查IG模块确实存在仿真报文的发送，关闭IG仿真报文后进行测试，DUT busoff正常。主要原因是TxErr导致了通信接口卡busoff，而不是DUT busoff。