I have noticed that if I short CAN_H and CAN_L together, or if there is noise on the bus, the BeagleBone will stop sending and receiving CAN messages. When this happens, if I execute “ifconfig can0 down” and “ifconfig can0 up”, things start working again. Is there a way to detect this automatically and recover? I’m using SocketCAN, but haven’t found anything that would tell me when I get a bus off or bus heavy.
You can configure the controller to automatically recover from bus-off conditions by setting the “restart-ms” option.
The python-can documentation has some useful notes on socket-can and bus-off conditions:
http://python-can.readthedocs.org/en/latest/socketcan.html#can-errors
This does not tell us strictly speaking if the canbus itself has issues, but we have a heartbeat device on the canbus. If we fail to hear from it (or any other traffic) for a set period of time, we reset the canbus as you described. In practice I’ve only seen this reset trigger when I’ve forgotten to specify or turn on a heartbeat device, or intentionally for testing. It was implemented as a safety net since the older generation windows based system (which was admittedly much larger, more complex, and used third party hardware and drivers) would sometimes fail for mysterious reasons.
Brent,
have you tried to use can-utils to dump traffic on the canbus when the NIC is found in that bad state? AFAIK, socketCAN implementation on linux does not utilize ID filtering on the can transceiver, it is done at the SocketCAN api level. You maybe able to see traffic. Also, what can transceiver are you using?
Adding restart-ms did the trick! Thanks so much, I never knew that was even there.
Brent, what guide are you reading for CAN ? I’ve never used CAN personally, and am curious . . .
Well, I’m not reading a guide, but I’ll share a few links that helped me get started. I have a Qt application and I use the SocketCAN to read/write CAN messages. This will work with J1939 as well.
https://www.kernel.org/doc/Documentation/networking/can.txt
http://en.wikipedia.org/wiki/SocketCAN
http://www.can-cia.org/fileadmin/cia/files/icc/13/kleine-budde.pdf
Thank Brent, However I was more curious about the bring up of the hardware on the BBB. IS there cape file I have not noticed yet ?
If so I can probably figure it out on my own.
Ah, yes. The TT3201 cape has three CAN channels, but two of them are over SPI. This should help you out…
https://github.com/beagleboard/devicetree-source/blob/master/arch/arm/boot/dts/TT3201-001-01.dts
Witch kernel are you using? Using the can cape that uses the can1 interface, I’m having some troubles with the 3.8 of Robert.
After I send some packages it just silently stop sending and I have to do a ifdown ifup in order to make it run again. This didn’t happen with the Kernel version of the Angstrom.
Any ideas?
Any hint how to activate the can1 in the device tree of the 3.15?