1. linux启动的时候probe MCP2515有时候失败，有时候成功，而有的板则是一直可以probe成功。probe失败时提示“MCP251x didn't enter in conf mode after reset”。
调试分析：由于probe的时候，驱动复位MCP2515采用SPI命令复位形式，同时MCP2515复位引脚接了ATMEIL9260的GPIO引脚（驱动中没用GPIO复位功能），因此，要么MCP2515的SPI复位命令没有成功，要么复位成功了MCP2515的配置模式检测不成功。
由于在有的板子可以，因此，把问题锁定在GPIO复位引脚上。用示波器量了下电平，居然是低电平。这应该就是probe失败的原因吧。查了下驱动，驱动中确实没有对这个复位GPIO引脚进行初始化，于是在驱动中加了GPIO的初始化，复位后输出高电平。但这个GPIO引脚还是低电平。估计问题出在硬件上了。驱动中明明已初始化该GPIO为高电平，而且其它驱动也没有用到此GPIO，为什么还是低电平呢？
仔细分析了电路，原来该GPIO在后续版的板子上预分配给了按键用，并通过244接到CPU上，原来是GPIO引用冲突引起的。割断按键用的通路，再看，启动时可以正常probe成功了。
2. 同样一块板，测试MCP2515收发帧数据的时候，发送一帧且PC机上的测试程序可以正常收到后，接下来发送帧都不能正常收到，且到发送第10次时提示：“write: No buffer space available”。
调试分析：这个提示信息应该是内核打印的而不是测试程序中打印出来的，在驱动上也找不到这种类似相关错误。在google上搜索下，有搜索到一些相关信息，如下：
Neal Probert wrote:
> I'm using PCAN-USB 6.7 with latest Socket-CAN from Subversion.
>
> Can anybody tell me what this means, and how to I get around it?
>
> "write: No buffer space available"
>
> I don't get this with vcan0, but I do with can0. Happens with cangen
> and my own application.
>
Hi Neal,
when you try to write more data than the 'real' CAN hardware can put
onto the bus the tx-queue from the CAN netdevice simply runs over after
some time.
If you have only 'peak' load you may try to pump up the tx_queue_len of
'can0' in the sysfs:
echo 1000 > /sys/class/net/can0/tx_queue_len
But if your idea is to generate maximum load, you could ignore/handle
the -ENOBUF return value, wait an appropriate time (e.g. 500ns?) and
send your next CAN frame.
Regards,
Oliver我的理解是tx_queue_len的值的问题，在linux上查了下tx_queue_len的值，是10，这似乎可以解释，收发帧测试程序在发第10帧后出现“write: No buffer space available”提示信息了。但没有解释为什么发送的第一帧数据可以收到，接下发送的帧收不到。
查了下驱动也找不出什么问题，而且有个型号的板子是可以正常收发帧数据的。
也查看了/sys/class/net/can0/目录下的一些统计、状态等信息，似乎也找不出什么问题。
找了好久没找到，就在这时，突然想到，会不会又是IO引脚冲突引脚的。于是查看了下MCP2515用到的其它IO，它还用到了中断GPIO引脚。再次分析电路图，oh my god，真是又是冲突了。解决方法如第1个问题。解决后，可以正常收发帧数据了。
3. CAN不连接其它节点即CAN总线空悬着，这时候进行帧发送测试，第1次可以发送成功(用示波器量波形可以证明)，但后面再次发送就不能正常在PC机上收到帧数据，除非ifconfig can0 down再ifconfig can0 up一下，则可正常收发帧数据。
这个问题目前没找到原因。后续解决了再补上。
4. CAN收帧数据时，会收到额外数据，如收到正常帧数据“11 22 33 44 55 66 77 88”，会收到“00 10 00 00 00 00 00 00”多余的帧数据。
这个问题目前没找到原因。后续解决了再补上。