Debugging notes for Linux socketcan mcp2515 on atmel9260

Some time ago, I debugged the mcp2515 driver in Linux. The driver basically passed the debugging. Some problems occurred when I debugged several other boards in the past two days.

 

1. When Linux is started, probe mcp2515 sometimes fails, sometimes succeeds, and some boards can always be successful. When the probe fails, the message "mcp251x didn't enter in conf mode after reset" is displayed ".

Debugging analysis: During probe, the driver reset mcp2515 adopts the SPI command reset form, and the mcp2515 reset pin is connected to the gpio pin of atmeil9260 (the gpio reset function is not used in the driver). Therefore, either the SPI reset command of mcp2515 fails, or the configuration mode of mcp2515 fails to be checked.

Because some boards can be used, the problem is locked on the gpio reset pin. When I use an oscilloscope to measure the lower level, it is actually a low level. This should be the cause of probe failure. After checking the driver, the driver does not initialize the reset gpio pin. Therefore, the gpio Initialization is added to the driver, and the output is high. However, this gpio pin is still low. It is estimated that the problem lies in hardware. In the driver, the gpio has been initialized to a high level, and other drivers have not used this gpio. Why is it still low?

After careful analysis of the circuit, the gpio was pre-allocated to the buttons on the subsequent board and connected to the CPU through 244, which was originally caused by the gpio reference conflict. Cut the access key, and then check that the probe can be successfully started.

 

2. in the same board, when mcp2515 is used to send and receive frame data, after one frame is sent and the test program on the PC can normally receive the data, the next frame cannot be normally received, the message "Write: no buffer space available" is displayed when the message is sent for 10th times ".

Debugging analysis: the prompt message should be printed by the kernel instead of the test program. Similar errors cannot be found on the driver. Some related information is found in the Google search, as shown below:

 

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_lenBut 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

 

My understanding is that the value of tx_queue_len is incorrect. in Linux, I checked the value of tx_queue_len, which is 10. It seems that the sending and receiving frame test program appears after sending 10th frames.Write: no buffer space available"Prompt message. However, it does not explain why the first frame of data sent can be received, and the next frame cannot be received.

No problem can be found when I check the driver, and a model board can send and receive frame data normally.

I also checked some statistics and status information in the/sys/class/NET/can0/directory and found no problems.

After looking for a long time, I couldn't find it. At this moment, I suddenly thought that I/O pins would conflict with pins. So I checked the other IO used in mcp2515 and used the interrupt gpio pin. Analysis of the circuit diagram again, oh my god, is a conflict. Solution: 1st problems. After resolution, you can send and receive frame data normally.

 

3. can does not connect to other nodes, that is, the CAN bus is suspended. At this time, frame sending testing can be conducted. The sending can be successful for 1st times (which can be proved by the amount of waveforms of the oscilloscope ), however, after sending the message again, you cannot normally receive the frame data on the PC. Unless ifconfig can0 is down and then ifconfig can0 is up, you can send and receive the frame data normally.

No reason is found for this problem. After the problem is solved, make up the problem.

 

4. when you receive frame data, you will receive additional data, such as the normal frame data "11 22 33 44 55 66 77 88 ", the system will receive extra frame data for "00 10 00 00 00 00.

The received frame data of "00 10 00 00 00 00 00" is actually sent by the kernel mcp2515 driver. According to the driver source code, if an error occurs in mcp2515, then, the kernel driver sends the relevant error frames to the upper layer. The upper-layer application determines what error occurs in mcp2515 based on the error code of the received error frames!

For more information, see: http://velep.com/