跨境派

跨境派

跨境派,专注跨境行业新闻资讯、跨境电商知识分享!

当前位置:首页 > 卖家故事 > 【研发日记】C/C++开发避坑秘籍(一)——CAN接收Buffer溢出Bug

【研发日记】C/C++开发避坑秘籍(一)——CAN接收Buffer溢出Bug

时间:2024-03-25 15:01:04 来源:网络cs 作者:言安琪 栏目:卖家故事 阅读:

标签: 接收  秘籍  日记 
阅读本书更多章节>>>>

文章目录

背景介绍

问题描述

分析排查

解决方案

总结归纳


背景介绍

        在一个嵌入式软件项目中,有一段使用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.kjpai.cn/gushi/2024-03-25/148430.html,文章来源:网络cs,作者:言安琪,版权归作者所有,如需转载请注明来源和作者,否则将追究法律责任!

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容,一经查实,本站将立刻删除。

文章评论