Electronic – BeagleBone Black CAN Bus

beaglebone blackcanlinux

My apologies if this is the wrong stack website for this question.

We plan to use a BeagleBone Black as the control computer for an electric car. The BBB handles, among other things, communicating with the motor controllers over the CAN protocol (using can-utils).

Installation (according to a number of online guides) seemed to be going well (device tree setup, modprobe, etc), with no errors, until we actually plugged into the motor controllers… and nothing happened.

We hooked up an oscilloscope (to both the TX and RX wires on the BBB) and watched the execution of the following commands:

ifconfig can0 down
ifconfig can0 up
cansend can0 180#1234

which should send data along the bus. The oscilloscope showed the following (RX on top, TX on bottom), every time we executed the commands above.

cansend oscilloscope trace

I suspect this signal we were seeing is some sort of handshake which was not being answered.

(Note that if we tried to run cansend again, nothing would happen until we ran ifconifg down/up).

After many such execution cycles, interestingly, ifconfig reported that the RX bytes had been increased, even though nothing had been received, only sent.

A few days later, with an identical setup, the CAN bus is still not working, and we are not seeing the handshake signal on the oscilloscope. ifconfig reports dropped bytes but little else to help us.

Any ideas on where to go from here, how to debug this issue, etc.?

Best Answer

If there is no Acknowledge for a CAN packet, so this can be considered like a transmission error. I'm afraid that it can be up to the CAN implementation how to handle this situation.

If you have a single CAN device, try to use either loopback mode or set a restart time:

ip link set can0 up type can bitrate 250000 loopback on

or

ip link set can0 up type can bitrate 250000 restart-ms 100

Note: BBB 3.8.x kernel apparently has a bug in CAN implementation. Sometimes there is kernel panic caused by CAN modules:

[ 2094.561511] BUG: scheduling while atomic: cansend/1996/0x40000100
[ 2094.568140] Modules linked in: vcan can_raw can g_multi libcomposite c_can_platform c_can can_dev mt7601Usta(O)
[ 2094.568332] [<c00114f1>] (unwind_backtrace+0x1/0x9c) from [<c04cb7bd>] (__schedule_bug+0x31/0x44)
[ 2094.568388] [<c04cb7bd>] (__schedule_bug+0x31/0x44) from [<c04d0707>] (__schedule+0x4df/0x574)
[ 2094.568446] [<c04d0707>] (__schedule+0x4df/0x574) from [<c004eafb>] (__cond_resched+0x1b/0x24)
[ 2094.568496] [<c004eafb>] (__cond_resched+0x1b/0x24) from [<c04d07fb>] (_cond_resched+0x23/0x2c)
[ 2094.568549] [<c04d07fb>] (_cond_resched+0x23/0x2c) from [<c02cdea7>] (__pm_runtime_resume+0x57/0x58)
[ 2094.568619] [<c02cdea7>] (__pm_runtime_resume+0x57/0x58) from [<bf8c00d7>] (c_can_get_berr_counter+0x16/0x3c [c_can])
[ 2094.568687] [<bf8c00d7>] (c_can_get_berr_counter+0x16/0x3c [c_can]) from [<bf8c0287>] (c_can_handle_state_change+0x1e/0x100 [c_can])
[ 2094.568752] [<bf8c0287>] (c_can_handle_state_change+0x1e/0x100 [c_can]) from [<bf8c0719>] (c_can_poll+0x14c/0x608 [c_can])
[ 2094.568811] [<bf8c0719>] (c_can_poll+0x14c/0x608 [c_can]) from [<c0426671>] (net_rx_action+0x69/0x138)

Some links where you can find some information regarding this problem https://groups.google.com/forum/#!topic/beagleboard/JL6aSRc0b7E http://lists.openwall.net/netdev/2013/11/27/64

Try to use another version of a kernel.

Related Topic