BeagleBone Black CAN Bus

Question

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.

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.?

Answer 1

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.

Answer 2

That looks very much to me like you're not sending any data really. I see stuff bits (each sharp downward transition) but nothing else.

At any rate, you won't get an acknowledge bit set if there are no other devices on the bus and the CAN controller will throw an ack error. You should see this message being transmitted continuously, since no device is responding, and the CAN BUS 2.0 standard specifies messages should automatically be resent.

My suggestion would be to hook up another CAN controller onto the bus, you'll need that one simply to set the acknowledge bits, nothing else. This tells your beaglebone black that its messages are being received correctly on the bus. You can read up on the various errors and such on the wikipedia article about can bus, which is actually quite good.