BBB- DCAN1 problems using latest debian image

Hi,

I have been trying to build a proof of concept system using two beaglebone black units with there DCAN1 (pins P9_24 and P9_26) and two can transcievers TI SN65HVD251P.
The can transceivers are powered from the same 5V bench supply as both of the beaglebone blacks. the canh and canl pins are terminated at both ends by 120R resistors to ensure the 60R bus impedence.

I was following the instructions in other posts about updating to the latest debian version and then upgrading the kernel to 3.14. This i have done.

uname -a
Linux beaglebone 3.14.35-ti-rt-r56 #1 SMP PREEMPT Sun Mar 29 01:13:05 UTC 2015 armv7l GNU/Linux

I added dtb=am335x-boneblack-can1.dtb to the uEnv.txt

I have also installed the canbus tools within the image so i can attempt a cangen can0 and candump can0.

On system boot i am doing the following:

modprobe can
modprobe can-dev
modprobe can-raw

ip link set can0 type can bitrate 125000 triple-sampling on
ifconfig can0 up

however if i use candump can0 and cangen can0 within two seperate putty sessions i dont see anything.

If I create a vcan bus i do see the messages in loopback.

sudo modprobe vcan
sudo ip link add dev vcan0 type vcan
sudo ifconfig vcan0 up

Previously I was using an older debian image and found that when i ran cangen can0 that the buffer would give me an error that it was full. however now with the latest image i am not getting the bufer full message but still not seeing anything on the candump. What should i expect to see here?

Can anyone see where I have gone wrong or a step i am missing?

Thanks in advance.

Mark

Hi Mark,

I would rebuild the device tree to make sure can0 is included.

  • Revert the changes to uEnv.
  • download Robert Nelson’s dtb-rebuilder (https://github.com/RobertCNelson/dtb-rebuilder) and checkout 3.14-ti.
  • edit am335x-boneblack.dts to include can0.
  • make am335x-boneblack.dtb and replace the original file in /boot/dtbs/3.14.35-ti-r56/
  • reboot.

Regards
Rui

Hi Rui,

I have reverted the changes to uEmv to comment out the #dtb line

I then modified am335x-boneblack.dts to uncomment so that it looks like the following:

/*can0: P9.19, P9.20: disable: i2c2: cape eeprom /
/
can0: peripheral /
#include “am335x-can0.dtsi”
/
can0: pinmux */
#include “am335x-bone-can0.dtsi”

/* can1: P9_24, P9_26 */
#include “am335x-can1.dtsi”
#include “am335x-bone-can1.dtsi”

I built the dtb using dtb-rebuilder and copied the new am335x-boneblack.dtb to /boot/dtbs/3.14.35-ti-rt-r56/ and rebooted the system.

Now when i look in the /sys/kernel/debug/pinctrl/44e10800.pinmux/pinmux-pins

pin 94 (44e10978.0): P9_20_pinmux.47 (GPIO UNCLAIMED) function pinmux_P9_20_i2c_pin group pinmux_P9_20_i2c_pin
pin 95 (44e1097c.0): P9_19_pinmux.46 (GPIO UNCLAIMED) function pinmux_P9_19_i2c_pin group pinmux_P9_19_i2c_pin

pin 96 (44e10980.0): P9_26_pinmux.53 (GPIO UNCLAIMED) function pinmux_P9_26_can_pin group pinmux_P$
pin 97 (44e10984.0): P9_24_pinmux.51 (GPIO UNCLAIMED) function pinmux_P9_24_can_pin group pinmux_P$

It seems that the DCAN0 is still associated with i2c and not can0. However I can now use
ip link set can1 type can bitrate 125000 triple-sampling on loopback on
ip link set can0 type can bitrate 125000 triple-sampling on loopback on

and bring up both can devices.

If i do candump can0 and cangen can0 i do see loopback messages

however when connected with two transceivers one connected to can0 and other can1 and then running cangen can0 and candump can1 i dont get any transmitted bits.

I tried using a scope on CANTX P9_26 to ground and find that nothing is coming out of this pin. I also found that running cangen can0 after a few seconds i am getting this error.

cangen can0
write: No buffer space available

could you give me a step by step from boot up to get the canbus running to see if there is something I am missing?

Thanks

Mark

Hi Mark,

On my system I have dtb=am335x-boneblack.dtb, I don’t think you should comment it out.

Are you using both can0 and can1? You should enable just the one you need.
If you are using can0 you must comment out i2c2: cape eeprom because it uses the same pins.

Regards,
Rui

what a night mare to get something simple to work. ditch Linux use barebones

Hi Lazarman. It is more difficult that i first thought.
However for what we are developing doing it in embedded will take weeks, if we get the canbus working in linux we can build a prototype demonstrator in a much shorter period of time.

Hi Rui,

I disabled can1 as i dont need to do a hardware loopback.

I now have setup two identical systems (beaglebone black Rev C) on the bus with dcan1 (P9_24 and P9_26) and running Linux beaglebone 3.14.35-ti-rt-r56.
After following the advice of RobertCNelson in another thread Redirecting to Google Groups I changed the dtb=am335x-black-can1.dtb

On reboot i have done the following:

sudo modprobe can
sudo modprobe can-dev
sudo modprobe can-raw
sudo ip link set can0 up type can bitrate 500000
sudo ifconfig can0 up

I checked the mux pin status for the /sys/kernel/debug/pinctrl/44e10800.pinmux/pinmux-pins

pin 96 (44e10980.0): P9_26_pinmux.53 (GPIO UNCLAIMED) function pinmux_P9_26_can_pin group pinmux_P9_26_can_pin
pin 97 (44e10984.0): P9_24_pinmux.51 (GPIO UNCLAIMED) function pinmux_P9_24_can_pin group pinmux_P9_24_can_pin

That looks all fine. then checking that the can0 is active running

ip -details -statistics link show can0

can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN mode DEFAULT qlen 10

link/can

can state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0

bitrate 500000 sample-point 0.875

tq 125 prop-seg 6 phase-seg1 7 phase-seg2 2 sjw 1

c_can: tseg1 2…16 tseg2 1…8 sjw 1…4 brp 1…1024 brp-inc 1

clock 24000000

re-started bus-errors arbit-lost error-warn error-pass bus-off

0 0 0 0 0 0

RX: bytes packets errors dropped overrun mcast

0 0 0 0 0 0

TX: bytes packets errors dropped carrier collsns

0 0 0 0 0 0

On system A: I started cangen can0

On system B: I started candump can0

No data… but i dont get a write buffer error either. On checking the ip -details link show can0
System A:

can0: <NO-CARRIER,NOARP,UP,ECHO> mtu 16 qdisc pfifo_fast state DOWN mode DEFAULT qlen 10

link/can

can state BUS-OFF (berr-counter tx 248 rx 0) restart-ms 0

bitrate 500000 sample-point 0.875

tq 125 prop-seg 6 phase-seg1 7 phase-seg2 2 sjw 1

c_can: tseg1 2…16 tseg2 1…8 sjw 1…4 brp 1…1024 brp-inc 1

clock 24000000

system B

can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN mode DEFAULT qlen 10

link/can

can state ERROR-PASSIVE (berr-counter tx 0 rx 127) restart-ms 0

bitrate 500000 sample-point 0.875

tq 125 prop-seg 6 phase-seg1 7 phase-seg2 2 sjw 1

c_can: tseg1 2…16 tseg2 1…8 sjw 1…4 brp 1…1024 brp-inc 1

clock 24000000

Now after some digging I found that the can-bus starts in error-active then if it doesn’t get a reply to a message after 127 errors we get error-passive and after 255 errors it goes into BUS_OFF.

I believe i might have a hardware issue to resolve so I will dig into this now and see if i can solve it.

What does everyone else think?

Now after some digging I found that the can-bus starts in error-active then if it doesn’t get a reply to a message after 127 errors we get error-passive and after 255 errors it goes into BUS_OFF.

Hey mark. I have zero hands on with anything CAN. However I have done some reading on CAN, and this seems like expected behavior to me. Maybe I misunderstood what I’ve read in the past. But CAN, to me, software side seems to be exactly like ethernet, only with hardware timeouts. Meaning, if a device does not respond in a set amount of time. It gets knocked off the network.

For what it is worth. Looks like I’ll be picking up a CAN “hobby”. We recently bought a couple inverters that can communicate via CAN. Xanbus we think it uses. Or in other words. MODBUS.

Hi William / Rui,
After some investigation it looks like its a broken BBB DCAN1 channel. Using a scope i found i was able to generate can messages from a second BBB but couldn’t receive it on the first unit. However once I setup the the secondary CAN bus port on pin9_19 and 9_20 i found that the secondary channel works but 9_24 / 9_26 doesn’t work even with a fresh install. Connecting up the primary DCAN1 channel corrupts the canbus network.

But just to save everyone time and effort when dealing with Can I will explain the steps I did to get it to work below.

First off downloaded the latest debian image and wrote the image to a uSD card.
Then on the SD card I downloaded the linux3.14 image.

sudo apt-get update

sudo apt-get install linux-image-3.14.35-ti-rt-r56 ; sudo reboot

Once its rebooted then the next step is to setup the hardware layer. Depending on what you’re trying to achieve to enable DCAN1(P9_24 / P9_26) do the following.

nano /boot/uEnv.txt

Change line #dtb to state dtb=am335x-boneblack-can1.dtb and then reboot the BBB.

If you want to enable both CAN channels or the alternative one then I did this by changing the dtb line and then editing the dtb and rebuilding.
so first

dtb=am335x-boneblack.dtb

save the uEnv.txt file

you need to download the dtb rebuilder.

git clone -b 3.14-ti GitHub - RobertCNelson/dtb-rebuilder

cd dtb-rebuilder/

nano /src/arm/am335x-boneblack.dts

and then change the section of the file relating to the canbus to the following to enable both.

/* can0: P9.19, P9.20: disable: i2c2: cape eeprom */

/* can0: peripheral */

#include “am335x-can0.dtsi”

/* can0: pinmux */

#include “am335x-bone-can0.dtsi”

/* can1: P9_24, P9_26 */

#include “am335x-can1.dtsi”

#include “am335x-bone-can1.dtsi”

If you only want one leave can1 above commented out. Save the file and then in the dtb-rebuilder folder run

make

make install

This will copy the new dtb to the right place. You can then go along and reboot your system. When it boots up you can check to see if the pins are configured correctly by looking at the following.

nano /sys/kernel/debug/pinctrl/44e10800.pinmux/pinmux-pins

you should see
pin 94 (44e10978.0): P9_20_pinmux.47 (GPIO UNCLAIMED) function pinmux_P9_20_can_pin group pinmux_P9_20_can_pin
pin 95 (44e1097c.0): P9_19_pinmux.46 (GPIO UNCLAIMED) function pinmux_P9_19_can_pin group pinmux_P9_19_can_pin
pin 96 (44e10980.0): P9_26_pinmux.53 (GPIO UNCLAIMED) function pinmux_P9_26_can_pin group pinmux_P9_26_can_pin
pin 97 (44e10984.0): P9_24_pinmux.51 (GPIO UNCLAIMED) function pinmux_P9_24_can_pin group pinmux_P9_24_can_pin

if you have both can controllers configured.

Then all you need is the can_utils to be able to send test data.

cd ~/

git clone GitHub - linux-can/can-utils: Linux-CAN / SocketCAN user space applications

cd can-utils

./autogen.sh

before the next step there is an error on line 11660 of the config file edit with vim or nano to remove the ) on the line.
The easiest way is to open with vim.

vim ./configure

:11660

:w

:q

Then complete the install

./configure

make

make install

You can then load the drivers and setup the port

sudo modprobe can

sudo modprobe can-dev

sudo modprobe can-raw

sudo ip link set can0 up type can bitrate 125000

sudo ifconfig can0 up

and then use the can utils cangen can0 and see that data is coming out of the CAN_TX pin.

Lots of the above comes from posts by other users and i claim no credit, I just found following this procedure got two BBB talking to each other and a scope with a can analyser / generator.

Thanks everyone for the information in this and other posts.

Mark

Thanks for the info Mark, I can definitely put it to use. I just updated to TI’s linux-image-3.14.37-ti-r57, on a “test image”, so I should not have many problems I hope.

Later, I’ll have to move the rootfs over to my NFS server so I can give it “hell”.

I’m a little late on this discussion but since I have lots of CAN experience and I’m also working on getting CAN working on my Beagle so I thought I’d jump in.
I bought the Logic Supply CBB_Serial with the on board CAN driver.
I followed the instructions on page 14 of their Serial Cape Manual with the only exception that I had to change to
git clone https://github.com/linux-can/can-utils.git from the git://gitorious.org site.

I’ve always suggested when working with CAN in embedded systems the easiest solution is to have on hand one working functional CAN module. Ideally something like a CANUSB from Lawicel or one of the other dongles. The ability to generate well formed correctly timed messages can save you hours of time.

Since I had a working system I set the bit rate up to 250kbps becauseI was attaching to a CANOpen system. I’d done the ip link command at the start of the instruction sheet and now had to first
ifconfig can0 down
then redo the bit rate
ip link set can0 up type can bitrate 250000
finally
ifconfig can0 up

Imagine my surprise when I got a dump of the correct messages after running
candump can0.

Next step was to attach onto a project with custom CAN messages running 1Mbps. Same process but with 1000000 for bit rate.

In this case the host sends a block of messages for RGBW LED Lamp intensity to nodes 2 through 96 in even ID# increments because the odd node also receives the even node message and uses the second 4 bytes of each message for LED information.

Once every loop it waits a bit, then sends out a request to one specific node for node status; like temperature and bus voltage. Then starts the whole refresh cycle again. The example from candump is below.

root@beaglebone:~# candump -t d -n 12000 can0 >logfile_can.txt
root@beaglebone:~# nano logfile_can.txt

(000.000124) can0 290 [8] FC D3 40 FF FC D3 40 FF
(000.000126) can0 294 [8] FC D3 40 FF FC D3 40 FF
(000.000113) can0 298 [8] FC D3 40 FF FC D3 40 FF
(000.000110) can0 296 [8] FC D3 40 FF FC D3 40 FF ← last node polled
(000.001741) can0 446 [1] 28 ← Command for lamp status.
(000.008456) can0 546 [8] 28 D3 28 02 00 00 77 70 ← Reply from lamp 0x46
(000.020936) can0 202 [8] FC D3 40 FF FC D3 40 FF ← polling starts again.
(000.000085) can0 204 [8] FC D3 40 FF FC D3 40 FF
(000.000140) can0 208 [8] FC D3 40 FF FC D3 40 FF

However, I’m running into problems that completely crash the beagle. I run candump continuously rather than for a set number of messages. The 4 leds freeze. A power cycle is the only solution.
This happens when I use PuTTY from my WIN7 PC and the USB port and after a while the messages stop and it locks up. That could be a Windows problem since the USB port interface could lock up the beagle.

Next step was hard wired Ethernet to 192.168.0.125 and PuTTY. Now it appears to run without issues messages streaming by.
But, if I try to open any other session into the beagle via web and Cloud 9 I can get in but at some point the system locks up and freezes. Especially if I close the browser.

My first guess is I shouldn’t be running candump as root since the cloud 9 also logs in as root. Can it be as simple as that? But why would the system lock up?

@John D

Which kernel version are you running on the black ? kernel version 3.14.x is supposed to bring some USB, and ethernet improvements over kernel version 3.8.x. However, I’m not sure what exactly these improvement are. Anyhow, it was a thought while reading your post. I do know that early on with kernel 3.8.x if you tried to hotplug ethernet or USB, you’d get a kernel panic. Symptoms similar to what you’re explaining here, You’d try to hotplug, everything would work fine for around a minute, then the board / system would just freeze.

Another thought that I had was that you may be powering over USB only ? Perhaps you are not getting enough power.

You can always try:

$ sudo dmesg | less

OR

$ tail /var/log/messages

To see what may be happening. If that does not work, then maybe you can use strace to debug candump.

http://www.cyberciti.biz/tips/linux-strace-command-examples.html

Hi William,
uname -r returns 3.8.13-bone47 from the revC board that arrived a couple of weeks ago.
I’m running with a 2A supply since I as using a WiFi USB module. At the moment I’m hardwired again.
Following the instructions in Derek Malloy’s “Exploring Beaglebone” I created a user and a group. Also used visudo to add my user to the sudo file so I can run root stuff.
Logged on as the user I’ve now had the 1Mbps CAN messages running for over 4 hours. I can log in with Chrome into Cloud9 and create a terminal which automatically logs in as root. No more lock ups.
If I have more problems I’ll start a new thread. Very strange.
Thanks

Hi John,

I’m attempting to enable CAN support for a USB/CAN from a Lawicel. We have a custom board and need to use pin D17/D18 and E17/E18 for CAN1 and CAN2.

The pad names in u-boot/arch/arm/include/asm/arch-am33xx/mux_am33xx.h for the BBB includes i2c0_sda (pin C17) and i2c0_scl (pin C16), but I don’t see names for i2c2_scl (pin D17) and i2c2_sda (pin D18), nor tstpt1 (pin E17) nor TP9 (pin E18),

  1. Did I miss the names for these pins in u-boot?

  2. If u-boot does not support these pins, should they be added to u-boot, and/or added to the kernel to support these pins?

Should these pins be pinmuxed in both uboot and the kernel, or only in the kernel dts? Checking now to see if the kernel has support for these pins.

thx, Tracy

The CANUSB from Lawicel is a standard USB device that looks like a serial port since it can use the FTDI driver.

On my MachineKit Debian Beagle 2.0 when I plug in the CANUSB I find I have a /dev/ttyUSB0 device.

I installed putty and connected to /dev/ttyUSB0

In the terminal window

V with a CR returns

V1011

An S5 sets 250kbps

An O opens the port.

t12327788 with a CR again of course sends SID=123, DLC=2, Data 0x77 0x88

With nothing connected to the CANUSB the red LED goes on. (or if bitrate is wrong).

A C closes the port.

An F prints the error flags and shuts off the red led.

It’s a good idea to have auto line feed set in putty so that each received message is on a new line.

John Dammeyer

The CANUSB from Lawicel is a standard USB device that looks like a serial port since it can use the FTDI driver.

On my MachineKit Debian Beagle 2.0 when I plug in the CANUSB I find I have a /dev/ttyUSB0 device.

I installed putty and connected to /dev/ttyUSB0

In the terminal window

V with a CR returns

V1011

An S5 sets 250kbps

An O opens the port.

t12327788 with a CR again of course sends SID=123, DLC=2, Data 0x77 0x88

With nothing connected to the CANUSB the red LED goes on. (or if bitrate is wrong).

A C closes the port.

An F prints the error flags and shuts off the red led.

It’s a good idea to have auto line feed set in putty so that each received message is on a new line.

John Dammeyer

CAN1 and CAN2 are available when you aren’t using any other cape and I think eiher HDMI or perhaps it’s the LCD interface. It’s been a while. There is no relationship between /dev/ttyUSB0 and the CAN devices. One requires a CAN driver to function while the other is purely a serial port like a UART.

To get 5 CAN ports I chose the Freescale 9S12 series. I think ST Micro also makes an ARM compatible processor with 4 CAN ports. There aren’t a lot around.

If you want higher speed access along with message interrupts than what you can get with USB FTDI based CAN connections your alternative approach will be to add Microchip MCP2515s on board and use the SPI bus interface. With 3 select lines to a 3:8 mux you can select one of 4 CAN devices, and wire-OR the interrupts. You just have to poll which one caused the interrupt. I believe there is a driver for the MCP2515 already in the Beagle CAN library.

Alternatively, since you are already building a cape that has CAN drivers on it and you now you want at least 2 more CAN devices it may be easier to use a second processor that has two CAN ports. Write the firmware to look like an SPI based MCP2515 and you can use the stock Beagle CAN driver for it.

In fact, use either the ST Micro ARM and make all the CAN ports on it appear as if they were MCP2515s and that then frees up your other pins on the Beagle.

John

CAN1 and CAN2 are available when you aren’t using any other cape and I think eiher HDMI or perhaps it’s the LCD interface. It’s been a while. There is no relationship between /dev/ttyUSB0 and the CAN devices. One requires a CAN driver to function while the other is purely a serial port like a UART.

To get 5 CAN ports I chose the Freescale 9S12 series. I think ST Micro also makes an ARM compatible processor with 4 CAN ports. There aren’t a lot around.

If you want higher speed access along with message interrupts than what you can get with USB FTDI based CAN connections your alternative approach will be to add Microchip MCP2515s on board and use the SPI bus interface. With 3 select lines to a 3:8 mux you can select one of 4 CAN devices, and wire-OR the interrupts. You just have to poll which one caused the interrupt. I believe there is a driver for the MCP2515 already in the Beagle CAN library.

Alternatively, since you are already building a cape that has CAN drivers on it and you now you want at least 2 more CAN devices it may be easier to use a second processor that has two CAN ports. Write the firmware to look like an SPI based MCP2515 and you can use the stock Beagle CAN driver for it.

In fact, use either the ST Micro ARM and make all the CAN ports on it appear as if they were MCP2515s and that then frees up your other pins on the Beagle.

John

I have no idea what this dongle would cost but they claim linux compatibility.

https://can-newsletter.org/hardware/host-interfaces/171102_with-up-to-four-can-fd-channels_intrepid/=cwt17-44&utm_medium=cwt-mail&utm_campaign=weekly-telegraph-17-44

As for your question about both CAN working. It all depends on what other I/O is enabled.

Perhaps this link will help.

http://www.embedded-things.com/bbb/enable-canbus-on-the-beaglebone-black/

John