文章目录
背景介绍
问题描述
分析排查
解决方案
总结归纳
背景介绍
在一个嵌入式软件项目中,有一段使用C语言写的嵌入式代码,功能是把CAN总线上的几帧报文接收进来,并解析出数据。示例如下:
乍一看感觉挺简单,想着直接用一个while循环,周期提取CAN buffer中缓存的数据就行了。但是就这么一个小应用让我栽了跟头,在整个工程中排查了几个小时才找到问题,下面就来分享一下这一小段个人经历。
一开始代码调试的时候很顺利,一共接收5帧报文,总共40个信号,相关代码大概是下面这个样子:
void main(void)
{
//省略若干行
if(Timer10ms == 1){
do{
ret = GetCANFrame(1, &Ext, &ID, &Length, &DataBuf);
if(ret){
if(ID == 0x100){
memcpy(&SignalArray[0], DataBuf, 8)
}
if(ID == 0x101){
memcpy(&SignalArray[8], DataBuf, 8)
}
if(ID == 0x102){
memcpy(&SignalArray[16], DataBuf, 8)
}
if(ID == 0x103){
memcpy(&SignalArray[24], DataBuf, 8)
}
if(ID == 0x104){
memcpy(&SignalArray[32], DataBuf, 8)
}
}
}while(ret && (i <= 100))
}
//省略若干行
}
问题描述
按照上述示例开发的软件,烧录到ECU中在实验室桌面上调试,使用Vector的CAN接口卡模拟残余总线发送0x100、0x101、0x102、0x103、0x104这五帧报文,ECU都能正常接收。但是把ECU集成到实车之后,却收到反馈ECU的CAN接收有丢帧现象。
分析排查
把实车上的CAN报文Log打开之后,看到总线上除了0x100、0x101、0x102、0x103、0x104这五帧报文之外,还有几十个其他ID的报文,所以推测是这些残余总线报文干扰了ECU的CAN接收。所以在实验室桌面上把这些残余总线模拟出来,复现了实车上的CAN接收丢帧现象,这就锁定了是残余总线的问题。
为了更具体的分析Bug机理,在代码中加入了一些调试信息,每个ID接收到之后都把相应的计数加1,示例如下:
void main(void)
{
//省略若干行
if(Timer10ms == 1){
do{
ret = GetCANFrame(1, &Ext, &ID, &Length, &DataBuf);
if(ret){
if(ID == 0x100){
memcpy(&SignalArray[0], DataBuf, 8)
FrameCount[0]++;
}
if(ID == 0x101){
memcpy(&SignalArray[8], DataBuf, 8)
FrameCount[1]++;
}
if(ID == 0x102){
memcpy(&SignalArray[16], DataBuf, 8)
FrameCount[2]++;
}
if(ID == 0x103){
memcpy(&SignalArray[24], DataBuf, 8)
FrameCount[3]++;
}
if(ID == 0x104){
memcpy(&SignalArray[32], DataBuf, 8)
FrameCount[4]++;
}
}
}while(ret && (i <= 100))
}
//省略若干行
}
烧录上述软件后可以看到,发生CAN接收丢帧时都伴随着残余总线报文的集中突增,总线瞬时100%负载率会持续十多ms,所以推测可能是残余总线报文挤占了CAN接收buffer。翻了一下CAN接收buffer的配置,是40帧的size。根据CAN总线500k的波特率计算100%负载率持续十多ms总线上会有50帧左右的报文。而我的代码是10ms从CAN接收buffer提取一次数据,这样必然会导致CAN接收buffer塞满后无法继续接收,也就是丢帧的现象。
解决方案
针对上述CAN接收buffer溢出的问题,解决方案可以从如下公式的每一个因子入手:
Buffer占用空间 = 单位时间最多的报文数量 * 提取Buffer的周期 公式(1)
方案一:扩大buffer size配置。其他条件不变,这里只要把原本40帧的size扩大到45帧左右即可。因为500k波特率的CAN总线,10ms时间内最多产生的报文不会超过45帧。这个方案需要MCU硬件资源的支持。
方案二:避免报文突增。其他条件不变,这里只要在CAN协议中约定好,各个ECU节点都按既定节拍发送报文,避免瞬时负载率拉升到100%,或者控制100%负载率持续时间要小于10ms。这样任何一个10ms周期内,总线上的报文最多也不会超过40帧,现有的40帧的Buffer size就够用了。这个方案需要总线上各个节点ECU的配合。
方案三:降低波特率。其他条件不变,这里只要把原本500k的波特率降下来,也就降低了单位时间最多的报文数量,实现的原理跟方案二一样。这个方案也需要总线上各个节点ECU配合变更波特率。
方案四:CAN接收ID过滤。其他条件不变,这里只要在底层CAN接收模块中做一个ID过滤,只允许0x100、0x101、0x102、0x103、0x104这五帧报文进入CAN接收buffer,实现的原理也跟方案二一样。这个方案只需要自己的ECU修改底层软件即可,不需要其他方面的支持和配合。
方案五:缩短提取Buffer的周期。其他条件不变,这里只要把原本10ms的提取周期改成5ms或者其他小于10ms的数值即可。因为因为500k波特率的CAN总线,5ms时间内最多产生的报文在20帧左右,远远低于40帧的buffer空间。这个方案只需要自己的ECU修改应用软件即可,不需要其他方面的支持和配合。
上述五种解决方案各有优劣,适用于不同的项目开发情景。方案一适用于ECU开发的早期,在MCU选项时,或者在软件架构定型时,就根据CAN总线的应用需求为buffer size留出足够的资源空间。方案二和方案三适用于系统集成阶段,在制定整车的网络协议时,约定好各个ECU节点需要遵循的公共基础和公用策略。方案四和方案五适用于ECU的应用开发阶段,在开发具体功能时,更具其他已经设定的条件,决定如何设计ID过滤和报文提取周期。
总结归纳
那么这个代码调试过程,发现的问题可以积累下来这么几条小经验以供自己将来使用,也给广大网友参考:
1、CAN网络相关的模块设计与开发时,不光要考虑自身ECU节点的发送和接收,还要考虑其他节点不相关报文的实际存在。对于不能确定确定参数时,就要按照最严酷的情况来估算,比如残余总线瞬时负载率达到100%,而且还持续挺长一段时间。
2、方案设计用的是等式(解决方案中的哪个等式),但是软件开发中用的是不等式,因为实际情况中要面对的有各种误差,所有在留下余量时,等式中的“=”就要变成“>”或者“<”。比如理论计算的buffer size是40帧,这里就应该使用>40帧。
以上就是本人在解决CAN接收Buffer溢出Bug时,一些个人理解和分析的总结,首先介绍了基本的项目背景,然后描述了问题的想象,最后分析排查了Bug原因,并给出了问题解决方案。
后续还会分享其他的,使用C/C++研发时遇到的Bug,欢迎评论区留言、点赞、收藏和关注,这些鼓励和支持都将成文本人持续分享的动力。
述例程使用的Demo工程,可以到笔者的主页查找和下载。文章来源:https://www.toymoban.com/news/detail-847413.html
版权声明:原创文章,转载请注明出处与链接,违者必究!文章来源地址https://www.toymoban.com/news/detail-847413.html
到了这里,关于【研发日记】C/C++开发避坑秘籍(一)——CAN接收Buffer溢出Bug的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!