> Hi Folks, > > Some time ago I have asked for help for mcp251xfd driver with an IMX7D, so I > am somehow familar with the system. > The next iteration is with a NXP LX 2160A ... new hardware platform ... new > kernel (6.1.1) ... new problems ;) > > What is working : Driver is successfully initialised. > ❯ sudo modprobe mcp251xfd > [ 4493.557075] mcp251xfd spi1.2 can2: MCP2518FD rev0.0 (-RX_INT -PLL - > MAB_NO_WARN +CRC_REG +CRC_RX +CRC_TX +ECC -HD o:40.00MHz > c:40.00MHz m:8.00MHz rs:8.00MHz es:0.00MHz rf:8.00MHz ef:0.00MHz) > successfully initialized. > > If I use a "wrong" interrupt for testing purposes (interrupt wont get it to the > driver code), I am able to send one CAN Message from SPI CAN to LX2160A > internal CAN (cangen/candump). Then the driver stuck. > This is more or less expected. Agree > Enable the interrupt on the right pin (IRQ_LEVEL_LOW) does make some > trouble. Driver is successfully initialised. If I bring up the interface (ip link set > canx type can bitrate 500000 ; ip link set canx up) > I will get contineous errors: > > . > . > . > [ 508.352616] mcp251xfd spi1.2 can2: CRC write error detected. > CRC=0x6844. > [ 508.362081] mcp251xfd spi1.2 can2: CRC write command format error. > [ 508.368956] mcp251xfd spi1.2 can2: CRC write command format error. > [ 508.375242] mcp251xfd spi1.2 can2: CRC write command format error. > [ 508.381531] mcp251xfd spi1.2 can2: CRC write command format error. > [ 508.387822] mcp251xfd spi1.2 can2: CRC write command format error. > [ 508.394117] mcp251xfd spi1.2 can2: CRC write command format error. > [ 508.400402] mcp251xfd spi1.2 can2: CRC write command format error. > [ 508.406700] mcp251xfd spi1.2 can2: CRC write error detected. > CRC=0x537f. > . I can't remember encountering these format errors before. Do you have access to a logic analyzer and can you spi during capture insmod + interface up? Do you have anything else on the same SPI? Where's the 8 MHz coming from? Did you limit this in your DT? You could try with -CRC_REG -CRC_RX -CRC_TX to see if you're able to communicate with the device (this is not suited for anything in production though) > Since driver successfully initializes, no CRC read errors and sending a frame is > working I assume SPI itself is okay. > /proc/interrupt shows only one additonal interrupt during a down / up cycle. > This indicates that the interrupt is never cleared via SPI. > Since the error is a command error assuming the command is the one clearing > the interrupt, that makes sense. > What can be the reason for the command format error ? Any ideas how to > investigate further ? > > BR > Niels > > Thomas
