• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 100 subscribers
  • Views 249 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.

TDA4VH-Q1: Clarification on behavior of timer auto-reload

Matthew Schnur
Prodigy 150 points
Part Number: TDA4VH-Q1

Tool/software:

With the timer auto-reload enabled, when the timer overflows does the counter get set to the reset value AND get incremented on the next clock cycle or does it only get set to the reset value on the next cycle? Essentially, which of the following two graphs accurately shows the auto-reload timing (assuming the counter overflow value is 5 and the reset value is 2)? The first shows the counter updating to the reset value AND incrementing on the next cycle, while the second shows it updating to the reset value on the next cycle but only incrementing the cycle after that.

  • +1
    TI__Mastermind 23505 points

    Hello,

    From the specification the second picture where the reload value gets a full tick would be expected. Which timer are you using exactly? How are you trying to use the clock such that this question is coming up? If you are trying to read or write the timers there will be some delay from the time the CPU launches an access, till the timer registers capture the command, and till the timer resynchronizes internally to process the command.  The ratios of the interface clock to the functional clock and timer settings will result in different kinds of delays.  The interface clock is what is used for a CPU to access timer registers and the functional clock is used for the ticking and consuming commands captured in registers.  Depending on the setup there can be some fuzz when monitoring via registers and trying to understand 'exact' time.   When trying to hit exact periods source clocks can matter over long spans of time, though the 1ms feature is implemented in a way to cause self correction of drift which happens non perfect number math.

    Regards,
    Richard W.
  • 0 in reply to Richard Woodruff
    Prodigy 150 points

    Second one, got it. I was leaning towards that one but wanted to confirm. Thank you for the answer!

    I plan on using the Timer module (AKA DMTimer) in the main domain. I can use pretty much any of the instances, though my impression is there shouldn't be differences in behavior from instance to instance among the instances in the main domain. The read/write access delays are the exact reason I want to use the auto-reload feature: I want to synchronize an action to occur periodically w/o drift, so I will set up the timer so that the reload value is set in a way that results in the timer overflowing once per my desired period. I then have an interrupt set up to do that action I want to do periodically.

    This setup should avoid the issues with the delays you mention, right?

  • 0 in reply to Matthew Schnur
    TI__Mastermind 23505 points

    Using the event interrupt with auto reload should avoid fuzz around timer access overheads.  What is sufficient for your usage idea depends on the time scales you are trying to guarantee.  If you are feeding into many layers of SW which timeshare the low layer efforts might not be realizable.  If your controlling the variables you can set the budgets and make the tradeoffs..