CAN Not Working (P9_24, P9_26, P9_19, P9_20 - Beaglebone Black Enhaced)

Kernel version: 4.19.31-ti-r19
OS: Ubuntu 18.04.2 LTS
BB Board: Beaglebone Black Enhanced (Sancloud)

Hello,

I am trying to use P9_24 and P9_26 for CAN (controller area network). The following are the steps I am taking to enable the pins and attempt to send messages over CAN:

config-pin P9_24 can
config-pin P9_26 can
sudo ip link set can0 up type can bitrate 500000
sudo ifconfig can0 up
cangen can0 -i -g 100 -v

cangen shows that it is generating messages, but when I view the voltage levels of P9_24 and P9_26 under and oscilloscope, there is no change in voltage. The voltage remains at 3.1V-3.2V.

When I query the pins, the configuration is correct:

config-pin -q P9_24

P9_24 Mode: can
config-pin -q P9_26

P9_26 Mode: can

If I change the pin configuration to “gpio” for example, I can see a voltage change in the oscilloscope for both pins accordingly. I have tried to configure P9_19 and P9_20 for CAN as well and I have the same results.

Does anyone have any idea tips on how to get the BB to send CAN messages? Do I need to configure anything else before it works?

(I do have a CAN transceiver which will interface on the CAN bus, but I was not able to see messages from the BB on the CAN bus, which lead me to debug the voltage at the BB I/O pins first before debugging it over to the transceiver. It appears my issue is that the BB pins are not transmitting anything currently.)

Thanks for the help!

Kernel version: 4.19.31-ti-r19
OS: Ubuntu 18.04.2 LTS
BB Board: Beaglebone Black Enhanced (Sancloud)

Hello,

I am trying to use P9_24 and P9_26 for CAN (controller area network). The
following are the steps I am taking to enable the pins and attempt to send
messages over CAN:

config-pin P9_24 can
config-pin P9_26 can
sudo ip link set can0 up type can bitrate 500000
sudo ifconfig can0 up

I think you need can1 here, not can0.

*I* got things to work with my LCC CAN Cape board
(https://www.pcbway.com/project/shareproject/LCC_CAN_Cape_for_Beagle_Bone_Black.html).
I have its eeprom set to load /lib/firmware/BB-CAN1-00A0.dtbo at boot time, I
can then configure can1 and it works just fine. I think BB-CAN1-00A0.dtbo
does a little more than merely what config-pin does. I'd suggest editint
/boot/uEnv.txt to load the BB-CAN1-00A0 overlay and then configuring can1...

Certainly, BB-CAN01-00A0 enables dan1 peripheral, not can0. However, as I know, you should enable ¡®can0(not dcan1 or can1)¡¯ when you enable the can network stack via ifconfig.

Please refer this links. The ¡®how-to¡¯ in this link still works well:

https://electronics.stackexchange.com/questions/195416/beaglebone-black-can-bus-setup

Best regards

Heecheol Yang.

it actually depends on the kernel version, 3.8.13 vs 4.1.x+...

It wasn't till sometime later that an aliases was setup to make it constant...

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/am33xx.dtsi?h=v5.3-rc1#n33

Regards,

Thanks for the feedback guys. I went ahead and attacked this problem again tonight.

This one was really strange. The reason I was using config-pin instead of overlays was because config-pin seems to be the preferred method on beaglebone to configure the pins now on the newer kernel and OS. "/sys/devices/bone_capemgr" no longer exists on my OS. So the two options I have is to use config-pin (beaglebone-universal-io) or /boot/uEnv.txt

I tried enabling the overlay in /boot/uboot.txt by adding:
uboot_overlay_addr0=/lib/firmware/BB-CAN1-00A0.dtbo
uboot_overlay_addr0=/lib/firmware/BB-CAN0-00A0.dtbo

This resulted in the same behavior.

Then I tried to add the “DCAN” overlay:
uboot_overlay_addr0=/lib/firmware/BB-DCAN1-00A0.dtbo

This seems to have changed something and both CAN interfaces (can0 and can1) began to work! After I verified CAN was working with the manually added overlays in uEnv.txt, I went ahead and removed all the manually added CAN overlays (BB-CAN0-00A0.dtbo, BB-CAN1-00A0.dtbo, BB-DCAN1-00A0.dtbo) from /boot/uEnv.txt and left “enable_uboot_cape_universal=1” and attempted to configure the CAN pins via:

config-pin P9_19 can
config-pin P9_20 can

config-pin P9_24 can
config-pin P9_26 can
sudo ip link set can0 up type can bitrate 500000

sudo ip link set can1 up type can bitrate 500000

sudo ifconfig can0 up
sudo ifconfig can1 up

The result was the CAN on can0 and can1 continued to work (RX and TX on both interfaces). How bizarre! Anyone have a clue why adding the “BB-DCAN1-00A0.dtbo” to /boot/uEnv.txt caused the CAN interfaces to work on can0 and can1 all of a sudden?

Anyway, thanks again for the tips. I hope this helps someone in the future!

Interesting, can you please run:

sudo /opt/scripts/tools/version.sh

When it's working, so i can validate and fix.

Regards,

Hi Robert,

Thanks for looking at this. Below is the output of the version.sh script. I took this with can0 and can1 working. Please let me know if there is anything else I can help with.

git:/opt/scripts/:[1d3eb3a15fafc1463e0a86dcef15857aa2a827be]
eeprom:[A335BNLTSE0A2019BBE81671]
model:[SanCloud_BeagleBone_Enhanced]:WiFi AP Enabled:[https://github.com/lwfinger/rtl8723bu]
dogtag:[rcn-ee.net console Ubuntu Image 2019-04-10]
bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 2019.04-00002-gbb4af0f50f]:[location: dd MBR]
kernel:[4.19.31-ti-r19]
uboot_overlay_options:[enable_uboot_overlays=1]
uboot_overlay_options:[disable_uboot_overlay_video=1]
uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo]
uboot_overlay_options:[enable_uboot_cape_universal=1]
pkg check: to individually upgrade run: [sudo apt install --only-upgrade ]
pkg:[bb-cape-overlays]:[4.4.20190610.0-0rcnee0~bionic+20190610]
pkg:[bb-wl18xx-firmware]:[1.20190227.1-0rcnee0~bionic+20190227]
pkg:[kmod]:[24-1ubuntu3.2rcnee0~bionic+20190208]
WARNING:pkg:[librobotcontrol]:[NOT_INSTALLED]
cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 root=/dev/mmcblk1p1 ro rootfstype=ext4 rootwait coherent_pool=1M net.ifnames=0 quiet cape_universal=enable]
dmesg | grep remote
dmesg | grep pru
dmesg | grep pinctrl-single
dmesg | grep gpio-of-helper
lsusb
Bus 001 Device 003: ID 0bda:b720 Realtek Semiconductor Corp.
Bus 001 Device 002: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
END