• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 2 answers
  • Subscribers 84 subscribers
  • Views 382 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.

LAUNCHXL-F280049C: Routing CAN Interrupt Lines to the CLB

Rishab Anand
Prodigy 40 points
Part Number: LAUNCHXL-F280049C

I am trying to implement a precision time synchronization scheme over CAN for PWM carrier synchronization.

One way I could think of is to reset the PWM counters through a software ISR. The CAN interrupts have a very low priority and may be blocked by other interrupts leading to reliability issues. 

Other way could be to use an external CAN controller with Tx / Rx interrupt lines. 

Another way could be to use the CAN Tx interrupt on the time master to capture the sending time and CAN Rx interrupt on the time slaves to capture the local receiving time without any main CPU action. The times can be counter values on a CLB tile. I find this robust well suited to my problem but I cannot figure out any way to route the CAN interrupt lines to the CLB.

Is there a solution to this ?

  • 0
    TI__Mastermind 19795 points

    Hi,

    Thanks for your question! Before diving into the suggestions you mentioned, would DMA work for your CAN interrupt? If you only care about the data being received in a timely manner, you can use the DMA to transfer the data WITHOUT an interrupt.

    If you are specifically talking about using CAN as a "trigger" for PWM sync, then I would likely lean towards your CLB suggestion. If so I will contact the CLB expert and let them provide suggestions. My guess for CLB is that the best way to do this kind of triggering would be using falling edge detection on CAN-RX (instead of actual data reception), that way you can consistently trigger on first bit of data. If the data is necessary, then this gets a bit more complicated, so do let me know a bit more on this if what I have here is insufficient.

    Regards,
    Vince

  • 0 in reply to Vince
    Prodigy 40 points

    Thanks for the quick reply. 

    I am not really concerned with transfer of data received over CAN.

    I essentially want to implement the mechanism described in this document on page 5. 

    https://www.autosar.org/fileadmin/user_upload/standards/classic/4-3/AUTOSAR_SWS_TimeSyncOverCAN.pdf

    I want to probably send a specific message which triggers PWM sync while using also using the same CAN bus for other data transfer. Falling edge detection on CAN Rx will be excellent timing accuracy wise, but it would trigger sync on every message leaving no control over when to synchronize. I was looking at something which looks at the message and generates a signal to capture a free running timer count only if it is a specific message.

    I was looking at other questions on this forum and found that the CAN interrupt lines are connected to the eCAP module as inputs.

    https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/575269/tms320f28075-time-stamps-for-controller-area-network-can

    Is it possible to start the eCAP module counter and capture the count when a specific message arrives ?

  • 0 in reply to Rishab Anand
    TI__Guru* 95315 points

    Rishabh,

          Not knowing enough about your network, I will say that CAN is not suitable for deterministic communication. This is especially true if there are multiple nodes on the network, which leads to arbitration. Of course, if there are only two nodes, you can make the communication deterministic by choosing the MSGID appropriately.

    Rishab Anand said:
    Is it possible to start the eCAP module counter and capture the count when a specific message arrives ?

    Yes, this should be possible.

  • 0 in reply to Hareesh Janakiraman
    Prodigy 40 points

    My apologies for not following up. As you pointed out, I do understand that CAN is not deterministic. The mechanism in fact used the time stamp capture mechanism that you described in your old post as a means to capture and eliminate these very random delays. I do have some concerns though. 

    I have two F280025C boards generating 50 Hz square waves. I want to synchronize the two square waves.

    Assuming that the clocks only have a very small difference on the two boards, I only need to compensate the initial random phase difference, and then periodically compensate any minor phase differences that arise out of the clock difference. 

    I have an ePWM counter running in up-down count mode, generating a sync out signal at zero count. I use this as a sync in signal to an eCAP counter, so that the ePWM and eCAP counters are synchronized.

    I have two CAN messages - a SYNC message and a follow-up message. I configure the CAN modules to generate interrupts on successful transmission or reception of the SYNC message.

    On the time master, I configure the CAN TX interrupt to cause an eCAP event and capture the count. On the time slave, I configure the CAN RX interrupt to cause an event and capture the count. 

    My assumption is that the TX and RX interrupts are generated at the same point on the CAN message frame (or within a fixed number of bits), so that the counts captured on both the boards should be the same if the PWMs were synchronized. The count at the time master is sent to the slave as the payload of the follow-up message. Any difference in the counts is fed as a one time phase shift to the ePWM module so that the phase shift is compensated. 

    I am however getting some jitter and wanted to make sure my assumption regarding the interrupts is correct (TX and RX interrupts are generated at the same point on the CAN message frame (or within a fixed number of bits)). Please comment.  

  • +1 in reply to Rishab Anand
    TI__Guru* 95315 points

    I am not sure if the transmit and receive interrupts would happen at exactly the same instant on the two Launchpads. I would expect some jitter due to the oscillator tolerance. You could simply toggle a GPIO pin in the ISRs, put your scope in persistence mode and try it out.