Data Errors with Raspberry Pi + 2 CAN FD HAT

While I’m relatively new to Python, I’m trying to get some Python test code to run on a Raspberry Pi 3B and talk CAN to a device under test. I have a 2 CAN FD HAT for the communication. But, I’m seeing something strange.

I have the two ports tied together in order to continuously monitor can1 and the bus. I send my commands through can0 to the DUT. However, whenever can1 reports a message, the data length is OK, but the message repeats the 1st byte twice, and the last byte is dropped. Here is an example message:

cansend can0 123#12345678
can1 123 [4] 12 12 34 56

Has anyone experienced anything like this before. Any suggestions as to where I should start looking?

Thanks!

What happens to dmesg when something goes wrong?

Excellent question - thanks!

Indeed, when I send messages out can0, a message is logged by the SPI/CAN driver:

mcp25xxfd spi0.0 can0: Something is wrong - we got a TEF interrupt but we were not able to detect a finished fifo

I’m not sure how to proceed, though.

https://github.com/Seeed-Studio/pi-hats/issues/7 You can see the discussion in these issues. We are going to switch Marck’s Linux driver.
For now, There is a temporary way for test the software.

mkdir /opt/kernel
git clone --depth=1 --branch v4.19-rpi/mcp25xxfd-20200429-46 https://github.com/marckleinebudde/linux.git
cd linux
KERNEL=kernel7l
make bcm2711_defconfig
make -j4 zImage modules dtbs
sudo make modules_install
sudo cp arch/arm/boot/dts/.dtb /boot/
sudo cp arch/arm/boot/dts/overlays/.dtb* /boot/overlays/
sudo cp arch/arm/boot/dts/overlays/README /boot/overlays/
sudo cp arch/arm/boot/zImage /boot/$KERNEL.img

Everything went fine, until this command:

Any ideas?

Thanks for your help!

sudo apt install libssl-dev

OK, all the makes succeeded. The 1st and 2nd copy commands failed because there’s no .dtp directory in either arch/arm/boot or arch/arm/boot/overlays. The last 2 copy commands succeeded. Any suggestions?

Also, am I correct in assuming that copying things into the /boot directory will make our new kernel the default kernel that my Pi will boot with? If so, how easy will it be to switch back to the existing kernel?

Thanks again for all your help!

Sorry, I’ve noticed some mistakes here.The following is correct.

mkdir /opt/kernel
git clone --depth=1 --branch v4.19-rpi/mcp25xxfd-20200429-46 https://github.com/marckleinebudde/linux.git
cd linux
KERNEL=kernel7l
make bcm2711_defconfig
make -j4 zImage modules dtbs
sudo make modules_install
sudo cp arch/arm/boot/dts/.dtb* /boot/
sudo cp arch/arm/boot/dts/overlays/.dtbo* /boot/overlays/
sudo cp arch/arm/boot/dts/overlays/.dtb* /boot/overlays/
sudo cp arch/arm/boot/dts/overlays/README /boot/overlays/
sudo cp arch/arm/boot/zImage /boot/$KERNEL.img

OK, that seemed to do it. (Except that your wildcards should be written *.dtb and *.dtbo, respectively.)

Thanks for your time and assistance!

This isn’t exactly working out of the box, the second SPI interface, spi1.0 doesn’t come up, i’m thinking to disable CRC check in the driver,

I’m running the RPI 3B+, the build shows

>make bcm2711_defconfig in the instructions @Baozhu , but lsmods shows spi_bcm2835 as that any relevance?

more details below

pi@raspberrypi:~ $ dmesg | grep spi
[    6.618121] mcp25xxfd spi0.0: MCP2517 successfully initialized.
[    6.684243] mcp25xxfd spi1.0: CRC read error: computed: ec03 received: 0000 - data: be 00 04 00 00 00 00
[    6.684264] mcp25xxfd spi1.0: CRC read of clock register resulted in a bad CRC mismatch - hw not found
[    6.684285] mcp25xxfd spi1.0: Probe failed, err=84
[    6.684424] mcp25xxfd: probe of spi1.0 failed with error -84

pi@raspberrypi:~ $ lsmod | grep spi
spi_bcm2835aux         16384  0
spi_bcm2835            20480  0

pi@raspberrypi:~ $ uname -an
Linux raspberrypi 5.4.51-v7+ #1327 SMP Thu Jul 23 10:58:46 BST 2020 armv7l GNU/Linux

I read that on the original driver here


one can remove the CRC check and it should come up the second CAN channel over SPI

what do you think?

Some updates, second can1 interface doesn’t come up after building and installing the patched module, getting this error:
mcp25xxfd spi1.0 (unnamed net_device) (uninitialized): Failed to detect MCP2517FD (osc=0x00000000).

dump of relevant data

pi@raspberrypi:~ $ dmesg | grep spi
[ 6.200302] spi_master spi0: will run message pump with realtime priority
[ 6.222181] mcp25xxfd spi0.0 can0: MCP2517FD rev0.0 (-RX_INT +MAB_NO_WARN +CRC_REG +CRC_RX +CRC_TX +ECC -HD m:20.00MHz r:18.50MHz e:18.18MHz) successfully initialized.
[ 6.223641] spi_master spi1: will run message pump with realtime priority
[ 6.262628] mcp25xxfd spi1.0 (unnamed net_device) (uninitialized): Failed to detect MCP2517FD (osc=0x00000000).
pi@raspberrypi:~ $ sudo ifconfig can0
can0: flags=128 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 167

pi@raspberrypi:~ $ sudo ifconfig can1
can1: error fetching interface information: Device not found
pi@raspberrypi:~ $ uname -an
Linux raspberrypi 4.19.118-v7+ #2 SMP Mon Jul 27 19:26:18 BST 2020 armv7l GNU/Linux
pi@raspberrypi:~ $

We have just updated the software, please use the new system.I’m really sorry to have brought you so much trouble.

:joy: :joy: :joy: :joy: :joy: :joy:
why can not just post emoji…

When you boot your Raspberry Pi, the first thing you’ll see (unless you’re prepping an installation with NOOBS) is the GPU test screen. This is commonly known as the “rainbow screen” and is intended to appear for just a couple of seconds. After this, the operating system should load.

However, sometimes this doesn’t happen. Instead, the device will hang at the GPU test. If this occurs, you have a problem.

common raspberry pi issues and fixes
In most cases, this is due to a problem with the Raspbian kernel image on your microSD card. To test, install Raspbian onto another microSD card, and boot from this instead. If it works, then you know the problem is with the original microSD card.

However, it’s not ideal. Additionally, you may have data you need from the original microSD card. In order to retrieve this data, insert the microSD card into your computer’s card reader. Browse to the /home/ folder, then copy it to your PC’s hard disk drive.

Regards,
Rachel Gomez