LPC1700 CAN接口的重大BUG

dxfshsh

LPC1700 CAN接口的重大BUG [复制链接]

虽然用到的人并不多，一旦用到，必死无疑。当你发送报文后，再使用终止指令，终止发送，就会死机，一般两条指令靠的越近，死机概率越高。
如：我在1752上使用 LPC_CAN1->CMR＝0x21 发送报文后，马上再用 LPC_CAN1->CMR＝0x22终止发送，总会造成死机， 不知在其他系列1754 1766上会不会是同样的结果。

zhaojun_xf

没有试过，应该不会吧。。。

dxfshsh

这个问题，已经困扰了我两周了，开始一直以为是自己的程序有问题，我想尽办法，去测试，最后发现是芯片的问题，当你发送报文后，有高优先级的事件产生，此时需要终止，刚才的发送，两条指令靠的越近，死机的概率就越高，如果，两条指令间隔较大，发生两种情况，1：该指令已经发送，终止已经没有意义了。2:发送报文在总线上竞争失利被挂起，此时可以通过终止指令进行终止，一般也不死机。3:死机的情况发生在，两条指令靠的比较近，这又是无法避免的，因为，终止指令是由高优先级事件触发中断中产生，无法控制两条指令的间隔。因此至少在lpc1752中是这样的。

ienglgge

没做过这种实验，“有高优先级的事件产生，此时需要终止”，不终止可以吗，不管它，去处理高优先级的内容

fxyc87

死机还是跳到异常区了？

dxfshsh

现象是CAN口不在接收数据了，程序的大循环也不动了，指示不在有动静。

dxfshsh

至于为什么要终止发送，是因为高优先级的事件，要占用总线，此设备必须避让。

Laspide

既然已经占用总线了，为什么不能允许他先发完呢？

dxfshsh

已经正在发送了，就停不下来，现在是刚放上，还在挂起状态，并未进入真正的占用了总线正在发送状态，终止便会出现此种异常。应该是cpu设计的一个bug。

dalang_9793

楼主想玩单次发送，不过你说的这个情况俺是没遇到。之前也是这样用过，实现了单次发送，用的是1766，跑的freertos

inner_peace

怎么没有NXP的人进来说明一下？

zhaojun_xf

那就适当加点延时。。。