Enable CANBus on the BeagleBone Black

A few months back I got hold of my first BeagleBone Black (BBB) with the intention of installing it in my car as a trackday data logger. First step in this endeavor was to get the CANBus working. I wrote this up here, but I'm shutting down that (poorly designed) site and have come up with a better way of enabling CAN so here goes.

First up, I'm assuming you are either running the latest Angstrom image (see here), or Ubuntu with the patched device tree compiler (see here). This ensures you have a device tree compiler which is capable of compiling overlays. So with that out of the way...

Enabling DCAN1

Update 26th August 2013: This original post focused on enabling dcan1, as these pins are available by default. If you'd like to enable dcan0 (At the expense of i2c2, possibly breaking any capes you have plugged in!), skip to the bottom of the post

To enable CAN (specifically dcan1), we need to write a device tree overlay which will enable the device and set the pin muxing. For those of you who just want the answer, here's the overlay.


/ {
    compatible = "ti,beaglebone", "ti,beaglebone-black";

    /* identification */
    part-number = "dcan1pinmux";

    fragment@0 {
        target = <&am33xx_pinmux>;
        __overlay__ {
            dcan1_pins_s0: dcan1_pins_s0 {
                pinctrl-single,pins = <
					0x180 0x12	/* d_can1_tx, SLEWCTRL_FAST | INPUT_PULLUP | MODE2 */
					0x184 0x32	/* d_can1_rx, SLEWCTRL_FAST | RECV_ENABLE | INPUT_PULLUP | MODE2 */

    fragment@1 {
        target = <&dcan1>;
        __overlay__ {
             #address-cells = <1>;
             #size-cells = <0>;

             status = "okay";
             pinctrl-names = "default";
             pinctrl-0 = <&dcan1_pins_s0>;

There are two important parts to the overlay, fragment@0 and fragment@1. We'll look at each of those in turn.

fragment@0 is responsible for setting the pin mux. The two lines of hex (15-16) represent pairs of 'pin' register and 'mode' value.

Update 20th August 2013I've created a spreadsheet to simplify the determination of register offset and mode values so you no longer have to dig through datasheets. The dcan1 signals can be found on pins P9 _24 and P9_26, both Mode 2. Use the register value worksheet to determine the correct pinmux values (Fast slew,  input for rx/output for tx, pull up, mode 2).

To find the correct register you first need to find out the name of the pins from the BBB SRM. Referring to Table 11 in the SRM, you can find the dcan1 signals are exposed on pins 24 (UART1_TXD) and 26 (UART1_RXD).

Now, diving in to the AM3359 Technical Reference Manual. In Table 9-10 (on page 759!) you can find the two registers conf_uart1_txd (0x980) and conf_uart1_rxd (0x984). These pin configuration registers start at 0x800, therefore the offset values are 0x180 and 0x184 respectively.

The detail of these registers can be found in Section 9.3.51, letting you calculate the correct values for dcan1.

Pin Slew Rate Input Pull Up Pull Up Mode Mode Mode In Hex
d_can1_tx (0x180) 0 0 1 0 0 1 0 0x12
d_can1_rx (0x184) 0 1 1 0 0 1 0 0x32

That's it for fragment@0, on to fragment@1. This section enables the CAN device. Firstly, on line 23, we identify the device we want to enable as dcan1. Then we specify that we want the device enabled by setting it's status to "okay" on line 28. Finally, we associate the pin mux created in fragment@0 with the device, line 30.

To compile this overlay, save it as BB-DCAN1-00A0.dts (the dts extension referring to a device tree source file). Then execute the following command.

 dtc -O dtb -o BB-DCAN1-00A0.dtbo -b 0 -@ BB-DCAN1-00A0.dts 

This will create the overlay binary BB-DCAN1-00A0.dtbo. If you get an error about the -@ option being unrecognised then you are likely on Ubuntu without the patched version of dtc (see here).

To use the overlay simply copy it to /lib/firmware

 sudo cp BB-DCAN1-00A0.dtbo /lib/firmware 

And execute the following (note you must be logged in as root to do this, sudo will not work!)

 echo BB-DCAN1 > /sys/devices/bone_capemgr.*/slots 

Check with dmesg to see if this worked, you should see something like this

dmesg | tail -n15
[   17.878323] init: plymouth-stop pre-start process (796) terminated with status 1
[  283.946706] bone-capemgr bone_capemgr.8: part_number 'BB-DCAN1', version 'N/A'
[  283.946892] bone-capemgr bone_capemgr.8: slot #9: generic override
[  283.946944] bone-capemgr bone_capemgr.8: bone: Using override eeprom data at slot 9
[  283.946996] bone-capemgr bone_capemgr.8: slot #9: 'Override Board Name,00A0,Override Manuf,BB-DCAN1'
[  283.947270] bone-capemgr bone_capemgr.8: slot #9: Requesting part number/version based 'BB-DCAN1-00A0.dtbo
[  283.947323] bone-capemgr bone_capemgr.8: slot #9: Requesting firmware 'BB-DCAN1-00A0.dtbo' for board-name 'Override Board Name', version '00A0'
[  283.951368] bone-capemgr bone_capemgr.8: slot #9: dtbo 'BB-DCAN1-00A0.dtbo' loaded; converting to live tree
[  283.952035] bone-capemgr bone_capemgr.8: slot #9: #2 overlays
[  283.953133] platform 481d0000.d_can: alias fck already exists
[  283.962225] bone-capemgr bone_capemgr.8: slot #9: Applied #2 overlays.
[  284.034183] CAN device driver interface
[  284.071999] c_can_platform 481d0000.d_can: invalid resource
[  284.078088] c_can_platform 481d0000.d_can: control memory is not used for raminit
[  284.084553] c_can_platform 481d0000.d_can: c_can_platform device registered (regs=fa1d0000, irq=71)

If you have something to hook up to (don't forget to go through a transceiver, or bad things will happen), you can test everything is up and working with can-utils. First, make sure you have all the relevant modules loaded.

sudo modprobe can
sudo modprobe can-dev
sudo modprobe can-raw

Get and build can-utils

svn co svn://svn.berlios.de/socketcan/trunk
cd trunk/can-utils/

Set up the bus speed and enable it

sudo ip link set can0 up type can bitrate 500000
sudo ifconfig can0 up

Now you can use either cansend or candump to test your bus.

Unfortunately, I've discovered my car is more rust than chassis so the track days are going to have to wait. BBB has been repurposed to other projects, more details on these coming soon...

Enabling DCAN0

Update 26th August 2013: After the comment from Marco below, I've put this section in to enable DCAN0.

To enable dcan0, you'll need an overlay similar to that for dcan1. Marco posted one below, but it seems the comment system strips angled brackets for fear of HTML tags, so here is one I made.

/ {
    compatible = "ti,beaglebone", "ti,beaglebone-black";
    /* identification */
    part-number = "dcan0pinmux";
    fragment@0 {
        target = <&am33xx_pinmux>;
        __overlay__ {
            dcan0_pins_s0: dcan0_pins_s0 {
                pinctrl-single,pins = <
                    0x178 0x12  /* d_can0_tx, SLEWCTRL_FAST | INPUT_PULLUP | MODE2 */
                    0x17C 0x32  /* d_can0_rx, SLEWCTRL_FAST | RECV_ENABLE | INPUT_PULLUP | MODE2 */
    fragment@1 {
        target = <&dcan0>;
        __overlay__ {
             #address-cells = <1>;
             #size-cells = <0>;
             status = "okay";
             pinctrl-names = "default";
             pinctrl-0 = <&dcan0_pins_s0>;

We can build and install this in the same way

dtc -O dtb -o BB-DCAN0-00A0.dtbo -b 0 -@ BB-DCAN0-00A0.dts
sudo cp BB-DCAN0-00A0.dtbo /lib/firmware

However, if you try to enable dcan0 now you will get an error about the i2c pins (see Marco's comment). This is because the i2c2 pins are enabled by default and take precedence over any overlay. Before we continue I should mention that the i2c2 pins are used by the BBB to identify capes, and enable devices/pinmuxes appropriately, everything I do from here on is likely to stop any capes working!.

Another warning: This process involves modifying the default device tree binary. If you do this incorrectly, your BBB will not boot. If you're messing with the eMMC image, I can't guarantee it can be reflashed either (although I see no reason why it shouldn't be possible). You're following this guide at your own risk, if it breaks your BBB it's not my fault! I do all my hacking on an Ubuntu flashed SD card, so if it goes wrong (and it often does!) I can stick the card in my PC and undo any changes. eMMC users, continue at your own risk...

Unfortunately, we can't simply disable i2c2 with an overlay (I have tried, it crashed my BBB!). We also can't switch off the i2c2 device, because it is used by bone_capemgr and disabling it seems to make /sys/devices/bone_capemgr.*/slots disappear, meaning we can't enable overlays! So, my work around is simply to prevent the i2c2 device setting its pinmux and claiming the dcan0 pins. In this state, as far as bone_capemgr is concerned, the i2c2 pins are perpetually disconnected (but the device still exists in /dev/).

To stop i2c2 from setting its pinmux, we need to modify the default device tree binary, and to do this we need the source files. If you built your kernel from scratch you will have them lying around somewhere, but if not you can grab them from Derek Molloy's git repository (Note, I'm assuming the 3.8.13 kernel here).

git clone https://github.com/derekmolloy/boneDeviceTree.git
cd boneDeviceTree/DTSource3.8.13/

Open up am335x-bone-common.dtsi and go to line 401 (pass the -c flag to nano to show line numbers). This is the section concerning i2c2.

 nano -c am335x-bone-common.dtsi 
&i2c2 {
	status = "okay";
	pinctrl-names = "default";
	pinctrl-0 = <&i2c2_pins>;

	clock-frequency = <100000>;

	cape_eeprom0: cape_eeprom0@54 {
		compatible = "at,24c256";
		reg = <0x54>;

	cape_eeprom1: cape_eeprom1@55 {
		compatible = "at,24c256";
		reg = <0x55>;

	cape_eeprom2: cape_eeprom2@56 {
		compatible = "at,24c256";
		reg = <0x56>;

	cape_eeprom3: cape_eeprom3@57 {
		compatible = "at,24c256";
		reg = <0x57>;

To prevent the pinmux from being applied, simply comment out line 404

//	pinctrl-0 = <&i2c2_pins>;

Save and exit, then build with (note, you're not building the file you just edited!)

dtc -O dtb -o am335x-boneblack.dtb -b 0 -@ am335x-boneblack.dts

Before overwriting your default device tree binary, back it up

sudo mv /boot/uboot/dtbs/am335x-boneblack.dtb /boot/uboot/dtbs/am335x-boneblack.orig.dtb

Now move your new binary in to place

sudo mv am335x-boneblack.dtb /boot/uboot/dtbs/

You'll get an error about preserving permissions, you can safely ignore this.

Now reboot your BBB and the i2c2 pinmux will not be applied. Now you should be able to enable dcan0 in much the same way as dcan1. As root (not sudo!)

 echo BB-DCAN0 > /sys/devices/bone_capemgr.*/slots 

Now grab can-utils and play around with the bus (see above for dcan1).

If you plan to use dcan0 and dcan1, I believe the device driver numbering is based on the order the devices are enabled. So enable dcan0 before dcan1 so that your calls to ip, ifconfig, candump, etc... all make sense!

Posted in BeagleBone Black, Car Hacking
50 comments on “Enable CANBus on the BeagleBone Black
  1. Stephen says:

    Thanks, this is the first tutorial that worked for the 3.8 kernel.

  2. Fernando says:

    Hi Owen,

    I'm trying to make the BBB communicate with a CAN testing setup that i have here in my lab. I know that the setup works, because other equipments works well with it, but I can't get the BBB to comunicate with the bus.

    I followed your tutorial and I get can0 listed in ifconfig. The only difference is that my testing setup works with the bitrate of 250000. Then I tried to use the canconfig to set the parameters (tq, prop-seg etc) but when I start the bus ( $ canconfig can0 start ) I get ERROR-ACTIVE as can0 state.

    When I start candump ( $ candump can0 ) it only output is "interface = can0, family = 29, type = 3, proto = 1". I know that my setup continuously sends data trough the bus, so, it was supposed to show some data on the terminal...

    I'm using angstrom with kernel 3.8.13. I've connected the can interface of the beagle using a sn65hvd230 transceiver from texas. Using a oscilloscope on the pin 26 of the bone I can se that the transceiver is working. Do you have any ideas of what could be the problem?

    • Owen says:

      Hi Fernando,

      When I tested my set up I did not use canconfig at all. Immediately after doing "sudo ifconfig can0 up" i was able to use "sudo ./candump can0" and get data.

      I have just noticed that my guide had a mistake where I talked about enabling the bus, it said to do "sudo ifconfig can0", which prints some information but doesn't do anything useful! As I just mentioned (and have now corrected in the guide), using "sudo ifconfig can0 up" should be enough to start the device.

      Let me know if this works for you, if not I will have a think about what else it could be.



      • Fernando says:

        I just found the problem... I had inverted the canbus tx and rx pin on the beaglebone. Now its working like a charm..

        Thank you for the tutorial, it was VERY useful!

        • Owen says:

          I'm glad you found it useful!

          I've hooked up RX/TX pins backwards more times that I can count, but at least you're up and running now!

        • Pratik Parve says:

          dear fernando,
          Im implempenting DCAN driver on beglebone with FreeRTOS support.
          I got stuck in testing OF BB.im trying to check it in loopback mode ..needs procedure or documentation for reference

    • longqi says:

      v3.8.13-bone40 debian demo image

      I have almost the same equipment and same problem. The only difference is I have NO extra transceiver. I use two BBB connected by 9_24, 9_26 and GND directly. Two sides have same configuration. I can't transfer data even I exchange can_H can_L or add a 120 ohm resister.
      The transceiver is necessary for this case? Or It's because of any other thing?

  3. Marco Faletra says:

    Hi, I tested your tutorial and it work fine for DCAN1.
    But when I try DCAN0, this is what happen:
    [ 1905.962041] bone-capemgr bone_capemgr.9: bone: Using override eeprom data at slot 8
    [ 1905.962094] bone-capemgr bone_capemgr.9: slot #8: 'Override Board Name,00A0,Override Manuf,BB-DCAN0'
    [ 1905.962393] bone-capemgr bone_capemgr.9: slot #8: Requesting part number/version based 'BB-DCAN0-00A0.dtbo
    [ 1905.962449] bone-capemgr bone_capemgr.9: slot #8: Requesting firmware 'BB-DCAN0-00A0.dtbo' for board-name 'Override Board Name', version '00A0'
    [ 1905.963044] bone-capemgr bone_capemgr.9: slot #8: dtbo 'BB-DCAN0-00A0.dtbo' loaded; converting to live tree
    [ 1905.970516] bone-capemgr bone_capemgr.9: slot #8: #2 overlays
    [ 1905.973809] platform 481cc000.d_can: alias fck already exists
    [ 1905.978598] pinctrl-single 44e10800.pinmux: pin 44e10978 already requested by 4819c000.i2c; cannot claim for 481cc000.d_can
    [ 1905.990635] pinctrl-single 44e10800.pinmux: pin-94 (481cc000.d_can) status -22
    [ 1905.998382] pinctrl-single 44e10800.pinmux: could not request pin 94 on device pinctrl-single
    [ 1906.036234] c_can_platform 481cc000.d_can: failed to configure pins from driver
    [ 1906.036494] c_can_platform 481cc000.d_can: invalid resource
    [ 1906.042605] c_can_platform 481cc000.d_can: control memory is not used for raminit
    [ 1906.063080] c_can_platform 481cc000.d_can: c_can_platform device registered (regs=fa1cc000, irq=68)
    [ 1906.065721] bone-capemgr bone_capemgr.9: slot #8: Applied #2 overlays.
    How can I change the pin from i2c to Can?
    Thank you.

    • Marco Faletra says:

      Sorry, I missed some info: this is .dts


      / {
      compatible = "ti,beaglebone", "ti,beaglebone-black";

      /* identification */
      part-number = "dcan0pinmux";

      fragment@0 {
      target = ;
      __overlay__ {
      dcan0_pins_s0: dcan0_pins_s0 {
      pinctrl-single,pins = ;

      fragment@1 {
      target = ;
      __overlay__ {
      #address-cells = ;
      #size-cells = ;

      status = "okay";
      pinctrl-names = "default";
      pinctrl-0 = ;


      • Owen says:

        Hi Marco,

        Thanks for the feedback. Unfortunately this comment system doesn't like angled brackets so your dts file didn't appear properly. However, I'm sure it is correct as I got the same error when I tried dcan0.

        I've just been playing around with a few different ways of disabling i2c2 and have come up with a workaround. I have updated the blog post with the details (see the new section 'Enabling DCAN0'). I don't have a CAN device available, but I stuck an oscilloscope on the TX pin and it seems to be working fine. So hopefully this will work for you!

        If you have any more problems, just let me know!



        • Marco says:

          Hi Owen, thanks for the tip.
          It works like a charme. I do this: instead to change am335x-bone-common.dtsi I changed am335x-boneblack.dts with:
          &ampi2c2 {
          pinctrl-0 = "";
          (I hope you can see it.)
          And then follow your tutorial.

  4. Mark Lazarewicz says:

    I am using a white with an DIGIKEY Serial cape version A2 with Ubuntu from here http://eewiki.net/display/linuxonarm/BeagleBone#BeagleBone-LinuxKernel

    I get these messages

    [ 4.972169] bone-capemgr bone_capemgr.8: failed to load firmware 'BB-BONE-SERL-01-00A2.dtbo'\par
    [ 4.981164] bone-capemgr bone_capemgr.8: loader: failed to load slot-0 BB-BONE-SERL-01:00A2 (prio 0)\par

    I renamed my .dbto I built using your instructions to BB-BONE-SERL-01-00A2.dtbo' copied it to /lib/firmware it boots

    From there I cant get the correct command to use for echo BB-DCAN1 > /sys/devices/bone_capemgr.*/slots

    I tried renaming it and I did it as root its returns an error

    excellant tutorial please help I am just learning device tree

    • Owen says:

      Hi Mark, thanks for the comment. I'll try and help you the best I can...

      Firstly, I've not tested any of this on a white, or with the serial cape, but here are my initial thoughts.

      Does the serial cape support CANBus? It sounds like it is an RS232 breakout or something, which might use the same pins but probably won't work. Forgive my ignorance here as I have never used the serial cape and a quick google of it has not given me much information!

      The EEPROM on the cape will be interrogated by the device tree driver on boot, and this will attempt to load the overlay to support the cape. Based on your experience I would say the current Ubuntu builds do not have this overlay installed (unfortunately I don't have my dev environment to hand to check right now!). I would not bother renaming the overlay file as you did (since I think overlays must be built different to support capes), simply try following my instructions exactly. If this does not work (as you suggested it may not), post any errors here and I will try to make sense of them.

      If you have access to an oscilloscope/logic analyser I would suggest checking that my tutorial works without the cape installed (simply scope the pins and see if anything happens). As I said I have not tested this on a white so there may be something fundamental I'm missing.

      Let me know if any of this helps you, or what errors you get and I'll try to help you where ever I can.



      • Mark Lazarewicz says:

        The Digikey Serial cape was shipped configured to support CAN. Its marked that way and is ann A2
        ITS HERE http://circuitco.com/support/index.php?title=BeagleBone_CANBus

        Kernels says failed to load BB-BONE-SERL-01-00A2.dtbo

        Doesnt this mean my .dts and dtbo must match this

        which cape is this tutorial for? I also have several TowerTech Can capes. http://circuitco.com/support/index.php?title=TT3201_CAN_Cape I have not tried yet
        I resist using Angstrom as building kernelfrom scratch has never worked for me

        I followed the tutorial exactly and it fails at echo BB-DCAN1 > /sys/devices/bone_capemgr.*/slots
        Is says the file is not found. what is purpose of this command and how does it know what BB-DCAN1 is?

        I am thinking since the eeprom tells it its a serial cape this echo above will never work thats why I renamed the .dbto file iwconfig showed can0 but thats it.
        modprobe showed no can

        How bout I wait for my Black I just need to know which cape you used and confirm Ubuntu will work

        • Owen says:

          Hi Mark, sorry for my delayed reply, I have been moving house and not had a stable internet connection!

          I did not use any cape when making this tutorial, I simply hooked up a CAN transceiver to the relevant pins. However, I see now reason why it shouldn't work with the cape, it may simply be a device tree conflict.

          After a clean boot with the cape installed, what is the output of the command

          cat /sys/devices/bone_capemgr.*/slots

          Also, what is the output of

          ls /lib/firmware/*.dtbo

  5. Mark Lazarewicz says:

    So I plugged in the towertech and short of probing the pins everything works out of the box on the white
    Sorry to hog the thread but I am confused where on Ubuntu are these .dbto files stashed?
    and whaf are the .dbts files placed in /media/boot/dtbs/ ???

    Here is the TowerTech load

    Ubuntu 13.04 arm ttyO0
    arm login: ubuntu
    Last login: Sun Sep 15 22:02:12 UTC 2013 on ttyO0
    Welcome to Ubuntu 13.04 (GNU/Linux 3.8.13-bone28 armv7l)
    * Documentation: https://help.ubuntu.com/
    ubuntu@arm:~$ dmesg | grep -i can
    [ 0.150126] of_get_named_gpio_flags: can't parse gpios property
    [ 1.493411] bone-capemgr bone_capemgr.8: slot #3: 'TT3201 CAN Cape,01,TowerTech,TT3201-001'
    [ 1.589830] bone-capemgr bone_capemgr.8: slot #3: Requesting firmware 'TT3201-001-01.dtbo' for board-name 'TT3201 CAN Cape', version '01'
    [ 1.738159] platform 481d0000.d_can: alias fck already exists
    [ 1.867460] of_get_named_gpio_flags: can't parse gpios property
    [ 1.867475] of_get_named_gpio_flags: can't parse gpios property
    [ 1.940376] pinctrl-single 44e10800.pinmux: pin 44e10854 already requested by 44e10800.pinmux; cannot claim for gpio-leds.7
    [ 11.911737] CAN device driver interface
    [ 12.008827] c_can_platform 481d0000.d_can: invalid resource
    [ 12.014797] c_can_platform 481d0000.d_can: control memory is not used for raminit
    [ 12.206140] c_can_platform 481d0000.d_can: c_can_platform device registered (regs=fa1d0000, irq=71)
    [ 12.496725] mcp251x spi1.0 can1: probed
    [ 12.527095] mcp251x spi1.1 can2: probed

    • Owen says:

      The dtbo files live in /lib/firmware (see my previous reply).

      That dmesg output seems to suggest the cape is supported by the TT3201-001-01 overlay, and seems to be working. As I said, I wrote this tutorial for using the CAN pins directly, not using a cape, so if this overlay is meant for the cape I would recommend using it instead!

  6. Mike says:

    I'm trying to place BB-DCAN1 on uEnv.txt to get this pinmux loaded at the begining but no luck.....



    [ 2.865623] bone-capemgr bone_capemgr.8: failed to load firmware 'BB-DCAN1-00A0.dtbo'
    [ 2.873937] bone-capemgr bone_capemgr.8: loader: failed to load slot-7 BB-DCAN1:00A0 (prio 0)
    [ 2.882936] bone-capemgr bone_capemgr.8: loader: check slot-6 BB-BONELT-HDMIN:00A0 (prio 2)
    [ 2.891719] bone-capemgr bone_capemgr.8: loader: check slot-5 BB-BONELT-HDMI:00A0 (prio 1)

    Also devloped a new pcb to use with can , the prototype works like a charm..... at 1mb/s 8000 fps without any issue 24 hours..... 100% busload.....

    Really the mos cheap gw betwen eth to can....... i seen.


    • Owen says:

      Hi Mike,

      I'm afraid I've never had any success getting enable_partno to work. If your running Ubuntu I'd recommend sticking the "echo BB-DCAN1 ..." line in /etc/rc.local, this will run the command after Ubuntu has booted and enable your CAN device. For this to work for me I had to replace that * wildcard with the actual number (which seems to be different between boards for reasons unknown to me!), so my rc.local looks like

      ubuntu@arm:~$ cat /etc/rc.local
      #!/bin/sh -e

      echo BB-DCAN1 > /sys/devices/bone_capemgr.8/slots

      exit 0

      If you're on Angstrom it is a little bit harder to run commands on boot, as they don't use rc.local. Check out this thread for some examples of Angstrom auto starting: https://groups.google.com/forum/#!topic/beagleboard/6GmHGPgnY84

      I hope this helps!


      • Mike says:

        Thanks Owen,

        I solved them, on the init.d creating a init script to start DCAN0 and DCAN1 now have the pcb's and all works perfect !!

        Can place the PCB (I called them semi-cape) on vertical or horizontal...... If you like to get one please let me know and I will sends to you for this great tutorial.....

        Very Much Thanks !!

        • Sam Crooks says:


          do you have more information on your BeagleBone CAN cape prototype? or a circuit diagram published anywhere?

          I'm considering my own cape due to issues with the CircuitCo CAN Cape (connector placement interferes with cases and single CAN channel only) and Towertech Cape (lacking optoisolators and a good connector for wiring).


  7. kees says:

    I tried your method to enable dcan0 with the latest kernel version from https://github.com/beagleboard/kernel/tree/3.8

    Unfortunately, the kernel does not boot. I think it's because the I2C-2 is not found:
    bone-capemgr bone_capemgr.9 slot #0: failed to find i2c client
    bone-capemgr bone_capemgr.9 slot #0: failed to add slot #1

    These message can be found as patch here https://lkml.org/lkml/2013/1/7/367.
    When I fully outcomment the I2C-2 device in the am335x-bone-common.dtsi, I get other errors

    • Owen says:

      Unfortunately I don't have a BBB to hand right now, but I'll see what I can do...

      Are those the very last messages you see before the boot fails? Whilst they clearly represent an error they don't seem like something which would kill the boot.

      If this is the cause it may be that they i2c device can't start without a pin mux applied, so try commenting out the pinmux settings for i2c2_pins (so they can be applied, but do nothing). I'm not sure precisely where these are located, but they will look like lines 14-17 of my DCAN0 dts (but with i2c2_pins instead of dcan0_pins_s0). Comment out the hex between the angled brackets and see if this helps.

      I'll be back to my BBBs in a few days, so if you're still stuck I can give more specific help then.



  8. kees says:

    I figured out I commented out the I disabled the last two slots (@101 and @102). Probably that result in not-booting. Anyway, now the system boots with
    //pinctrl-0 = ;

    But I get a message "d_can.0: alias fck already exists". Probably because the I2C is still enabled (although pinmux is set wrong in dcan0 mode).

  9. Graetz says:

    Hi Owen,

    thanks for that outstanding Howto; can device 1 is up on my BBB. Cheerio!

    How did you connect your BBB to your car and what did you configure in the BBB (HW address, commands, etc.). Did you use a transceiver like Microchip's MCP 2551 (do you have a wiring plan)?

    Would be great - and me very happy - if you share that knowledge too; email is fine. ;-)


  10. Hossein Zolfi says:

    Hi Owen,
    Thanks for this article. Unfortunately, when deploying new am335x-boneblack.dtb on my board, the BBB will not be boot.

    Could you please help me to fix it?

    Thanks again.

  11. Sam Crooks says:

    how to make it start up at boot:

    place this in /etc/rc.local:

    #!/bin/sh -e
    # rc.local
    # This script is executed at the end of each multiuser runlevel.
    # Make sure that the script will "exit 0" on success or any other
    # value on error.
    # In order to enable or disable this script just change the execution
    # bits.
    # By default this script does nothing.

    su -c "echo BB-DCAN0 > /sys/devices/bone_capemgr.*/slots"
    su -c "modprobe can"
    su -c "modprobe can-dev"
    su -c "modprobe can-raw"

    su -c "ip link set can0 up type can bitrate 500000"
    su -c "ifconfig can0 up"

    su -c "echo BB-DCAN1 > /sys/devices/bone_capemgr.*/slots"
    su -c "ip link set can1 up type can bitrate 125000"
    su -c "ifconfig can1 up"

  12. Jean-Claude Wippler says:

    Would it be an option to provide a pre-compiled "BB-DCAN1-00A0.dtbo" to avoid having to apply, build, and install the dtc patch? I'm new to all this, and trying to find a way to get started with CAN on BBB.

  13. Nik says:

    Hi Owen, first of all a big THANK YOU for your time and your good job on doing this!

    There is something I would like to ask: with a BBB I'm using a (white board) CAN cape, and after some troubleshooting now it works very well. I can put CAN0 in candump mode and in another console from the same machine do a cansend to the same CAN0 and see that it works (receives data).
    I'm trying to do the same without cape board, just plane BBB and a transceiver using your tutorials but something doesn't work: i can do a candump and I see data flow on the network (coming from a can device which keeps sending data). BUT.... When I try to cansend something, nothing happens (no data are sent) and at the same time can0 stops receiving data.
    I tried to remove the transceiver, checked CAN0 output pins with an oscilloscope... Nothing. No data out.
    CAN0 seems locked at that point and the only way to re-enable data receiving is to ifdown and ifup again CAN0.
    I tried googling around and again read point by point your tutorial searching for something that perhaps I've been missing, but I believe that I've done everything right and still i can't CANSEND anything!
    I would like to ask: am I the only one with such a problem? Have you any suggestion to give?
    Thank you again


  14. Juan C says:

    Hi Owen, first of all, great job.
    I have some questions about it:
    1) Can I work with only DCAN0? or Is necessary to have available both of them?
    2) Is necessary to have a transeiver or you connect directly to OBD car?
    3) Could you share your connection design? It is not very clear with the picture.

    Thanks a lot!!

  15. Jin says:

    Hi Owen,
    Thanks for your useful post.
    I have a question on connecting 2 BBB via CANBus. I followed your post to get the DCAN1 up, I used DCAN1 to send data between two BBB by MCP2551 transceiver like this topology BBB-MCP2551======MCP2551-BBB. On 1st BBB, I used cansend to send data (cansend can0 aaa#aaaaaaaa) and on 2nd BBB I used candump (candump can0) to look for coming data but I got nothing on from candump. Using oscilloscope I found that the signal comes out BBB-DCAN1-TX pin and MCP2551-RX pin as well, but can't see anything on 2nd BBB.
    Did I do right by connection 2 BBB this way?

  16. Juan C says:

    Any one can help me

  17. João says:

    Hi, I'm implementing a dcan1 on my beaglebone black. I'm doing everything as posted in this forum. However, when I try to see something through an osciloscope, I see nothing.
    I'm trying to watch some signal on the P9_26 pin, thats the responsable for the dcan1_tx. I'm executing cansend can0 -i 0x10 command and others (http://processors.wiki.ti.com/index.php/AM335x_DCAN_Driver_Guide) so I can see something moving.
    I can only see a 3v3 signal, nothing else. Can someone help me? Any sugestion?

    dmesg | tail -n15 gives everything as shown above.

    • Ed says:

      I also am unable to get either can0 or can1 working. Did you figure out the problem? I also am using an oscilloscope to analyzed the tx line but I an getting DC 3.3V. Any help would be appreciated. Thanks

    • Daddy Dave says:

      Though I have zero experience with the BeagleBone, I have been doing CAN for almost 20 years. CAN needs to see something else on the bus before it will toggle any pins. What it is trying to do is Assert the bus and it is monitoring pins to see that it has Asserted. Nothing happens so your CAN waits. The way I solve this problem is by using a CAN Analyzer where I can watch the data. Those are $300-$400, though. There should be anything else that can work. There is often a way to put CAN in a loopback mode. Don't know if that can be done with a BeagleBone.

  18. Lily says:

    Hi Fernando,
    Can I ask how you get your BBB access to Internet?

  19. Edwin says:

    I am still unable to get either can0 or can1 working. Is there a command I can call to confirm that I set up the GPIO setting correctly? I want to know I am successfully turning off the I2C on P9_19 and P9_20 to turn on can0. I have a CAN transceiver but right now I just want to see a tx signal on the oscilloscope.

  20. L31N says:

    Owen thanks !
    Very nice tutorial ...
    I followed your instructions for DCAN1 and basically it works fine.
    But when I try to send data to my BBB relatively fast,
    let's say 400 frames/s I have the problem that my ubuntu hangs up and I have to press the reset button.
    I spent much of time to find reason for this Problem and figured out that it only occures if I really read the data with candump or an own socketCAN application. Then it reads for an indefinite time and hangs up. I have also tried different bitrates (1MBPS, 500KBPS, 100KBPS) always the same. Memory usage is not increasing. syslog and kern.log doesn't contain anything about the hangup.

    Do you have an assumption about the reason ?
    I don't know how to continue ...



  21. Oliver says:

    Hey Owen,
    thanks for all this information!!

    Btw. the repository for the can-utils changed some time ago.

    The latest (and greatest) can-utils can be downloaded from:

    See at http://en.wikipedia.org/wiki/SocketCAN#External_links


  22. Tobias says:

    SocketCAN doesnt use SVN anymore. You can now checkout canutils via:

    git clone https://git.gitorious.org/linux-can/can-utils.git

  23. Jared Wiltshire says:

    I couldn't get the overlays to enable on boot so if you want to enable DCAN0 and DCAN1 on boot perform the following patch, or just clone my fork and compile and install as per the blogs instructions.

    Then you can just add the following to /etc/network/interfaces to bring up can0 and can1 on boot. See 'man interfaces'

    auto can0
    iface can0 can static
    bitrate 500000

    auto can1
    iface can1 can static
    bitrate 500000

  24. Emre says:

    Hi ,

    I have a problem about enabling to can pins .

    so my problem is , after the write this command

    sudo ip link set can0 up type can bitrate 500000

    İ have get error message "cannot find can0 device "
    so why I'm get this message.

    is there any idea ? .

  25. Steve B says:

    On the Angstrom 3.8.13 kernel, there was no /boot/uboot/dtbs/ and the am335x-boneblack.dtb was found in /boot but aside from that this all worked just fine for me.

  26. Arthur Summers says:

    I'm just now looking at using a BeagleBone to connect to my car's CAN interface. I've never used a BeagleBone, so I'm trying to research its capabilities, and I hoped someone could clear up some of my confusion.

    Since the BeagleBone has two CAN interfaces (DCAN0 and DCAN1), why isn't it possible to simply use a breakout for the pins on the board itself and connect these wires to the car's OBDII? Is it possible to use a board like the following to send and receive CAN dada?

    If not, is this why there are CAN transceiver capes on the market? What transceiver did you use?

    Thanks for your help!

  27. CAN bus _must_ be connected through a transceiver or some sort of open collector driver for low speeds. The CAN device monitors the Tx line with the Rx line to make sure that what it sent is what it's receiving. It also looks in at a bit position for an ACK. The nomenclature is dominant and recessive.
    Think of Recessive as an open collector circuit that holds the bidirectional bus CAN_H and CAN_L at 2.5V. A Dominant signal pulls the CAN_H line up to about 4V (3V for the 3.3V CAN drivers) and the CAN_L line down to around 1V. Now you have a 2V to 3V difference between the levels and that signals a Dominant.
    The CAN bus looks for a recessive level before issuing a Dominant Start bit. Then we have 11 or 29 Identifier bits mixed up with a few others. After that the Data Length Control (DLC) bits. The Identifier bits determine the priority of the message where a dominant has higher priority than a recessive. A node sending a dominant at the same time as another node sending a recessive results in the dominant bit wins ID bit arbitration and that message is transmitted. The DLC, 8 data bytes and CRC are not bit wise arbitrated.
    That's why there's a rule that you can't have identical IDs with non-identical data. There's also bit stuffing. Slot delimiters that are recessive. The CRC delimiter and the ACK delimiter surround the recessive ACK bit with two more recessive. The ACK is not transmitted by the sending node. The node that successfully receives the messages inserts an ACK (dominant) over top of the recessive.

    So you can't connect two CAN devices together without drivers. And, since it's a transmission line and the drivers are not truly differential like RS485, you must have termination resistors at both ends of the bus.

Leave a Reply

Your email address will not be published. Required fields are marked *


8 + eight =

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>