TCAN4550: TCAN4550 Maximum Frame Rate Inquiry and Test Results

Hello Joe,

All communication with the TCAN4550 happens through the SPI bus, therefore it will become the overall limiting factor when determining the maximum CAN bus throughput that can be supported.  Several factors will need to be considered:

• The overall time required to process (transmit or receive) a CAN message from the TCAN4550's MRAM buffer space and read/write any required registers to initiate transmit of a message or acknowledge a message has been received, etc.  The SPI speed, amount of idle time between SPI transactions, etc. will need to be determined for each application and are processor/firmware specific.
• The amount of data that needs to be transferred for each CAN message through the SPI bus
• The bit rate of the CAN messages which determines the amount of time per bit (bit period)
• The RX and TX FIFO, Queue, and buffer configuration and how many messages can be held in memory before message data will be lost.
• The message priority status on the CAN bus, especially with high bus loads that may cause a delay in message transmission due to the CAN bus arbitration protocol.
• etc.
• The idle time between SPI read/write transactions due to the MCU firmware doing other things.  (SPI bus efficiency)
• The idle time within the SPI packet such as the time between CS falling low and the clock/data starting, any idle time between data bytes or words within the data bits, and time between the end of the clock/data and the CS signal pulling high again.  The device uses 32-bit data words, but may SPI drivers only support 8 or 16 bits at a time resulting in small time delays in the overall data packet.

Generally the SPI communication takes longer than the actual CAN message transmission, so a 100% CAN bus load is unlikely to be supported.  However, if the 100% load is only for a short period of time, then having a large enough RX FIFO can allow for the messages to be stored into Memory.  As long as the overall number of CAN messages is less than the required time to process those messages through SPI, there won't be an issue.  

But if CAN messages are arriving faster than the MCU can process them through SPI, then this will lead to an overflow situation and CAN message data will be lost.  Similarly, there can be limitations on the transmit path due to the time needed to load messages into the MRAM buffers and initiate the transmit through SPI writes.

Transmitting and Receiving CAN messages simultaneously also results in a time-sharing of the SPI bus between the RX and TX buffers.  

The processor controls the SPI communication, so the results may vary and it is best to measure the time needed to complete a full cycle of transmitting and receiving a CAN message by monitoring the SPI communication using a logic analyzer or other methods to determine the time needed to detect a new message has arrived (interrupt or register read) read the RX FIFO Status register to determine the buffer location, calculate or look up the MRAM address, read the data, and then acknowledge the buffer has been read to clear it for use again with a new message.  Likewise the time needed to write messages into the TX Buffer, set the TXBAR bit for that message, etc.

Regards,

Jonathan

Hi Jonathan,

Thank you for the detailed explanation regarding the TCAN4550 and the factors affecting CAN bus throughput. Your insights have given me a much better understanding of the rate limitations and how SPI communication plays a critical role in overall performance.

I also have an observation from my side that I would like to share with you. While testing the TCAN4550 on different kernel versions, I encountered an issue: on the Linux 5.10 kernel, I experienced errors similar to those mentioned in your explanation. However, when I switched to the 6.1 kernel, the errors disappeared, and the frame rate performance improved significantly.

This leads me to wonder whether the issue might be related to the software driver level. From what I understand, the 6.1 kernel includes support for burst read/write operations in the CAN subsystem. Does this mean that for high frame rate applications, using a kernel version 6.1 or above is necessary to achieve optimal performance?

I would appreciate your thoughts on this matter.

Best regards,
Joe

Hi Joe,

There have been two versions of the driver and you are testing with the initial version when using kernel 5.10, and the revised version with kernel 6.1.  

My expertise is with the TCAN4550 and not with Linux or which kernel version was the first to contain the revised driver, but I would suggest the newer version for optimal performance.

The TCAN4550 SPI protocol supports multiple data words in a single SPI read/write transaction.  The header word contains a Length field that instructs the device how many 32-bit data words should be expected in this transaction and if it is greater than 1, then the address is the starting address and the device will return or write all data to the memory or registers starting with the address given in the header.

The initial SPI driver only used single-word SPI read/write transactions which is functional and ok for single register read/writes, but not efficient when passing large amounts of RX/TX message data into and out of the MRAM buffers.  Each word of message data required a new address header word and a toggle of the chip select line which added additional time to the overall process.

The driver was revised to optimize the SPI throughput as much as possible and reduce the overall time needed to send and receive a CAN message.  This involved changing the SPI driver to use the multi-word read/write support when possible and to remove any other process inefficiencies that existed in the driver.  This revised driver was then upstreamed into the kernel and is likely the version you are seeing in the 6.1 which is why you have seen your performance improve.

You can find more information about this device and the MCAN configuration and operation in the following documents.

TCAN45xx Software User's Guide (Link)

MCAN User's Manual (Link)

Regards,

Jonathan