• State
  • Locked Locked
  • Replies 1 reply
  • Subscribers 100 subscribers
  • Views 781 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.

Synchronizing Timer (DMTimer) with CPTS

Dominic Rath
Mastermind 7450 points
Part Number: AM6548
Other Parts Discussed in Thread: TDA4VM

Dear TI team,

we're currently trying to synchronize the timer hardware of our AM6548 with the CPTS, and we have some questions regarding the general approach to solve this problem.

Our setup is:

  • TI AM6548 SR2.0
  • PROCESSOR SDK RTOS 07.01

Our application configures the NAVSS CPTS to synchronize its counter value with an external time source (which is our reference time base). This is working fine.

We want to trigger certain software events at a given time in our reference time base, and we want to have this time base accessible to code running on an R5f core. In order to do this, we want to use the timer hardware (section 12.8.3 in the TRM Rev. E, sometimes called DMTimer) to trigger interrupts.

The CPTS GENF signal is routed to the timer clock input (TIMER0_FCLK). This allows us to tune the timer counter to run at the same frequency as the CPTS. However, we still need to know the offset between both counters.

If we could route the timer compare output to a CPTS HW_TS_PUSH signal, this would solve our problem. Our software could program the timer compare register and could wait until the corresponding time stamp in the event FIFO of the CPTS would be generated. The difference between the time stamps would be our required offset.

Another possible solution would be to route (another) CPTS GENF signal to the capture input of the timer.

However, both of these routings are not possible.

As a workaround we did the following:

  • Configure the CPTS.
  • Configure the CPTS GENF signal to start at a known time in the future.
  • Route the CPTS GENF signal to the reference clock signal of the timer.
  • Configure the timer hardware.
  • Wait until the GENF signals starts (and the timer starts to count).
  • Now, we know that the timer starts to count at our configured time and we know the offset between both time bases.

However, this approach has got some flaws:

  • If we use the timer hardware in "non-posted mode", all register accesses will hang forever before the GENF signal is running. The reason is that the register access will be synchronized with the next tick of the timer's clock domain. And since the clock is not running, the synchronization will stall indefinitely.
  • We found that "posted mode" might allow us to work around that problem, but the TRM in section 12.8.3.4.12, is unclear whether that is allowed, or what drawbacks it might have ("it is not recommended to access the timer registers prior to the PLLs generating the timer and interface clocks have been configured and the clocks have stabilized"). "Not recommended" is a rather useless term in this context. Should it work? What side effects should we expect?

We've currently implemented the above workaround with posted mode, and it seems to be working, but we don't know if this is "safe".

If the timer registers really shouldn't be acccessed before the timer's functional clock is stable we would have to wait for the GENF signal to be available, and then start configuring the timer. That way we wouldn't have control over the offset between the CPTS counter and the timer counter, and would require a way to synchronize the timer with the CPTS.

Are there any alternatives?

There is a thread where outlined something similar for the TDA4VM (https://e2e.ti.com/support/processors/f/791/p/899500/3326239) but that post doesn't contain any details on the step that we're currently missing:

>> Once that is done, we have to configure TimeSync Router(TSR) to route either GTC/DMTimer pulse to HW push of MCU domain CPTS.


Best Regards,

Dominic

  • 0
    TI__Mastermind 37435 points

    Hi Dominic,

    Sorry, for the delay.

    This was quite a complex topic and I had to wrap my head around it to make it simple.

    So, your basic requirement is that you have a time synchronization signal coming over ethernet (is my assumption correct?) and you want to trigger interrupts based on it on an R5F. Correct ?

    I have a few questions for you:

    • Are you using MCU CPSW or ICSSG for this ? This part wasn't clear from the question. Or is your time source in some other format ?
    • You are using DMTimer specifically for some reason ? Is your requirement just an interrupt based on a compare event ?
    • Can you use any other Timer module for this ?

    Based on what you described, you can either generate the compare event directly or use TimeSync Router described in Section 11.3.2 of the TRM.

    You have a few options in front of you

    • Since you already have CPTS working, you can route the CPTS_GENF signal (which is an input to the TSR (TimeSync Router) ) to another module, say MCU_CPSW, which is capable of generating events based on compare values.
    • You can use the TS_COMP event of CPTS itself to generate an event of your choice bypassing the TSR, there is only one compare event register though.
    • You could also use the Timer Manager module (Section 11.2) which is fed by the CPTS module to configure different timers.
    • You can use the CMPEVT_INTRTR0 register to map the source compare event directly to A53 or R5F core as an interrupt.

    The workaround that you described should also work but is a roundabout way of doing it in my opinion. (unless you have a dependency on DM Timer). I have myself accessed the DM Timer registers without starting it in the past without any issues.

    However I can consult with a HW expert on the "Side effects" of doing what you described.

    Regarding examples, there is no example involving TSR on AM65 but there is a good presentation explaining this, called "TimeSync_design_overview.pdf" use-case under <SDK_INSTALLATION_DIR>/pdk/docs/trainings. Slides 11,12,13 are probably related to your use-case.

    Regarding API's on TimeSync Router, you can refer to the CSL code present under <SDK_INSTALLATION_DIR>/pdk/packages/ti/csl/src/ip/intr_router/V0/priv/csl_intr_router.c

    Regards

    Vineet