前言
在CanSM模块的概念详解和模块配置文章中已经对BusOff处理机制有了详细描述,最近实际项目中领到了一个BusOff的Bug,解决Bug的过程没多大阻碍,不过,借助这个机会,深入分析一下Can网络的BusOff产生及处理机制。本文将从以下几个方面进行分析。
正文
1. 问题描述
测试问题:BusOff时间达到了191ms,也就是没有快恢复策略。
2. 复现问题
制造BusOf的方法:(1)CAN_H, CAN_L短接;(2)CAN_H或者CAN_L短接地;(3)工具,CAN Disturbance(VECTOR VH6501)干扰;这里使用方法3.
搭建测试环境:
控制器(ECU):热管理控制器TMC
仿真器器(IC5000):提供仿真环境,实时改代码编译调试
VN1630A:提供硬件lisence
VH6501: 物理层干扰控制器报文,触发BusOff
上位机CANOe 14.0:观测错误帧,及通过错误帧估算恢复时间
实测:Can BusOff后尝试恢复时间为192ms左右,现象上看是没有快恢复策略。
3. 查看CanSM模块配置
快恢复配置次数为3次,快恢复时间为30ms,慢恢复时间为200ms,BusOff Check时间(超时认为无BusOff)为400ms. 配置是没有问题的。
4. 查看配置生成代码
四个重要的配置项(快恢复时间,快恢复次数,慢恢复时间,BusOff检测超时时间)都是不对的
原因:低级错误,没有把BSW生成的代码拷贝到项目的工程目录下。
5. 修改验证
快恢复时间:30ms
快恢复次数:3次
慢恢复时间:200ms
BusOff检测超时时间:400ms
第一次BusOff恢复时间为94ms左右,第二次恢复时间为92ms左右,第三次恢复时间为93ms左右,第四次恢复时间为290ms左右.
问题:现象上看,3次快恢复然后进入慢恢复,但是快恢复时间(92ms左右)及慢恢复时间(290ms左右)和我们配置的参数(30ms, 200ms)差距很大,还是有问题吗?
答:是没有问题的,BusOff快恢复还是慢恢复时间描述的是CAN控制器进入到BusOff状态后尝试恢复到正常状态的时间,但是我们使用了CAN报文的错误帧外发周期来衡量BusOff时间的,然而我们的报文外发周期是100ms的,也就是说BusOff快恢复时间到后(允许外发报文)到开始发生报文其实是有0-100ms的时间可能的,也就是说,这种测试方式只要保证“快恢复时间”在100ms + 30ms = 130ms以内且慢恢复时间在100ms + 200ms = 300ms以内就算正常的了。
结论:使用正常的配置参数后,BusOff恢复策略达到要求。
到这里就结束了吗? — 请看下面的BusOff深入分析。
6. BusOff处理深入分析
BusOff状态机详细分析请参考本公众号的AUTOSAR 通信服务-CanSM概念详解一文。这里提出以下四个问题进行深入分析。
问题1. 发生BusOff事件后什么时间点将Can Controller设置为STOP模式?
答:发生BusOff事件后在BusOff的中断处理函数中将Can Controller设置为STOP模式。
问题2. 发生BusOff事件后什么时间点在哪个模块停止往CanDrve外发报文?
答:发生BusOff事件后在CanIf的回调函数CanIf_ControllerBusOff中停止往CanDrve外发报文,同时通知到CanSM模块发送BusOff事件。也对应图中的T_BUS_OFF。
问题3. BusOff进入恢复阶段后什么时间点将Can Controller设置为START模式?
答:BusOff进入恢复阶段后进入S_RESART_CC子状态后立马将Can Controller设置为START模式。也对应图中的E_BUS_OFF。
问题4. BusOff进入恢复阶段后什么时间点在哪个模块开始往CanDriver外发报文?
答:BusOff进入恢复阶段后如果快恢复次数小于等于配置次数且快恢复时间大于配置时间或者快恢复次数大于配置次数且慢恢复时间大于配置后开始往CanDriver外发报文。也对应图中的G_TX_ON。
小结:CAN BusOff的恢复时间对应状态机中发生T_Bus_OFF事件后从S_BUS_OFF_CHECK状态机器切换到S_RESTART_CC状态机时刻到最后从S_TX_OFF状态机满足G_TX_ON条件切换到S_BUS_OFF_CHECK状态机时刻之间的时间。
7.总结
1) CAN Controller检测到Bus Off事件发生后,通过中断向CAN Driver模块报告事件。
2) CAN Driver模块设置CAN Controller状态为STOPPED状态。
3) CAN Driver调用CanIf_ControllerBusOff()函数向上层模块CanIf通知BusOff事件。
4) CAN Interface模块收到信息后,更改Controller状态,设置所有PduMode为OFFLINE。
5) CAN Interface调用CanSM_ControllerBusOff()向上层CanSM模块报告Bus Off事件。
6) CanSM模块进行BusOff事件处理。
推荐阅读
Autosar架构下的模块详细设计及代码实现–基于配置的编程方法
CANoe工具使用(1)-实现CAN通道的收、发、录、回放报文
End
欢迎点赞,关注,转发,在看,您的每一次鼓励,都是我最大的动力!
汽车电子嵌入式
微信扫描二维码,关注我的公众号
原文始发于微信公众号(汽车电子嵌入式):AUTOSAR架构下CAN BusOff问题分析
我也有快恢复的时间比配置的时间要长的情况。但是出于验证的想法,我把一帧报文改成了1ms周期的,快恢复配的10ms,测试下来发现快恢复的时间在14ms-18ms之间变化。(L1->L2的次数是32次)