• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 99 subscribers
  • Views 211 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.

AM5718: Determining when EtherCAT distributed clocks are synced with the reference

Vikesh Subramanian
Prodigy 100 points
Part Number: AM5718


Tool/software:

Hello,

We are running the TI ESC on the AM5718. We are trying to generate an alert signal when the sync0 interrupt is out of sync with the reference clock. We have a partially working solution based on the System Time Difference Register with window monitoring enabled on the master. The remaining problem is when data transmission stops or a cable is unplugged, the sync0 interrupt continues triggering, but is no longer actively synced to the reference clock. Is there a method to check if the sync0 signal is being actively locked to the reference?

  • 0
    TI__Mastermind 32635 points

    Hello Vikesh,

    I will take a look at your enquiry and will get back to you next week.

    Best,

    Josue

  • 0
    TI__Mastermind 48231 points
    Vikesh Subramanian said:
    The remaining problem is when data transmission stops or a cable is unplugged,

    You can look at PD WD expiry status and DL status link state to determine this indirectly? Other option is to add 0x92c (System Time Diff) threshold check, say > +/- 1000ns implies SYNC is lost.

  • 0 in reply to PratheeshGangadhar
    Prodigy 100 points

    Hi Pratheesh,

    Thanks for your response. It seems like the PD WD status is serviced by the Sync0 interrupt to the processor, and therefore gets cleared even when the link is down (Sync0 ISR runs regardless of data transmission). We are currently running the system time difference solution, but notice that the register retains the last known value when the link is lost (does not go outside the threshold). The link status solution was our first thought too, but it can't detect faults on an upstream slave device - if there are 3 devices daisy chained, device 3 will not be able to tell if the link is down between 1 and 2, and will assume sync is still happening. Are there any other solutions we can try?

    Best,

    Vikesh

  • 0 in reply to Vikesh Subramanian
    TI__Mastermind 48231 points

    Sync ISR clearing PD WD expiry status does not seem like a compliant behavior to spec.

    Can you use system time diff settling to a constant value for many cycles as a means to detect connectivity loss to reference upstream?

  • 0 in reply to PratheeshGangadhar
    Prodigy 100 points

    Hi Pratheesh,

    This is the solution we implemented as a workaround. It is not ideal, as it introduces a delay detecting loss of the reference. I will investigate the correct behavior for clearing the WD status to see if there is a potential solution there.