• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 33 subscribers
  • Views 176 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TCAN4550-Q1: Throughput issue with multiple CANFD

Ankita Hegde
Prodigy 50 points
Part Number: TCAN4550-Q1
Other Parts Discussed in Thread: TCAN4550

Tool/software:

Dear Team,

We are using TCAN4550 with iMX8DXL processor lpspi. We have configured two CANFD to be connected two different SPI lines with two different TCAN chip. Now the issue is if we do the TX with single CAN we are getting throughput of around 5.5k msg/sec but when we do TX with both CAN in same arbitration and bitrate combination the throughput in each can will be reduced to half, like each CAN node transmits of around 2.7k messages per second which is not expected. So is there any way that you can help us to fix this issue.

Regards,

Ankita

  • 0
    TI__Mastermind 33790 points

    Hi Ankita,

    I see two possible limitations you should explore.

    If your SPI buses are not running on separate cores in the processor that will allow both SPI buses to be run independently and in parallel, then the processor may only be able to communicate to a single TCAN4550 at a time even though the SPI bus interface are separate connections.  This could explain why the total number of messages remained the same but were split between the two devices because the single core can still only service a single TCAN4550 at a time.

    The other possibility to explore is whether the CAN bus has enough idle bandwidth to handle twice the number of CAN messages.  If not, there may be arbitration limitations on the total number of messages sent in a given time.

    Regards,

    Jonathan

  • 0 in reply to Jonathan Nerger
    Prodigy 50 points

    Hi Jonathan,

    Thank you for the reply.

    Jonathan Nerger said:
    running on separate cores in the processor that will allow both SPI buses to be run independently and in parallel,

    Is there any example or way how we can achieve this?

    Jonathan Nerger said:
    The other possibility to explore is whether the CAN bus has enough idle bandwidth to handle twice the number of CAN messages.  If not, there may be arbitration limitations on the total number of messages sent in a given time.

    Also is there a specific way to check this and what should be the expected values in these fields?

    Regards,

    Ankita

  • 0 in reply to Ankita Hegde
    TI__Mastermind 33790 points

    Hi Ankita,

    Ankita Hegde said:
    Is there any example or way how we can achieve this?

    I support the TCAN4550 at the device level and can help with questions relating to the register configuration and hardware related questions.  I am not familiar with the iMX8DXL processor and how they chose to develop their firmware.  I'm simply pointing out that with a single core, the processor may only be able to communicate through one SPI peripheral interface at a time.  If so this means that while the processor is communicating with one TCAN4550 through SPI, the other TCAN4550 SPI interface is idle. 

    Ankita Hegde said:
    Also is there a specific way to check this and what should be the expected values in these fields?

    There are many CAN Analyzer tools available that can provide diagnostic information and run various CAN bus performance tests. 

    However my point was more general in that they should know if there are a lot of CAN messages on the bus being generated by other devices.  If they have a simple test setup with just a couple of devices talking directly to each other, then this is likely not the case.  A scope could also be used to monitor the CAN bus and determine if there is sufficient idle time that would allow for messages with lower priority message ID's to get their message transmitted so that they don't get repeatedly blocked by other nodes that are transmitting messages with higher priority message IDs.

    Regards,

    Jonathan