> Some additional erors captures. Thanks! > On more event of truncated CAN frame. This time 8 data bytes (instead of 64 > are > received). So much to my 20 bytes observation ... Took some time but I think I understood what's going on. The issue here is that due to the bug that Marc wrote the workaround for, we read a false HEAD from FIFOSTA and read multiple RX message objects including one that's currently in the process of being updated with the CAN-Frame that is just in the process of finishing on the bus. At this point the Timestamp is already updated but the DLC is not, so you're re-reading the old DLC from the previous iteration of the Ring but the new timestamp so the workaround doesn't fire as it's a positive relative timestamp. At this time I don't know if this is constrained to the DLC or if data bytes could also be affected. I will have this checked in simulation. Now, the only workaround I can currently think of, is completely disabling fetching more than one RX Message Object at a time and forcing re-reading the FIFOSTA after every iteration. This will be a performance hit so it's not a nice solution but that *should* get rid of this error in your case. I suppose it could be faster reading diag1 and using the error free messages to determine how much to read. This also means an additional SPI transfer/SPI message but I suppose reading C1INT and DIAG1 in 1 Message using two transfers would be faster (at least on a SPI driver comparable to the PI). > And then two cases of "Transmit Event FIFO buffer full" along with the > requested > coredump. Will work on this next but didn't have a chance yet. Thomas