BBB- DCAN1 problems using latest debian image

[mpwi...@gmail.com]

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

[RFA]

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

[Mark Irwin]

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

[RFA]

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
On Wednesday, April 8, 2015 at 2:20:29 PM UTC+1, Mark Irwin wrote:

[Mark Lazarewicz]

what a night mare to get something simple to work. ditch Linux use barebones Sent from Yahoo Mail on Android From:"Mark Irwin" <mpwi...@gmail.com> Date:Wed, Apr 8, 2015 at 9:21 PM Subject:[beagleboard] Re: BBB- DCAN1 problems using latest debian image

download Robert Nelson's dtb-rebuilder (https://github.com/ RobertCNelson/dtb-rebuilder) and checkout 3.14-ti.

-- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.

[Mark Irwin]

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.

To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe@googlegroups.com.

[Mark Irwin]

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 https://groups.google.com/forum/#!category-topic/beagleboard/can/1T_m9uXJ8Kc 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?

[William Hermans]

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 more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.

To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.

[William Hermans]

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.

[Mark Irwin]

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 https://github.com/RobertCNelson/dtb-rebuilder.git

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 https://github.com/linux-can/can-utils.git

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

[William Hermans]

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

[John Dammeyer]

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? 

[William Hermans]

@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

--

[John Dammeyer]

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

[Tracy Smith]

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

[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

 

 

 

From: beagl...@googlegroups.com [mailto:beagl...@googlegroups.com] On Behalf Of Tracy Smith
Sent: October-31-17 3:42 PM
To: BeagleBoard
Subject: [beagleboard] Re: BBB- DCAN1 problems using latest debian image

 

Hi John,

--

For more options, visit http://beagleboard.org/discuss
---

You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/_9u1B6ZkgCU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/e6297438-0999-4320-916e-f41d74671533%40googlegroups.com.

[Tracy Smith]

Hi John, 

Do you see support for both CAN0 and CAN1?  Need both and our pins for CAN1 are E17 and E18 in the TI pinmux tool.  Found the pad names and pins in uboot pinmux for CAN0 after this post.  Haven’t found pad names associated with E17/E18 yet in uboot pinmux. Will look at the kernel dts today.  

My question I guess will CAN1 be available when plugging in the CANUSB and where do you see CAN1 indicated?  If supported, it will appear as /dev/ttyUSB1?  Or, as a different device on the BBB?  Eventually may need as many as four CAN0-3.

Thx, Tracy

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/003001d352ac%24d3f24980%247bd6dc80%24%40autoartisans.com.

[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

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/48C2AA15-9F29-44DD-BE79-5122B54449C2%40gmail.com.

[Tracy Smith]

Hi John,

Both CANS are working on BBB even though Robert Nelson is implementing these on the P9 expansion header?

So what indicates the second CAN is working fine on BBB?  What do I look for to see the second CAN is working properly?

If this is the case, I just need to validate both are working and save myself time. We only saw the first CAN working.

Thx, Tracy

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/009501d35326%24bfafaba0%243f0f02e0%24%40autoartisans.com.

[John Dammeyer]

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/

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/E6DEF846-36DD-44B0-A7A3-F844799CFC4C%40gmail.com.