CAN bus problems with new kernel

General Discussion
1

I’ve got a Beagle with a prototype card and the CAN bus driver installed on it. Connected to the CAN bus is also a Lawicel CANUSB on a PC. I can send messages from a terminal program and the low level CAN device on the Beagle is providing the ACK as the CANUSB does not fault. But I don’t get messages.

The system was updated, upgraded (Buster 10.12) and a new kernel was installed.

debian@beaglebone:~/lazarus/lazcandump$ uname -a
Linux beaglebone 5.10.106-bone62 #1buster SMP PREEMPT Wed Mar 23 00:33:25 UTC 2022 armv7l GNU/Linux
debian@beaglebone:~/lazarus/lazcandump$ cat /etc/*release
PRETTY_NAME="Debian GNU/Linux 10 (buster)"
NAME="Debian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

The CAN device was enabled with this:

debian@beaglebone:~/lazarus/lazcandumpsudo ip link set can1 up type can bitrate 250000

and using the socketcan candump program

debian@beaglebone:~/lazarus/lazcandump$ candump can1

It sits and does not show any received messages even though the messages are acknowledged.
Now. Shutdown the Beagle, remove the MicroSD card and replace it with this version SD card.

debian@ebb:~$ uname -a
Linux ebb 4.19.94-ti-r68 #1buster SMP PREEMPT Thu Sep 16 15:32:31 UTC 2021 armv7l GNU/Linux
debian@ebb:~$ cat /etc/*release
PRETTY_NAME="Debian GNU/Linux 10 (buster)"
NAME="Debian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"
debian@ebb:~$ cat /etc/dogtag
BeagleBoard.org Debian Image 2018-10-07
debian@ebb:~$ sudo ip link set can1 up type can bitrate 250000
[sudo] password for debian:
debian@ebb:~$ candump can1
  can1  123   [4]  FE ED C0 DE

Notice this time the candump program works. the ifconfig shows the device is there.

debian@ebb:~$ ifconfig
can1: flags=193<UP,RUNNING,NOARP>  mtu 16
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 10  (UNSPEC)
        RX packets 10  bytes 20 (20.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 43

One other odd thing that I doubt is related is that this working system does this when I ask it to shutdown. Very annoying. The other one shuts down immediately.

debian@ebb:~$ sudo shutdown -h now
debian@ebb:~$ [  OK  ] Started Show Plymouth Power Off Screen.
[**    ] A stop job is running for Session 1 of user debian (20s / 1min 27s)

For the non-working system the results are similar for ifconfig other than it also doesn’t show any received packets and the device interrupt is 48 instead of 43 which may be the clue?

debian@beaglebone:~$ sudo ip link set can1 up type can bitrate 250000
debian@beaglebone:~$ candump can1
^Cdebian@beaglebone:~$ ifconfig
can1: flags=193<UP,RUNNING,NOARP>  mtu 16
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 10  (  UNSPEC)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 48

So the hardware is the same. the 5.10 version of the kernal and debian also does this for quite some time:

debian@beaglebone:~$ [  102.084983] wkup_m3_ipc 44e11324.wkup_m3_ipc: could not   get rproc handle
[  102.123986] PM: Cannot get wkup_m3_ipc handle

Be nice to also not see this.

2

Solved. I thought the image that I upgraded was an identical copy of the older one. But that was last May and clearly I’d done someone to the older 4.19 version and hadn’t on the other one. Now the CAN bus works when I send a “t1234feedc0de” to the Lawicel CANUSB.

debian@beaglebone:~$ sudo ip link set can1 up type can bitrate 250000
[sudo] password for debian:
debian@beaglebone:~$ candump can1
  can1  123   [4]  FE ED C0 DE

Turns out the uEnv.txt file in the 5.10.10-bone62 did not have the CAN1 line.

###Additional custom capes
uboot_overlay_addr4=/lib/firmware/BB-SPIDEV0-00A0.dtbo
uboot_overlay_addr5=/lib/firmware/BB-CAN1-00A0.dtbo
#uboot_overlay_addr6=<file6>.dtbo
#uboot_overlay_addr7=<file7>.dtbo

I thought I’d actually modified the EEROM on the prototype board to include the CAN1 now that it has a permanent CAN driver installed on it. Guess I’d better update that BB-W1-P8.11 to include CAN1.

uboot_overlays: [uboot_detected_capes=BB-W1-P8.11,] ...
loading /boot/initrd.img-5.10.106-bone62 ...

Sorry for the noise.
John

1 Like