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.
/dts-v1/; /plugin/; / { 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 2013: I'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.
PinSlew RateInputPull UpPull UpModeModeModeIn Hex
d_can1_tx (0x180)00100100x12
d_can1_rx (0x184)01100100x32
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/ make
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.
/dts-v1/; /plugin/; / { 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!
Thanks, this is the first tutorial that worked for the 3.8 kernel.
Hi Stephen, I'm glad this was helpful!
Are you using the default Angstrom image?
Yes, I downloaded the most recent Angstrom image before following you're tutorial and it worked perfectly. I may try it with Ubuntu in the future.
Thanks for confirming that. All my BBBs are on Ubuntu so I've never tested this on Angstrom, but I had no reason to doubt it would work. Now I can say for sure it does!
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?
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.
Cheers,
Owen
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!
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!
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
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?
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.
Sorry, I missed some info: this is .dts
/dts-v1/;
/plugin/;
/ {
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 = ;
};
};
};
Regards.
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!
Cheers,
Owen
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:
&i2c2 {
pinctrl-0 = "";
};
(I hope you can see it.)
And then follow your tutorial.
Regards.
Good to hear you've got it working!
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
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.
Cheers,
Owen
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
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
you mean I must have a transceiver so I can use the can bus?
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
Password:
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
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!
I'm trying to place BB-DCAN1 on uEnv.txt to get this pinmux loaded at the begining but no luck.....
optargs=capemgr.enable_partno=BB-DCAN1
result
[ 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.
Cheers,
Mike
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!
Owen
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 !!
Mike:
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).
Sam
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
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.
Cheers,
Owen
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).
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.
best!
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.
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"
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.
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
Nik
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!!
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?
Any one can help me
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.
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
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.
@Ed and Daddy Dave: Did you solve your problem with CAN1? I have exactly the same on my BBB Rev. A6. The TX line has 3.3 volt and no change occurrs when I send data with cansend.
Torsten
Hi Fernando,
Can I ask how you get your BBB access to Internet?
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.
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 ...
Thanks
L31N
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:
https://gitorious.org/linux-can/can-utils/
See at http://en.wikipedia.org/wiki/SocketCAN#External_links
Oliver
SocketCAN doesnt use SVN anymore. You can now checkout canutils via:
git clone https://git.gitorious.org/linux-can/can-utils.git
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.
https://github.com/jazdw/boneDeviceTree/commit/9e6a5ecaa1ce5cecdea5a87622d292e53e3d1680
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
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 ? .
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.
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?
http://inspire.logicsupply.com/2014/06/cbb-serial-automotive-can-bus.html
If not, is this why there are CAN transceiver capes on the market? What transceiver did you use?
Thanks for your help!
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.
I would point out that you may not be able to use a monitor plugged into the bbb once you've disabled i2c2. Older monitors will still work but the newer ones that use DDC2 require i2c2.
This CAN-BUS Shield adopts MCP2515 CAN Bus controller with SPI interface and MCP2551 CAN transceiver to give your Arduino/Seeeduino CAN-BUS capibility.
http://www.elecfreaks.com/store/canbus-shield-p-746.html