• State
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 2 replies
  • Subscribers 101 subscribers
  • Views 212 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.

Original question:

[FAQ] AM64x: What is the Time Sync Router for? How do I use it?

AM6421: Common timestamp between A53(Linux) and R5 (FreeRTOS)

Angel Gavrailov
Intellectual 270 points
Part Number: AM6421
Other Parts Discussed in Thread: TMDS64EVM

Tool/software:

Dear TI Experts,

We have the following setup:

0) TMDS64EVM as hardware

1) Processor SDK 10.00.07.04 +  the corresponding Yocto for Linux, Kernel version 6.6.32-ti-01287

2) R5-0-0 and R5-0-1 running in split mode

3) Custom firmware, running on R5-0-0 from SRAM+TMC, with FreeRTOS

4) Implemented RPMSG, respectively IPC between Linux and R5

Our application:

  • we use the R5 to read 8 ch of 24-bit ADC data @ 128ksps pro channel and to transfer the data over shared memory to Linux. This kind of data we call Raw Data
  • we use the R5 to control different hardware, that is attached to several interfaces
  • we use Linux on the A-cores to process the raw data, configure the R5 Application and provide general connectivity to the outer world

What we'd would like to achieve:

  • Basically, we would like to have a common timestamp/timebase between Linux and R5/Freertos
    • We would like to be able to tag the raw data packets, created on the R5 with timestamps
    • For the error handling and event generation on the R5 side, we would like to be able to timestamp those events and errors
    • We want to be able to order and correlate Linux events with R5 events, based on this timestamp. 
  • The time granularity can be between 10us and 100us
  •  The timestamp between Linux/R5 is allowed to have some offset (and probably jitter), x00 ns are perfectly fine

Questions:

  • Which is the best way to achieve that? We already did some research and it appears, that the Time Sync Router + GTC would be the choice (https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1061474/faq-am64x-what-is-the-time-sync-router-for-how-do-i-use-it)
  • In case of the above, it would be better if the target core (R5) is not being disrupted by the GTC/TSR interrupt, but that signal is used to increment a Timer/Counter, whose value then to be read on demand by the R5 application. Is that a plausible solution and what would be the major steps to achieve that?
  • In case of too complex solution, it would be perfectly OK that the R5 reads a register, which stores the current common time. Unfortunately, there is only a brief GTC API explanation in the MCU+ SDK 10.01. 
  • What is the way to read this timestamp (presumably out of the GTC) at the Linux side?
  • In all cases, I suppose the GTC has to be configured from the Linux side. Again, the information there is pretty much missing, except several pages in the TRM, but we were unable to find a DT Entry description for this node. Please advise!

Thank you and regards,

Angel

  • 0
    Intellectual 270 points

    Dear experts,

    Any ideas? Thanks!

    Angel

  • 0
    TI__Guru** 101090 points

    Hello Angel,

    Apologies for the delay here. Are you getting your system time from an external source? (e.g., ethernet PTP on Linux?) Or do you just want roughly the same time to be shared between Linux and remote cores?

    If you can have hundreds of nanoseconds of drift / jitter, you might not need a fancy setup. GTC is basically the A53 core's counter, so that should be incrementing at the same rate as Linux system time.

    When we did some benchmarks on AM64x, it took a couple hundred nanoseconds to access memories outside of the processor. Reads within the processor should be faster. I cannot remember if these were average, worst case, or best case values, I can check if you want: https://www.ti.com/lit/spracv1

    So you might not even need to use the time sync router infrastructure (i.e., no router configuration, periodic pulse setup, etc). Since you can handle hundreds of ns of offset/jitter, it might be good enough for your application if the R5F cores just periodically read the GTC value, compare to their local counter value, and adjust the local counter as needed.

    Regards,

    Nick