TCAN4550: If there a firmware transmitting and recieving CAN packet by SPI simultaneously?

Hi Phoebe,

What type of processor and firmware are you currently using?

Because there is only one SPI bus on the TCAN4550, full duplex access to simultaneously read and write registers or Memory RAM (MRAM) is not possible.  However, the device is capable of writing and reading multiple words of data to consecutive memory address cells in a single SPI transaction with the LENGTH field set to the number of words.  This allows a complete CAN message to be placed or retrieved from MRAM with a single SPI transaction that only has to transmit one SPI word that contains the start address for the buffer element used for the message.

For bare metal ANSI C code, we have the TCAN4550 Demo Software.

For Linux, a driver has been upstreamed into the Kernel which is generally a wrapper to the MCAN driver also in the Kernel.  This is not the most efficient driver and a newer version is currently in development that will improve efficiency and increase the CAN message throughput.  It is expected to be complete in a couple of months.

Regards,

Jonathan

Thank you for your reply. But I could'nt open the link of TCAN4550 Demo Software, maybe I don't have the access of it. And I'm trying the method of transmiting data in one SPI transaction, but I don't know when is the tx queue empty. I want to send several CAN packet when tx queue is empty. The TFE of MCAN Interrupts always is 0 even though the TCAN4550 is just startup.

How can I know when the tx queue is empty?

If there is no a interrupt notify me the tx queue is empty, I need to check the register frequently, which also make CPU load high. Looking forwad to your reply.

Hi Phoebe,

You can find the original link to the the demo software on the TCAN4550-Q1 product folder by scrolling down to the Design and Development section.  You may have to answer a few security questions first, so try downloading it from the link on that page.  Here is the link.  https://www.ti.com/product/TCAN4550-Q1

Regarding the transmission complete questions, I think there may be a bit of confusion we need to work through regarding how the messages are to be transmitted.

The device can be configured to to use dedicated TX Buffers where the MCU controls which TX Buffer element in MRAM to place the message and initiates a transmission through writing a '1' to the corresponding bit in the TXBAR register.

The device can be configured to use a TX FIFO where the messages are stored in a FIFO and transmitted in the order they were loaded into the FIFO.  After each transmission the Get Index of the FIFO is incremented cyclically until the FIFO is empty.  The MCU can check the Put Index to determine where to place the next message to load into the FIFO.  The device will also calculate the difference between the Get and Put index to determine the number of available (free) TX FIFO elements.

The device can be configured to use a TX Queue which transmit the messages starting with the lowest message ID (highest priority) per the CAN arbitration protocol first.  New messages have to be written to the TX Buffer referenced by the Put Index and an add request cyclically increments the put index to the next free TX Buffer until the TX Queue is full indicated by the TFQF bit.  However, the messages may not be transmitted in the sequence they were loaded into the TX Buffers, so the TX Buffer Request Pending (TXBRP) register can be read instead to determine which buffers contain messages that are pending transmission, and which buffers are available or free.  The MCU can then write new messages to the free buffers and make an add request to the TXBAR register for the new message to be added to the queue.

Or the device can be configured to use a mixture of dedicated TX Buffers and a TX FIFO.

My confusion is that you are mentioning you are using a TX Queue, but then you are reading the TX FIFO Empty (TFE) bit that is not applicable when using a TX Queue mode.  If you are using a TX FIFO configuration with the TX FIFO/Queue Mode (TFQM) bit of the TX Buffer Configuration (TXBC) register 0x10C0 set to '0' for TX FIFO Operation, then the TFE bit will indicate the status of the FIFO.  If you are using a Queue, the TFE bit is not applicable.

Also, if using a TX FIFO, you can look at the TX FIFO Free Level (TFFL) bit field of the TX FIFO/Queue Status (TXFQS) register to determine how many empty elements are in the FIFO and use that as an indication of the transmission status.

The TX Buffer Transmission Occurred (TXBTO) register can also be read to see the transmission status for all the TX Buffer elements.  A '1' will be written to the buffer element when a transmission has occurred.

The TX Buffer Request Pending (TXBRP) register can also be read to see which buffer elements have messages that are pending transmission and use a non-zero register as an indication of how many messages are still waiting to be transmitted.

You can also configure a TX Event FIFO that will create a log of which messages were transmitted and in what order they were transmitted which may be useful to some applications using a TX Queue where the messages are transmitted based on message ID (priority).  A timestamp is also added to the information if this information is of value to the application.

phoebe TAN said:

How can I know when the tx queue is empty?

This can only be done by the MCU reading the status registers, TX Event FIFO, etc. as I have just indicated to determine which messages have been transmitted, and which ones remain.

To reduce the CPU load, I would suggest using a TX FIFO configuration that would allow the MCU to monitor the TFE bit that can be tied to a hardware interrupt pin, to indicate when the TX FIFO is empty.  All non-TX FIFO configurations require the MCU to poll the status registers for the TX status.

I will also point out that the TCAN4550-Q1 uses the M_CAN CAN FD Controller IP developed by Bosch.  The M_CAN Users Manual published by Bosch contains more detailed information about the CAN FD Controller configuration and this document should be used as a supplemental document to the TCAN4550-Q1 datasheet.  You can download it from this link https://www.bosch-semiconductors.com/media/ip_modules/pdf_2/m_can/mcan_users_manual_v330.pdf

Regards,

Jonathan

Hi,

I am happy to hear that work is being made to improve the performance of the tcan4x5x driver in Linux. I am mostly concerned with the CPU load when logging traffic from several high bus load CAN buses. I start dropping frames at around 50% busload at 500k CAN bus due to CPU load. The system is an iMX8MP. Is there any driver available for me to test or some tweaks that can be made to the current driver? I am using Linux 5.15.60.

Thanks,

Mattias

Hi Mattias,

Our latest update from our 3rd party contractor last week was that they have mostly completed their debug of the driver to determine the areas of improvement that can be made and they are moving onto implementing the improvements.  We have asked them to provide us with versions that have incremental improvements if possible to share with our interested customers. I currently don't have anything to share beyond what you are currently using. 

I will however post back on this thread if or when we do receive an updated version that I can pass along.

Regards,

Jonathan