您尚未登录。

楼主 # 2024-09-09 17:23:27

tomas
会员
注册时间: 2024-03-26
已发帖子: 39
积分: 124

D211的CAN通讯如何避免死机

初调D211的CAN通讯,最初是很正常的,可实现不同波特率下的数据正常收发。之后的测试卡的一塌糊涂
1- 发送卡壳;
2- CANH,CANL线缆短路,断路卡壳;
3- 设备波特率与总线波特率不一致时候卡壳。
卡壳有些是不可恢复的只能重新开机,有些是断开总线连接后可以恢复。

优化后的CAN通讯设计要点:
1.一定要把aic_can_hal.c文件中的hal_log_err()语句注释掉。主要是因为can通讯时有些error会被频繁触发,如果不关闭,所有线程都会被憋死,因为这属于中断响应。

2. can初始化时要选择自测模式而不是normal模式
    hal_can_ioctl(&can, CAN_IOCTL_SET_MODE, (void *)CAN_SELFTEST_MODE);
   按官方所说,自测模式属于发送不管,发送是否生效,用户可自己通过别的方式加以判断。
    很多情况下数据本就是发不出去的比如线缆断路,短路,并不需要sdk函数本身来保证发送是否成功,否则CAN也会出现卡壳。

3. 发送安全机制:
    . 设置一tx_done变量,在收发中断函数中tx_done=1。
    . 发送每一帧报文前先判断tx_done是否为1.如果=1直接发送,如果=0说明之前的报文未发送完毕。等待10ms且每隔1ms判断一次,等待过程注意让出线程。
    . 如果累计10ms后tx_done依然为0,说明总线异常,可能是D211设备异常,也可能是线缆异常。软件重启CAN外设来保证D211设备是正常的。
    . 重启CAN外设后,即直接发送不再判断,如果tx_done=1属于正常发送;否则属于重启后发送。发送后tx_done=0.

这样的话,对于每次发送任务,不管总线有无异常,总会执行所需要的发送任务。如果属于CAN外设驱动问题,在软件重启CAN外设后自然会恢复。如果属于线缆问题,线缆正常后也会第一时间恢复发送。

经过这样一番倒腾后,D211的can运行还是挺稳的。完美。。

最近编辑记录 tomas (2024-09-09 17:34:58)

离线

#1 2024-09-10 08:46:20

Gentlepig
会员
注册时间: 2018-10-24
已发帖子: 1,345
积分: 1309.5

Re: D211的CAN通讯如何避免死机

使用d133也是遇到类似问题,最开始的版本,can总线上已经有其他设备在收发信息,d133上电,有几率卡死,好像是接收错误。后来sdk更新了,这个问题不再出现了,但是如果总线上其他设备上电晚,d133先上电,没有其他can接收设备,则d133 can发送卡死,还恢复不了...

离线

#2 2024-09-18 09:03:07

ArtInChip
会员
注册时间: 2023-11-11
已发帖子: 206
积分: 212

Re: D211的CAN通讯如何避免死机

1.在1.0.6版本中,hal_log_err已修改,收发出错时不再显示打印信息
2.发送数据时,设置了超时时间,如果总线异常导致数据发不出去,超时后会退出,不会卡死
3.can总线上已经有其他设备在收发信息,d133上电卡死的问题,是因为RTT CAN框架在设置波特率之前就打开了中断,波特率不匹配导致,这个问题已修复。
4.d133先上电,没有其他can接收设备,则d133 can发送卡死,这个通过问题2已解决,也是RTT CAN框架的bug

离线

#3 2024-09-18 09:56:51

jimmy_xt
会员
注册时间: 2021-04-17
已发帖子: 7
积分: 6

Re: D211的CAN通讯如何避免死机

CAN总线比较特别,有仲裁机制,也要求错误节点不得影响整个总线。
最好自己来实现错误处理。

离线

#4 2024-09-18 10:40:39

Gentlepig
会员
注册时间: 2018-10-24
已发帖子: 1,345
积分: 1309.5

Re: D211的CAN通讯如何避免死机

@ArtInChip
那就太好了,稍后试试1.0.6。

离线

页脚

工信部备案:粤ICP备20025096号 Powered by FluxBB

感谢为中文互联网持续输出优质内容的各位老铁们。 QQ: 516333132, 微信(wechat): whycan_cn (哇酷网/挖坑网/填坑网) service@whycan.cn