CANBus on BeagleBone Black Rev C Debian Linux not working

I am running a BeagleBone Black Rev C running Debian Linux kernel 4.19.x. beagle-version output at the end of the post.
I am starting to work on a CANbus implementation by breadboarding the CAN transceiver and trying to do a loopback test but the pins from the BeagleBone show a flat ~2.5V on the scope when I do a cansend.

Here’s the setup:
Using P9_24 - TXD
Using P9_26 - TXD
Using the MCP2562 for the transceiver.
120Ohm resistor between CANH and CANL on the MCP2562.
VI0 on the MCP2562 is 3.3V from the BeagleBone P9_3
VDD on the MCP2562 is 5V from the BealgeBone P9_7
STBY on the MCP2562 is tied to ground.

The Beagle is powered with the barrel connector and is connected to a Windows PC via the USB.

I have triple-checked the wiring and believe it to be correct.

My terminals for the loopback tests are on the same Windows PC. I use puTTY for one and Cloud9 for the other.

I execute this on “Terminal 1” to test

sudo ip link set can1 down
sudo ip link set can1 up type can bitrate 250000
candump can1
cansend can1 123#DEADBEEF

And this on the "Terminal 2’

candump can1

Nothing happens on the second terminal.
When I execute

sudo ip link set can1 down

on Terminal 1, Terminal 2 responds that the CAN network is down.

I have changed the transceiver chip in case one is damaged. I get the same behavior.
I have the latest can-utils for this distribution.

Output of beagle-version:

root@beaglebone:/boot# beagle-version
eeprom:[A335BNLT00C02411SBB02285]
model:[TI_AM335x_BeagleBone_Black]
dogtag:[BeagleBoard.org Debian Buster IoT Image 2021-02-15]
bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot SPL 2019.04-00002-gc9b3922522 (Aug 24 2020 - 16:42:18 -0500)]:[on: dd MBR]
bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 2019.04-00002-gc9b3922522]:[location: dd MBR]
UBOOT: Booted Device-Tree:[am335x-boneblack-uboot-univ.dts]
UBOOT: Loaded Overlay:[AM335X-PRU-RPROC-4-19-TI-00A0.kernel]
UBOOT: Loaded Overlay:[BB-ADC-00A0.kernel]
UBOOT: Loaded Overlay:[BB-BONE-eMMC1-01-00A0.kernel]
UBOOT: Loaded Overlay:[BB-CAN1-00A0]
kernel:[4.19.94-ti-r68]
nodejs:[v10.23.1]
/boot/uEnv.txt Settings:
uboot_overlay_options:[enable_uboot_overlays=1]
uboot_overlay_options:[uboot_overlay_addr6=/lib/firmware/BB-CAN1-00A0.dtbo]
uboot_overlay_options:[disable_uboot_overlay_video=1]
uboot_overlay_options:[disable_uboot_overlay_audio=1]
uboot_overlay_options:[uboot_overlay_pru=AM335X-PRU-RPROC-4-19-TI-00A0.dtbo]
uboot_overlay_options:[enable_uboot_cape_universal=1]
pkg check: to individually upgrade run: [sudo apt install --only-upgrade <pkg>]
pkg:[bb-cape-overlays]:[4.14.20210809.0-0~buster+20210816]
pkg:[bb-customizations]:[1.20210810.1-0~buster+20210810]
pkg:[bb-usb-gadgets]:[1.20200504.0-0~buster+20200504]
pkg:[bb-wl18xx-firmware]:[1.20200813.1-0~buster+20200813]
pkg:[kmod]:[26-1]
pkg:[librobotcontrol]:[1.0.5-git20200715.0-0~buster+20200716]
pkg:[firmware-ti-connectivity]:[20190717-2rcnee1~buster+20200305]
groups:[debian : debian adm kmem dialout cdrom floppy audio dip video plugdev users systemd-journal input bluetootev i2c gpio admin spi iio docker tisdk weston-launch xenomai cloud9ide pwm eqep remoteproc]
cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 root=/dev/mmcblk1p1 ro rootfstype=ext4 rootwaerent_pool=1M net.ifnames=0 lpj=1990656 rng_core.default_quality=100 quiet]
dmesg | grep remote
[   71.203338] remoteproc remoteproc0: wkup_m3 is available
[   71.230295] remoteproc remoteproc0: powering up wkup_m3
[   71.230331] remoteproc remoteproc0: Booting fw image am335x-pm-firmware.elf, size 217148
[   71.230619] remoteproc remoteproc0: remote processor wkup_m3 is now up
[   72.849994] remoteproc remoteproc1: 4a334000.pru is available
[   72.856458] remoteproc remoteproc2: 4a338000.pru is available
dmesg | grep pru
[   72.849994] remoteproc remoteproc1: 4a334000.pru is available
[   72.850185] pru-rproc 4a334000.pru: PRU rproc node pru@4a334000 probed successfully
[   72.856458] remoteproc remoteproc2: 4a338000.pru is available
[   72.856597] pru-rproc 4a338000.pru: PRU rproc node pru@4a338000 probed successfully
dmesg | grep pinctrl-single
[    1.027103] pinctrl-single 44e10800.pinmux: 142 pins, size 568
dmesg | grep gpio-of-helper
[    1.040697] gpio-of-helper ocp:cape-universal: ready
lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
END


output of ip link and additional commands to set up can1

root@beaglebone:/boot# ip link set can1 down
root@beaglebone:/boot# ip link set can1 up type can bitrate 250000
root@beaglebone:/boot# ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: can0: <NOARP,ECHO> mtu 16 qdisc noop state DOWN mode DEFAULT group default qlen 10
    link/can
3: can1: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UP mode DEFAULT group default qlen 10
    link/can
4: eth0: <NO-CARRIER,BROADCAST,MULTICAST,DYNAMIC,UP> mtu 1500 qdisc mq state DOWN mode DEFAULT group default qlen 1000
    link/ether 98:89:24:76:1a:28 brd ff:ff:ff:ff:ff:ff
5: usb0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
    link/ether 98:89:24:76:1a:2a brd ff:ff:ff:ff:ff:ff
6: usb1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000
    link/ether 98:89:24:76:1a:2e brd ff:ff:ff:ff:ff:ff
root@beaglebone:/boot#


I verify our images with this design: capes/beaglebone/Comms/Comms_Cape_sch.pdf at master · beagleboard/capes · GitHub

Two boards, tied together…

debian@40-am335x-bbb:~$ sudo ip link set can0 type can bitrate 500000
debian@40-am335x-bbb:~$ sudo ifconfig can0 up
debian@40-am335x-bbb:~$ candump can0
debian@39-am335x-bbb:~$ sudo ip link set can0 type can bitrate 500000
debian@39-am335x-bbb:~$ sudo ifconfig can0 up
debian@39-am335x-bbb:~$ cansend can0 123#DEADBEEF
  can0  123   [4]  DE AD BE EF

Regards,

@RobertCNelson Before I go so far to bring another board and transceiver into the mix, let me ask a couple more questions. First, I noticed your schematic is using P9_24 and P9_26 for CAN. You are using can0 in your commands. Are P9_24 and P9_26 can0? I’m loading the overlay and using can1… Since neither P9_24 or P9_26 show any activity on the scope with the cansend yet the overlay appears to be loaded, I am thinking I should be loading and using can0 for these pins. Is this my problem? Could it really be that simple?

@RobertCNelson I switched to CAN0 and P9_19 and P9_20 and have communications between a Black and a Black Wireless!!! But I really need to use P9_19 and P9_20 for something else so any ideas on why P9_24 and P9_26 aren’t working with CAN1?