TCAN4550-Q1: Kernel reporting "msg lost in rxf0" error

Hello Peter,

This error message indicates that the RX FIFO was full an there were no available elements to store the new incoming message and therefore the new message was discarded and lost.  Because you are communicating ok with a 10ms interval, but not a 1ms interval, this indicates your processor is not reading and acknowledging the messages within your 1ms window.  You will either need to reduce the message interval to what you can support, or reduce the overhead time from when the processor receives the interrupt of a new message to the final acknowledgement of that message which frees up the FIFO element for a new message.

The two RX FIFOs can be configured to store up to 64 elements (messages) each.  Based on the Message Filters, incoming messages are directed to one of these FIFOs, a dedicated RX Buffer element, or rejected. When a message is stored, an interrupt status bit is set to notify the MCU of the new message.  Once the MCU had read the message, it must acknowledge that it has read the message which will free up the element in the FIFO or Buffer for a new message.

If the MCU does not read and acknowledge the messages faster than they are arriving, then the FIFOs and Buffers will eventually fill up resulting in the loss of messages.  The SPI data rate, the length of the data payload in the message, reading the message data in a burst read (multiple words of data in a single SPI transaction to prevent additional overhead from repeated address headers), the efficiency of the processor to read and acknowledge the message after receiving the interrupt, etc.

I don't know how your FIFO's and message filter elements are configured, but some general suggestions for improvement from a TCAN4550 device level are:

• Use the maximum supported SPI data rate possible.
• Use burst reads and writes to send or receive multiple consecutive words of data to or from the MRAM without requiring additional address headers.  Note it is also possible to read multiple messages out of the MRAM space in a single SPI transaction if they are in consecutive memory locations.
• Configure either the GPIO1 or GPO2 pin as a dedicated interrupt and elevate the priority level to obtain faster response.
• Reduce as much overhead in the MCU as possible to reduce delays from the MCU performing other functions during this process
• Setup filters to filter out unwanted messages and to direct messages to different locations based on priority or type instead of placing every message in a single FIFO
• Reduce the RX Message Element data size to match the maximum data size of the message so that you are not transferring extra dummy data on the SPI bus.  For example, if the maximum message data field is 8 bytes, do not have the RX Message elements set for a 64 byte data field.
• Increase the depth of the FIFO so that it can hold more messages before becoming full.  However, this is not a long term solution if the messages are arriving faster than they are acknowledged.  But it does help accommodate bursts of messages.
• Reduce the frequency of the RX messages on the bus

I support the TCAN4550 from a device level and I'm not sure if you can follow all of these suggestions in the Linux driver you are using such as the SPI burst reads, or dedicated GPIO interrupt pins, etc.  But hopefully this gives you some suggestions on how to improve your results.

Regards,
Jonathan

Thanks Jonathan, we will try and get back to you soon.

Peter

Hi Peter,

Good luck.  Let me know if you have any additional questions.

Regards,

Jonathan