Beaglebone black newb here. I’ve been fighting with various problems with getting CAN to work and not really getting anywhere. Does anybody have a detailed set of instructions for the TT3201?

I’m trying to use the onboard Beaglebone Black CAN which is routed directly to a transceiver to avoid the extra problems with SPI. I expected this to be built into the distribution, but apparently it is not.

In addition, it seems like can_utils, can-utils, or canutils have become a victim of bitrot and going down. Almost all the tutorials have “cansend can0 -i 0x11 0x22” when the cansend command I have supports “cansend can0 FED#DEADBEEF”. In addition, I don’t even have a “cancontrol” command. Clearly, something has changed significantly.

I’ve got my scope connected, and nothing external is toggling. Do I have to use Angstrom or Debian? Is there a particular image I need to load to make this work? Am I doing something completely stupid (almost certainly)?

Any pointers would be useful.


I saw similar issues but didnt have a scope. Did you check the inputs to transciever with scope ??. I’d bet the IO is not configured properly for that cape

I did check the transceiver. The RX toggles fine (I have a board that generates CAN transactions that is not a Beaglebone); the TX doesn’t budge. So, the transceiver appeears to be working. Whether that means that the RX and TX on the SoC are connected correctly is a different question.

The Linux configuration is certainly not automatic, but I followed the directions here and they seem to work:

The problem is that lots of things are still linked to for a subversion repository, and that’s all gone with no pointer to where a new one would be.

I’m looking primarily at the CAN interface that is directly connected to the DCAN1 interface on the ARM SoC. The only thing needed is for the CAN transceiver (a very simple chip) TX/RX to be connected to the correct lines on the ARM SoC. I’m trying to stay away from the CAN interfaces that require SPI communication to the CAN controller chips from Microchip as that’s a whole 'nother ball of wax.

I haven’t physically traced the lines (yet) since I would have to create a “Blinky LED” switcher test since the pin is underneath the SoC, but it seems that people have managed to get this working in the past so I would be very surprised if those lines moved. Although, I should probably go check the schematics on the Beagleboard or previous Beaglebone to see if something actually did… Mr. Murphy is always hanging around …

I’m more concerned about the fact that the “cansend”, “cancontrol”, etc. commands in the tutorials simply don’t reflect anything close to reality on the current versions as well as the references to Something major changed, but there is no trace of it. The fact that nobody has created new tutorials means that this stuff may be untested for quite a bit of time. I suspect if I could run that down, everything else would probably fall into place.