CAN(调试过程遇到的问题记录）

1，环境及问题现象描述：设备链路完整，可以正常收发数据，但ints发现对应的中断不计数？
【分析及解决】中断函数在正确处理完之后必须要返回一个大于0的返回值，驱动中的中断函数回调base中的sja1000irq，sja1000irq函数是void类型，无返回；改变驱动模块，在驱动模块中多嵌套了一层，并且加了在中断正确处理后的的返回值（如下图所示）

2、问题现象描述：程序运行起来后（无接收设备，总线上就这一个发送设备），来测试应用的发送功能，发送64帧数据后会卡在write()哪里？
【分析及解决】查看了内核__canDevInit()函数，发现发送超时时间与接收超时时间都被初始化为永久等待，并且设备发送或接收之前都存在二进制信号量的超时等待（用于共享资源的互斥访问）。为了进一步确认此现象，在终端命令行发送ts命令来确认，发现客户的发送线程确实卡在Sem信号。所以在应用程序初始化时调用功能函数ioctl()，将超时时间改为客户要求的时间。另外发送64帧数据是在设备创建时，设定的系统接收缓存区大小，当此缓存区满了（此驱动64帧数据）没有位置继续写便会卡在write哪里。

3、问题现象描述：程序运行起来后（无接收设备，总线上就这一个发送设备），程序根据打印提示成功发送64帧数据（其实是应用将64帧数据写到了系统缓存区中，还并未将数据从can控制器的发送FIFO中发送出去），当cantest软件对应打开两通道时（此时应用程序已结束运行），会收到之前应用发送的64帧数据（设备can控制器是继续工作的，当can盒子打开后，总线上便有了多个设备，此时设备间进行ack确认，之后便将数据发送给了can盒子并显示出来）。客户意思是说应用都挂掉了，对端他不想要之前发送的数据。
【分析及解决】出现上述问题按正常来说属于正常范畴，但为满足客户的需求驱动中做以下改变：首先先明白设备不管因为什么原因挂掉（例如人为的Ctrl+C, Ctrl+X，系统断电等等特殊因素反正就认为应用异常死掉了）系统都会去回收资源，调用close函数。所以在驱动close函数中对can控制器进行复位操作（个人觉得这样是安全操作，首先复位后不影响下次设备的使用，然后应用异常后复位也合情合理），复位后会清除FIFO中的数据。