• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 102 subscribers
  • Views 323 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Original question:

AM6442: Time sharing between AM53 and Core R5

AM6421: Synchronizing R5f timer with A53/Linux system time

Dominic Rath
Genius 5735 points
Part Number: AM6421

Dear TI team,

I'm looking for ideas on how to synchronize a timer that is able to generate an interrupt in the R5f cores with the linux system time, i.e. CLOCK_REALTIME or CLOCK_TAI.

I've seen a few threads where other customers asked similar questions, but the threads that I've found never came to a conclusion, e.g. https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1133559/am6442-time-sharing-between-am53-and-core-r5/4207778 or https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1158216/sk-am64-time-synchronization-between-a53-and-r-core.

In the most simple form Linux' CLOCK_REALTIME would be free-running with a rough estimate of "now", but we might also have a CLOCK_REALTIME that is synchronized to some outside time master, e.g. via NTP or PTP.

Are there any examples available or planned that show how to synchronize time between A53/Linux and an R5f, so that the R5f can a) read the current time with reasonable overhead and b) program timer interrupts relative to CLOCK_REALTIME?

Best Regards,

Dominic

  • 0
    Genius 5735 points

    ... a small update:

    We've started looking into the CPTS TS_COMP feature, and in theory it might be possible to use that, but we've got some concerns regarding this path:

    • we managed to route the event via CMPEVT_INTRTR0, but currently the interrupt appears to be constantly firing. Only when using a CPTS instance that is completely powered down (CPSW is unused in our case) is there no interrupt, but when using the PCIE0_CPTS or the "main" CPTS we get constant interrupts, even if the TS_COMP hasn't been enabled yet
    • the documentation for the CPSW CPTS mentions some restrictions:
      • not compatible with timepstamp PPM
      • not compatible with a non-zero CPSW_CPTS_TS_ADD_VAL_REG[2-0]

    Has the CPTS TS_COMP feature been validated, is there any example code available?

    Do the same restrictions that are documented in the CPSW chapter also apply to the "main" CPTS?

    Best Regards,

    Dominic

  • 0
    TI__Guru 72555 points

    Hello Dominic,

    We have discussed potential implementations of synchronizing R5F timer with Linux system time, but as far as I am aware at this point we have not developed specific example code that you can run. Let me double-check with the team.

    Could you point me to the part of the TRM that you are referencing?

    Regards,

    Nick

  • 0 in reply to Nick Saulnier
    Genius 5735 points

    Hello Nick,

    these limitations are mentioned in TRM Rev. E, chapter 12.2.1.4.7.9 Timestamp Compare Output.

    The main CPTS is documented in 10.1.3.6 Timestamp Compare Output, which doesn't contain this restrictions.

    Regards, Dominic 

  • 0 in reply to Dominic Rath
    Genius 5735 points

    ... another update:

    Dominic Rath said:
    we managed to route the event via CMPEVT_INTRTR0, but currently the interrupt appears to be constantly firing

    The issue was that the TS_COMP output defaulted to a logical '1' with '0' pulses indicating a compare match. After changing the polarity we got the desired interrupts.

    Unfortunately we believe that we've verified that the main CPTS is also affected by the limitations described for the CPSW CPTS (and thus unusable for us):

    Dominic Rath said:
    not compatible with a non-zero CPSW_CPTS_TS_ADD_VAL_REG[2-0]

    It seems that the timestamp compare feature only acts upon an exact match. In our test the ADD_VAL of 0x4 caused the programmed TS_COMP_VAL to be skipped, and no interrupt was generated. That would explain why it is incompatible with ADD_VAL and the PPM feature. Can you confirm this?

    Another issue with the TS_COMP approach is that the compare events also generate CPTS events which in turn cause interrupts in Linux, too, making this approach unusable for our purposes.

    We're trying to figure out if the CPTS GENF feature might work for us, but we've got some doubts regarding that, too, mainly because we fear that the separate PPM and NUDGE register eventually cause the GENF to drift when compared to the CPTS "main" TS counter. It might be possible to use the CPTS GENF in a "one-shot" mode though, because the way we understand it the "initial" timeout of the GENF COMP is based on the "main" TS counter, and only the "cyclic" period of the GENF is based on separate counters.

    It would be great if there's a proven/reliable approach. Let me know when you hear back from your team.

    Best Regards,

    Dominic

    Edited: GENF COMP might work, only GENF PPM/NUDGE appears to be problematic

  • 0 in reply to Dominic Rath
    TI__Mastermind 42560 points
    Dominic Rath said:
    Are there any examples available or planned that show how to synchronize time between A53/Linux and an R5f, so that the R5f can a) read the current time with reasonable overhead and b) program timer interrupts relative to CLOCK_REALTIME?

    Did you consider PRU-ICSSG IEP from one of the ICSSGs as an option? it has 64-bit timer with IEP_SLOW_COMPEN_REG which allows rate compensation (so that you can follow Linux time base) and also 16 IEP_CMPx_REGx which can be used to generate R5F interrupts via CMPEVT_INTRTR0. Though I am not aware of any examples, I am pretty sure that this will work as this HW is used implementation EtherCAT Distributed Clock and 802.1AS for communication protocols.