我先说一下目前项目中采用的一些处理：
1、利用HAL库的返回值处理，比如下面：
        while(HAL_CAN_Transmit_IT(&hcan_use)!=HAL_OK)
        {
                __nop();
        }

2、加入独立看门狗，死机3秒就重启
3、CAN通讯协议设计成发送后必须有回复，超时没回复就发出重启指令，另接收指令的CAN节点重启，然后重发指令

但是目前通讯在节点多于6个以上的时候会容易出现通讯故障。
现在从硬件与软件两个方面同时解决，
硬件上我认为可能是线路阻抗匹配上有问题，正申请购置相应测量仪器
软件上除了上述处理以外，不知道各位还有什么经验没有？
比如说怎么通过一些寄存器标志位进行错误判断，然后能够通过软件上做出一些相应的处理，使CAN通讯功能恢复正常。之类的。

楼主用的是中断发送，如果想查询实时发送结果，不要用中断。接收用中断处理。节点过多并不一定是电阻的问题，只要保证最多2个120欧姆的电阻即可。可能是波特率配置不一致导致的。

但是目前通讯在节点多于6个以上的时候会容易出现通讯故障。


这个故障是什么?报错是什么错误?

阻抗匹配一般问题不大，我们甚至在CAN总线上总电阻在40甚至30欧姆的情况下都能读到正确的CAN报文。当然官方建议还是两端各跨接一个120欧姆电阻。
1.认真规划总线使用波特率和ID分配。良好的ID分配应该有深入的考虑，例如CANOpen或者J1939都是很好的范例。通过ID定义报文的优先级，在出现总线竞争的时候能够仲裁胜出。此外，还要便于报文的过滤，一个CAN网络，在1秒内可能产生超过1k条的CAN报文，如果没有良好的过滤机制，筛选报文也是一个头疼的事情。
2.单个控制器向外界发送周期性报文的时候，可以考虑在其中加入一个Live值，就是每个报文中某个字段比前一个+1，这样当其他设备读到这个值不符合预期时，可以判断报文丢失或通讯错误。
3.节点的CAN控制器应该考虑仲裁失利是否重发，重发带来的问题是可能会一直被堵塞。
4.配置BUS OFF。当控制器发现自己发送错误帧超过一定数目的时候可以考虑主动脱离CAN网络。