On 16.01.2023 08:43:29, Stefan Althöfer wrote: > Tested this on two raspberry CM4 with two MCP1518 controllers each. > CAN frames are sent (and received) by both sides "simultaneously". In > 67 h of testing an average of about 100 fifo errors occurred for each > CAN controller. No wrong messages we received by the application. > > Tested-by: Stefan Althöfer <Stefan.Althoefer@xxxxxxxxxxx> Added, thanks. > Just to make sure I'm correctly understanding the issues impact: The > driver reads one complete timed-back message (76 bytes) The driver reads the RX FIFO head index and has a cached tail index. It calculates the number of pending messages (which are too many in the bad case) and reads them from the chip. It reads n * 76 bytes. This might be some CAN frames too much. > and then re-syncs to the fifo to read the now hopefully correct > pointers: Hence there is a spurious extra latency of about < 100 us > (assuming *' 10 MHz SPI clock)? The latency introduced by the erratum is "76 bytes * number of old messages", if the controller is configured for CAN-FD, it's only 20 bytes in the CAN-2.0 mode. Note: I haven't invested much time in the optimization of CAN-FD, as it was not important for our customers. There are several options: - In CRC SPI transfer mode at max 252 bytes are read from the RAM, however the chip should support up to 1020 bytes in one transfer. - The driver always reads full 76 bytes in CAN-FD mode. Splitting the transfer in to 2 parts might be more performant for small CAN-FD frames. In the first transfer the driver would read the timestamp, ID and DLC and some amount of data, after decoding the DLC the remaining data can be read in a 2nd transfer. Contact me if you are interested. :) regards, Marc -- Pengutronix e.K. | Marc Kleine-Budde | Embedded Linux | https://www.pengutronix.de | Vertretung West/Dortmund | Phone: +49-231-2826-924 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
Attachment:
signature.asc
Description: PGP signature
