Thanks for the tips Patrick on config.txt cleanup, I'll take a closer look into that. Not sure I'm following what you're asking for with regards to i2c. i2c1 is currently is use to communicate with accel, gyro, mag, and a power supervisor MCU that helps us accomplish wake/sleep based on accel or vehicle ignition and some other low-level hardware tasks. I removed the UDEV rules I had that rename can0 and can1, just in case that was causing a race condition or something else odd, but the system is behaving the same. Not sure what else to try at this point, any ideas? What does the error number of -110 mean to you all? -----Original Message----- From: Patrick Menschel <menschel.p@xxxxxxxxx> Sent: Wednesday, June 23, 2021 4:07 PM To: Joshua Quesenberry <engnfrc@xxxxxxxxx>; 'Marc Kleine-Budde' <mkl@xxxxxxxxxxxxxx> Cc: kernel@xxxxxxxxxxxxxx; linux-can@xxxxxxxxxxxxxxx Subject: Re: MCP2518FD Drivers Rarely Working with Custom Kernel 5.10.Y Am 23.06.21 um 19:34 schrieb Joshua Quesenberry: > Hey! > > I have attached config.txt so you all can see what I'm doing. > > I added printing the error number as Marc suggested and the number appears to be -110 every time. > > [ 25.660006] CAN device driver interface > [ 25.668720] spi_master spi0: will run message pump with realtime priority > [ 25.676697] mcp251xfd spi0.1 can0: MCP2518FD rev0.0 (-RX_INT -MAB_NO_WARN +CRC_REG +CRC_RX +CRC_TX +ECC -HD c:40.00MHz m:20.00MHz r:17.00MHz e:16.66MHz) successfully initialized. > [ 25.684900] mcp251xfd spi0.0 can1: MCP2518FD rev0.0 (-RX_INT -MAB_NO_WARN +CRC_REG +CRC_RX +CRC_TX +ECC -HD c:40.00MHz m:20.00MHz r:17.00MHz e:16.66MHz) successfully initialized. > [ 28.098033] mcp251xfd spi0.1 rename4: renamed from can0 > [ 28.175644] mcp251xfd spi0.0 can0: renamed from can1 > [ 28.225891] mcp251xfd spi0.1 can1: renamed from rename4 > [ 146.964971] mcp251xfd spi0.0: SPI transfer timed out [ 146.965023] > spi_master spi0: failed to transfer one message from queue (ret=-110) > [ 146.965216] mcp251xfd spi0.0 can0: CRC read error at address 0x0e0c (length=4, data=00 00 00 00, CRC=0x0000) retrying. > [ 146.965247] mcp251xfd spi0.0 can0: CRC read error at address 0x0e0c (length=4, data=00 00 00 00, CRC=0x0000) retrying. > [ 146.965277] mcp251xfd spi0.0 can0: CRC read error at address 0x0e0c (length=4, data=00 00 00 00, CRC=0x0000) retrying. > [ 146.965286] mcp251xfd spi0.0 can0: CRC read error at address 0x0e0c (length=4, data=00 00 00 00, CRC=0x0000). > [ 146.965331] mcp251xfd spi0.0 can0: CRC read error at address 0x0000 (length=4, data=00 00 00 00, CRC=0x0000) retrying. > [ 146.965360] mcp251xfd spi0.0 can0: CRC read error at address 0x0000 (length=4, data=00 00 00 00, CRC=0x0000) retrying. > [ 146.965389] mcp251xfd spi0.0 can0: CRC read error at address 0x0000 (length=4, data=00 00 00 00, CRC=0x0000) retrying. > [ 146.965397] mcp251xfd spi0.0 can0: CRC read error at address 0x0000 (length=4, data=00 00 00 00, CRC=0x0000). > [ 146.965413] A link change request failed with some changes committed already. Interface can0 may have been left with an inconsistent configuration, please check. > > Regarding the discussion about Kconfig flags, I went ahead and rebuilt kernel 5.10.44 using a config that was essentially arch/arm/configs/bcm2711_defconfig with these additions needed to get our I2S working. This should have undone the switch to ONDEMAND governor and enabling 1000 Hz clock. > > 1030a1031 >> CONFIG_SND_RPI_I2S_AUDIO_WM8782=m > 1040a1042 >> CONFIG_SND_SOC_WM8782=m > > My RPi and HAT have worked very reliably with the older buster image and customized (same tweaks as mentioned in last email) kernel 4.19.73, in that kernel I'm using MCP25XXFD driver from msperl which under 5.10.Y kernel is having issues too. I only upgraded everything on my system at the end of last week, so hardware has been OK very recently. > > Keep in mind I'm not seeing a total failure, I do occasionally see everything work correctly and I can run the ip link setup command without issue, it's just not common and it seems fully removing power from the system and reapplying seems to help, but not every time, so maybe it's a coincidence. It could be an issue of subsequent configurations of the controller after the initial setup on power application, but I'd expect it work after every power yank I think. > > I wouldn't feel comfortable reverting my /boot/config.txt to a stock one and a default setup of the 40-pin header, at least not with my HAT attached which includes the CAN controllers AND circuitry to supply power to RPi from a 12V rail. OK, one general advice. Check if you can merge your HAT into a complete overlay with ovmerge tool like I did in https://github.com/raspberrypi/linux/issues/4032 https://github.com/raspberrypi/linux/pull/4034 This should clean up your config.txt quite a bit. I compare against the seeed can fd hat v2 which also has i2c1 and both can on spi0. I'm not sure about the PI4 but these 3 items usually all go on i2c1 which may be problematic. # typical combination out of raspi-config dtparam=i2c_arm=on dtparam=i2s=on # some manual entry, check if it can be removed dtoverlay=i2c1 The CAN related stuff looks ok, but you can omit the oscillator=40000000,speed=20000000 Those are the standard values afaik. # CAN 0/1 dtoverlay=spi0-cs dtparam=cs0_pin=8 dtparam=cs1_pin=7 # CAN 0 dtoverlay=mcp251xfd,spi0-0,interrupt=24 # CAN 1 dtoverlay=mcp251xfd,spi0-1,interrupt=25 Concerning the naming, I also used generic names can0, can1 at first but was advised to use best practice and to rename to mcp0, mcp1 instead. I believe Marc mentioned that this causes some kind of problem. This is my udev rule content. SUBSYSTEM=="net", ACTION=="add", DEVPATH=="/devices/platform/soc/*/*/*/spi0.0/net/can?", NAME="mcp0" SUBSYSTEM=="net", ACTION=="add", DEVPATH=="/devices/platform/soc/*/*/*/spi0.1/net/can?", NAME="mcp1" Regards, Patrick
