On 02/18/2011 07:58 PM, Joseph Kubicky wrote: > I'm using socketcan on a custom Analog Devices BF537 board running uClinux. > I'm using ADI's 2010R1 uClinux (2.6.34.7-ADI-2010R1-pre-svn9156), but I > don't know how to find out what version of the socketcan driver is in there
The bfin_can Socket-CAN driver is mainline since 2.6.33 but I can't tell if it uses it. > (if someone could tell me I'd appreciate it). I'm using the BF537's > built-in CAN controller. My application is receiving all the CAN frames I > expect, but ifconfig is telling me that fully 1/2 of the packets being > received are error frames. I also have a Kvaser CAN analyzer on my bus and > it isn't reporting any errors at all. My packet rate is pretty low - around > 25 frames/s on a 500Kbit bus. > > Exploring a little more, if I look at the bus transcript from my CAN > analyzer I see something like: > > 0 00000020 8 1B 00 07 98 80 09 88 80 515.903420 R > 0 00000020 8 1B 08 0B 78 80 09 78 80 515.903610 R > 0 00000020 8 1B 10 07 88 80 08 78 80 515.903870 R > 0 00000020 8 1B 14 07 C8 81 07 58 80 515.904120 R > 0 00000020 8 1B 04 0B 98 80 08 88 80 515.904380 R > 0 00000020 8 1B 0C 07 98 80 09 58 80 515.904570 R > 0 00000060 6 6B 2B 00 00 00 00 515.911100 R > 0 00000020 8 1F 00 08 98 80 09 88 80 516.153400 R > 0 00000020 8 1F 08 0B 78 80 09 78 80 516.153660 R > 0 00000020 8 1F 10 07 78 80 08 78 80 516.153910 R > 0 00000020 8 1F 14 07 D8 81 07 58 80 516.154170 R > 0 00000020 8 1F 04 0A 98 80 07 88 80 516.154360 R > 0 00000020 8 1F 0C 07 98 80 09 68 80 516.154620 R Are you sending the messages at a very high rate? > But if I run candump can0 -m 0 -e 0xffffffff on my host I get: This seems to be a very old version of the can-utils. Anyway, that's not the problem. I think. > can0 20 [8] 1B 00 07 98 80 09 88 80 > can0 20000004 [8] 00 01 00 00 00 00 00 00 ERRORFRAME This is an CAN_ERR_CRTL_RX_OVERFLOW error (from Receive Message Lost Interrupt Status). > can0 20 [8] 1B 08 0B 78 80 09 78 80 > can0 20000004 [8] 00 01 00 00 00 00 00 00 ERRORFRAME > can0 20 [8] 1B 10 07 88 80 08 78 80 > can0 20000004 [8] 00 01 00 00 00 00 00 00 ERRORFRAME > can0 20 [8] 1B 14 07 C8 81 07 58 80 > can0 20000004 [8] 00 01 00 00 00 00 00 00 ERRORFRAME > can0 20 [8] 1B 04 0B 98 80 08 88 80 > can0 20000004 [8] 00 01 00 00 00 00 00 00 ERRORFRAME > can0 20 [8] 1B 0C 07 98 80 09 58 80 > can0 20000004 [8] 00 01 00 00 00 00 00 00 ERRORFRAME > can0 60 [6] 6B 2B 00 00 00 00 > can0 20000004 [8] 00 01 00 00 00 00 00 00 ERRORFRAME > can0 20 [8] 1F 00 08 98 80 09 88 80 > can0 20000004 [8] 00 01 00 00 00 00 00 00 ERRORFRAME > can0 20 [8] 1F 08 0B 78 80 09 78 80 > can0 20000004 [8] 00 01 00 00 00 00 00 00 ERRORFRAME > can0 20 [8] 1F 10 07 78 80 08 78 80 > can0 20000004 [8] 00 01 00 00 00 00 00 00 ERRORFRAME > can0 20 [8] 1F 14 07 D8 81 07 58 80 > can0 20000004 [8] 00 01 00 00 00 00 00 00 ERRORFRAME > can0 20 [8] 1F 04 0A 98 80 07 88 80 > can0 20000004 [8] 00 01 00 00 00 00 00 00 ERRORFRAME > can0 20 [8] 1F 0C 07 98 80 09 68 80 But the received data seem to be correct. What does the following command tell you: # ip -d -s link show can0 > These frames are being generated by some custom boards of mine, but I get > exactly the same error frame even if I generate a frame from the Kvaser. My > bus is properly terminated (at both ends) and is very short for this test > setup - just three nodes (+ the analyzer), separated from one another by > ~1ft of twisted-pair. The only configuration I do is when I start the > interface in /etc/rc: > > ip link set can0 type can bitrate 500000 > ifconfig can0 up > > I assume the detailed bit timing is being set to some default values by the > driver... I wonder if that could be my problem. The errors seems not due to electrical problems. > Has anyone else seen this type of problem? Any ideas how to troubleshoot > it? Looks wired. Maybe the maintainer of the driver does have an idea (added to CC) Wolfgang. _______________________________________________ Socketcan-users mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-users
