Hi Stefan, > I have reduced my test case to a simple single thread self-receipt test: > * TX two messages > * Wait for RX and send out a new message on every receipt > * TX for messages in total > > Refer to the attached PDF for some error cases. Last send frames are at the > top of the logs. You can see that wrong > messages appear in the RX queue, which have been successfully transmitted > in previous test loop. The data that is actually sent > out is correct however (checked with an external logger for some cases). Do I read the pdf correctly (based on the /var/log stuff) that you have two MCP2518FD connected to a Pi4B and both of them are running in internal/external loopback mode no interaction between them and the SPIs are separate? What are your CAN interface settings? Would it be possible to share the script? > I see infrequent mcp251xfd CRC read errors. I think those are due to the 2518 > SPI errata. However they don't > occur at the time when the wrong messages are received (refer to the PDF). Correct, this shouldn't be related to your problem. > - Any suggestion how I can step further in fixing this issue. One thing would be to dump the RAM i.e. the content of the fifos itself to see whether the device actually has the incorrect frames. Marc wrote a tool to dump registers and RAM via debugfs: https://github.com/linux-can/can-utils/blob/master/mcp251xfd/mcp251xfd-dump.c For this debugfs needs to be enabled and mounted (e.g. $mount -t debugfs none /sys/kernel/debug) Now the registers can be dumped like this: cat /sys/kernel/debug/regmap/spi0.0-crc/registers So I'd suggest to abort the script after the first error occurred and then dump registers/ram to find the RX fifo in question and check the content. Best Regards, Thomas
