CAN控制器总线错误分析之CAN节点BusOff恢复过程分析与测试

总线关闭（bus off）是CAN节点比较重要的错误处理机制。那么，在总线关闭状态下，CAN节点的恢复流程是怎样的？又该如何理解节点恢复流程的“快恢复”和“慢恢复”机制？本文将为大家详细分析总线关闭及恢复的机制和原理。

一、故障界定与总线关闭状态

为了避免X某个设备因为自身原因（例如硬件损坏）导致无法正确收发报文而不断的破坏总线的数据帧，从而影响其它正常节点通信，CAN网络具有严格的错误诊断功能，CAN通用规范中规定每个CAN控制器中有一个发送错误计数器和一个接收错误计数器。根据计数值不同，节点会处于不同的错误状态，并根据计数值的变化进行状态转换，状态转换如下图所示。

图1节点状态转换图情形1

以上三种错误状态表示发生故障的严重程度，总线关闭是节点最严重的错误状态。并且，节点在不同的状态下具有不同的特性，在总线关闭状态下，节点不能发送报文或应答总线上的报文，也就意味着不能再对总线有任何影响。

状态跳转和错误计数的规则使得节点在发生通信故障时有了较好的自我错误处理和恢复机制，从一种较严重的错误状态跳转到另一种严重性相对较低的状态，本质上就是一种恢复过程。图1所呈现的转换过程是CAN通用规范所要求的，我们从设备供应商买回来的CAN控制器已经把这些功能固化在硅片之中。

在通信过程中，错误主动和错误被动两种状态下节点的恢复过程一般不需要MCU进行额外的编程处理，直接使用CAN控制器固有功能即可。但对于总线关闭状态，往往不直接使用CAN控制器固有的恢复过程，而是对其进行编程控制，以实现“快恢复”和“慢恢复”机制。

注：

1、由于篇幅有限，关于错误计数的详细规则以及各状态下节点的具体特性不在本文进行讨论，读者可以查阅CAN的相关协议规范。

2、本文的“CAN控制器”是指已经实现了CAN通用协议物理层和数据链路层所要求的功能和特性的器件，如SJA1000；而“节点”是指把CAN控制器与MCU、收发器等相关器件进行整合开发出来的具有一定功能的CAN节点。

二、为什么需要对总线关闭状态的节点实现“快恢复”和“慢恢复”策略？

当节点进入总线关闭状态后，如果MCU仅是开启自动恢复功能，CAN控制器在检测到128次11个连续的隐性位后即可恢复通信，在实际的CAN通信总线中，这一条件是很容易达到的。以125K的波特率为例，12811（1/125000）= 0.011264s。这意味着如果节点所在的CAN总线的帧间隔时间大于0.011264s，节点在总线空闲时间内便可轻易恢复通信。我们已经知道，当进入总线关闭状态时，节点已经发生了严重的错误，处于不可信状态，如果迅速恢复参与总线通信，具有较高的风险，因此，在实际的应用中，往往会通过MCU对CAN控制器总线关闭状态的恢复过程进行编程处理，以控制节点从总线关闭状态恢复到错误主动状态的等待时间，达到既提高灵活性又保证节点在功能上的快速响应性的目的。具体包括“快恢复”和“慢恢复”策略，两种策略一般同时应用。

通过以上的讨论，我们可以知道，节点进入总线关闭状态后，存在以下几种恢复情况：

（1）MCU仅开启CAN控制器的自动恢复功能，节点只需检测到128次11个连续的隐性位便可以恢复通信，恢复过程如图1所示。

（2）MCU没有开启CAN控制器的自动恢复功能，也不主动干预总线关闭错误，节点将一直无法“自动”恢复总线通信，只能通过重新上电的方式使节点恢复, 恢复过程如图2所示。

图2 节点状态转换图情形2

（3）MCU对CAN控制器的恢复过程进行编程处理，这时，节点的恢复行为由具体的编程逻辑决定，各厂家普遍采用了先“快恢复”后“慢恢复”的恢复策略，恢复过程如图3所示。

图3 节点状态转换图情形3

三、MCU如何实现“快恢复”和“慢恢复”？

MCU编程实现总线关闭“快恢复”和“慢恢复”的一般过程可用以下流程图描述：

图4 MCU实现总线关闭恢复流程

节点以正常发送模式发送报文的过程中，如果出现了发送错误，发送错误计数会增加，只要发送错误计数没有超过255， CAN控制器便会自动重发报文，如果出现多次发送错误，使发送错误计数累加超过255，则节点跳转为总线关闭状态。MCU能够第一时间知道节点进入了总线关闭状态（例如在错误中断处理逻辑中查询状态寄存器的相应位），这时MCU控制CAN控制器进入“快恢复”过程，即控制CAN控制器停止报文收发，并进行等待，计时达到需要的时间T1（如100ms）后，MCU重新启动恢复CAN控制器参与总线通信，这样便完成了一次“快恢复”过程。

节点每进入一次“快恢复”过程时，MCU会对此进行计数，当节点“快恢复”计数达到设定的值N（如5次），则后续再次进入总线关闭状态时MCU把恢复总线通信的等待时间T2进行延长（如1000ms），这样便实现了“慢恢复”过程。“快恢复”和“慢恢复”过程的主要区别就在于恢复节点参与总线通信的等待时间的不同。

通过MCU对于总线关闭后的恢复行为进行编程控制，实际上是对CAN控制器的错误管理和恢复机制进行了补充，使得总线关闭状态后的恢复过程更加灵活，更能适应实际应用的需要。对于 “快恢复”和“慢恢复”的等待时间，以及“快恢复”计数多少次后进入“慢恢复”过程，不同厂家可根据具体的需求进行编程实现。

四、实测总线关闭恢复过程

通过广州致远电子有限公司的CAN总线分析仪的流量分析功能，可以很方便分析总线关闭后节点的恢复过程及测试“快恢复”和“慢恢复”的恢复时间。

第一步，连接DUT但先不要上电。按以下配置，使能接收干扰功能，并开启报文读取功能。

图5 功能设置

第二步，给DUT上电，并采集一段时间报文，停止采集后使用流量分析功能进行分析。

图7 读取恢复时间

至此，我们便可以得出结论：该DUT对总线关闭的恢复过程进行了编程控制，采用了先“快恢复”后“慢恢复”的恢复机制，节点进入总线关闭状态后，进行一次“快恢复”过程，后续进行“慢恢复”过程，两个恢复过程的恢复时间分别为27.5ms和209.5ms。

那么，我们该如何根据所得波形理解该DUT进入总线关闭状态及恢复通信的整个过程呢？
把第一个波形“团”放大得到下图：

图8 放大波形“团”观察

可以清晰的看到，波形“团”中包含共32帧CAN报文。把其余各波形“团”放大后也都是包含32帧，这里不再把详细的图片贴出来。

DUT上电后，初始发送和接收错误计数都为0。由于在测试时配置了接收干扰功能，当DUT开始发送报文后，每一帧报文都受到CAN总线分析仪的干扰而出现发送错误，第一次发送时发送错误计数加8，并自动重发，第二次发送时错误计数再加8，直到发送了32次后，发送错误计数大于255，根据图3的错误状态的转换规则，这时DUT跳转为总线关闭状态，MCU控制进入“快恢复”过程同时对“快恢复”次数进行计数，并等待约27ms后，MCU控制DUT从总线关闭状态恢复为错误主动状态，由MCU继续启动发送，由于仍然受CAN总线分析仪的持续干扰，发送32帧后再次进入总线关闭状态，再次执行“快恢复”或“慢恢复”过程，以此类推。

根据流量分析的结果可知，该DUT进入“快恢复”的计数达到1次后便执行“慢恢复”过程，“慢恢复”等待时间约为209ms。

注：
1、干扰的设置可以根据需要设置其他的参数，只要保证能对DUT发送的帧进行干扰使其出现发送错误即可。

2、为了分析完整的总线关闭恢复过程，建议DUT和CAN总线分析仪连接好后，先开启“报文读取”和“接收干扰”功能后再上电DUT。因为这样能确保DUT的接收错误计数和发送错误计数的初始计数都为0。

3、需要对DUT进行连续的干扰，否则DUT恢复后成功发送了报文，“快恢复”次数的计数会递减，这不利于分析DUT总线关闭后的整个恢复行为。

4、总线关闭后节点的“恢复”是指恢复参与总线的通信，但并不意味着恢复后一定能成功发送或接收报文。如上述案例，DUT恢复通信后由于仍然受CAN总线分析仪的干扰，导致报文发送再次失败。

总结：

在总线关闭状态下，“快恢复”和“慢恢复”不是CAN控制器固有的功能，而是通过MCU的编程逻辑实现的恢复机制，是总线关闭状态下恢复过程的补充，使恢复过程更具有灵活性。

CAN控制器总线错误分析之CAN节点BusOff恢复过程分析与测试相关推荐

can总线rollingcounter_CAN总线错误分析与解决
CAN总线错误分析与解决背景写这篇文章是因为我看到网上介绍CAN总线错误处理的文章,清一色的都是生搬照抄教科书或是数据文档的内容,特别是国内很难找到一些有价值的内容,这让一些真正有需要的人很苦恼, ...
Greenplum Segment节点掉线恢复介绍
1. 背景 Greenplum版本:6.13.0 问题: Segment节点异常关机,恢复Segment节点并恢复Mirror节点状态. 如图所示:sdw1节点掉线. 2. 解决方法: 2.1 查看M ...
CAN总线错误分析方法
我们先简单总结一下CAN的错误处理与故障界定: 1.CAN控制器记录发生在发送/接收过程中,总线数据出现错误的总数(位错误,CRC错误等). 2.CAN控制器根据总线出错数量由低到高,依次处于主动错误 ...
linux 设备树 usb控制器,linux 设备树中 dwc3 节点的phys参数含义
找了好久今天找到了,记录一下: &dwc3_0 { ... phys = ; ... } Required properties (port (child) nodes): lane0: - ...
[Hadoop][笔记]4个节点搭建Hadoop2.x HA测试集群
为什么80%的码农都做不了架构师?>>> 搭建Hadoop2.x HA 1.机器准备虚拟机 4台 10.211.55.22 node1 10.211.55.23 node2 ...
linux 驱动没有设备id,linux不同总线的设备和驱动的匹配过程分析
摘自: 前几日读书会,谈到linux中driver和device的匹配问题,我认为是通过设备名来匹配的,因为我之前看过platform的驱动,它就是通过设备name和驱动name来进行匹配,所以我确信 ...
Openstack入门篇（十一）之neutron服务（控制节点）的部署与测试
1.Neutron的介绍 Neutron 为整个 OpenStack 环境提供网络支持,包括二层交换,三层路由,负载均衡,防火墙和 *** 等.Neutron 提供了一个灵活的框架,通过配置,无论是开 ...
win11 创建恢复节点与恢复到节点
win+R ->control->系统安全->系统->允许远程访问->系统保护->此页面可以设置恢复的节点(具体方法一搜就有图文并茂的指导文档),还有系统还原-&g ...
CAN Bus-Off详解
1.什么是CAN Bus Off 举例: 车上一个ECU 1, 一直向总线上发送消息,可怎么都发送不出去. 如果这个累计到一定的次数(255),按照CAN总线协议: ECU ...

CAN控制器总线错误分析之CAN节点BusOff恢复过程分析与测试

CAN控制器总线错误分析之CAN节点BusOff恢复过程分析与测试相关推荐

最新文章

热门文章