I’m trying to integrate an MCP2515 device with the spi bus on a ras pi4, with dissapointing results:
The CAN bus interface is not appearing.
Firmware- updated to latest: v3.80~44
Package manager and VECan setup installed.
multiple reboots all result in the following appearing in dmesg:
[ 6.683603] mcp251x spi0.0: MCP251x didn't enter in conf mode after reset
[ 6.690741] mcp251x spi0.0: Probe failed, err=110
[ 6.695621] mcp251x: probe of spi0.0 failed with error -110
[ 6.756637] EXT4-fs (mmcblk0p2): re-mounted. Opts: (null)
root@raspberrypi4:
config.txt reads:
root@raspberrypi4:~# cat /u-boot/config.txt
enable_uart=1
kernel=u-boot.bin
[all]
device_tree=bcm2711-rpi-4-b.dtb
begin CAN overlay
Waveshare 1-channel CANbus Hat 16 MHz crystal
instantiates as can0 ONLY !!!
use udev rules to rename
[all]
dtparam=spi=on
dtoverlay=mcp2515-can0,oscillator=16000000,interrupt=25,spimaxfrequency=400000
end CAN overlay
root@raspberrypi4:~#
Note: spi max frequency has been reduced from the 2MHz to 400kHz .
Tedious inspection of the SPI bus to the MCP 2515 gives the following:
Reset instruction sent.
Read canstat instruction sent (multiple times)
mcp2515 replies #b1000000 which is the default / Reset value.
So it appears that the signals are nice and clean, the VE-CAN overlay is setting up the SPI correctly, the MCP2515 is receiving a reset followed by a read of the CANSTAT register, to which the 2515 is replying correctly the 0xf0 default setting (config mode), but the VE-Can overlay is not receiving or interpreting this correctly. I’m not sure where to go looking next, but something in the VE-CAN receive side is not setting up correctly.
VeCanSetup command line configuration can be confusing but it does look like you have done all the necessary steps since there are entries in config.txt (unless you added those manually !!).
You did not say which CANbus hat board you are using. There is no guarantee that a configuration for a specific hat board will work with another.
Check to make sure the hat CANbus interface you are using puts its interrupt on GPIO 25 as that’s what VeCanSetup configured with your “Waveshare 1-channel CANbus Hat 16 MHz crystal” selection.
Also make sure the crystal frequency is in fact 16 MHz. There are also 8 and 12 MHz configurations for the single channel Waveshare boards.
VeCanSetup will set up can8 for the first hat interface, not can0. This is done through udev rules and is not completely clear from the comment in config.txt
config.txt should have comment lines but your excerpt does not show the # characters.
There could be conflicts between the GPIO 25 used as an interrupt for this interface and other possible uses such as digital inputs or relay outputs.
Not using a “hat” board, but a board that I developed, just repurposed for testing this. One reason I slowed the SPI clock speed down.
Interrupt is on #25, but as the response to the CANSTAT probe shows, no interrupt is configured yet.
Yes clock is 16MHz - though this should not affect the setup, it would only affect the CAN data speed.
ok on can8.
config.tx lost its # characters whilst I was trying to get the format right for the post, they are there.
No other ‘mods’ have been made for digital inputs or relay outputs.
Also, yes the entries in config.txt were made automatically, I just edited the file later to slow the clock speed so as I could see what was going on. just have old analog scope and (somewhat) newer camera. For some reason the venus os is hanging in boot, so going to re-image the card and start from fresh. << Done that, no change.
You may need to create your own overlay to use on your board. I don’t really know what’s going on inside the overlay or how your board may differ from the Waveshare hats the configs I include in VeCanSetup came from.
From what I can make out, the waveshare hat has the mcp2515 connected directly to the spi pins, so does mine. The mcp is getting the reset and read canstat commands, and giving the correct response. So the Pi is not ‘receiving’ the response to the spi read command.
3 options here:
1)Check the spi performance with the pi os,
try the Venus os with a differnet set of hardware (got one spare, can swap the sd cards).
decode the .dtbo file and analyse. (done this before with BBB systems).
Waiting for new DSO/logic probe to turn up too. After nearly 30 yrs the Tek scope is starting to give problems - it was s/h when I got it.
