• State Resolved
  • Locked Locked
  • Replies 16 replies
  • Subscribers 32 subscribers
  • Views 1448 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.

TM4C129XNCZAD: Start timer on CCP transition

Greg Winters
Intellectual 720 points
Part Number: TM4C129XNCZAD

I would like to have a timer start and increment at the rate of the system clock when an input toggles.  I assume the input would be the CCP pin associated with the timer and designed hardware with that in mind.

I see there is a way to set up a timer in one-shot mode to start counter when another counter in its 'chain' triggers, but cannot see how to do it based on an input.

I know it is possible to have an interrupt occur when an input toggles and I could examine system time in the ISR, but there are various latencies associated with that - which is the point of the timer.


Specifically, I want to use the timer as an error calculator.  I will have an ISR triggered by the same signal tied to another GPIO.  The point of the timer is that I will be able to determine the precise latency of the interrupt by examining the magnitude of the timer in the ISR.

Is there a way to set this up via Tivaware or if not that, direct register access?

  • 0
    Guru 13040 points

    Greg, interesting question... I would assume this was "quite possible", but I can't find the answer on Tivaware (nor or direct registers). Apparently, there is no such "timer-start-trigger".
    However, there are options. Take a look at this thread:
    e2e.ti.com/.../564508
    You can quite easily keep your timer counter rolling, read the event counter on the first transition, and then read it again on the second - you should have the difference you are looking for. Do note that there is one register that keeps the exact counter value of when the pin transition happened.

    BTW: TivaWare documentation does not make it clear if TimerValueGet() reads from the continuous counting register (the one offset 0x050) or the "edge last event register" (the one offset 0x048). I had to once look directly at the code to find out. It could be the case of TI to create separate functions for both, for the API description might be misleading. These days, reading timer counter is one rare thing I do by reading the register value directly instead of using a TivaWare call.

  • 0 in reply to Bruno Saraiva
    Intellectual 720 points
    After a significant rabbit hole: Per the example cited I figured I would have to use DMA to grab the timer value at the time of a CCP trigger...

    I found that the timer can be configured in 'Input Edge-Time Mode' (which is alluded to in your answer) where the timer is free running and a configured CCP event causes the current timer value to be squirreled into a HW register. From that, in the ISR, I can do a delta between the current timer value and the squirreled value.

    I'm suggesting this as answer, if I am correct, please verify.
  • 0 in reply to Greg Winters
    Guru 47900 points

    Only the originating poster (i.e. you, here) may, "Verify" an answer. Such should reveal upon your review of any post w/in this thread...

  • 0 in reply to Greg Winters
    TI__Guru**** 244400 points
    Hello Greg,

    Do note that when using the Input Edge-Time Mode, and two events occur across a timeout (roll over) boundary, it is not possible to determine the number of such roll overs. It would be safe to sync the timer with a periodic timer so that timeouts can be counted to correctly determine the time spacing.
  • 0 in reply to Amit Ashara
    Intellectual 720 points

    Understood.

    The event is occurring approx every 4 seconds.

    I hope you are as confident as I that the interrupt will be serviced within that timeframe. :)

  • 0 in reply to Greg Winters
    TI__Guru**** 244400 points
    Hello Greg

    The interrupt is OK. It can be serviced pretty fast. But since the even is occurring in the seconds range, I would like that you implement the timeout counter as well to be able to count the number of rollovers.
  • 0 in reply to Amit Ashara
    Intellectual 720 points
    Not sure you understand. The timer is being used to determine (and offset) interrupt latency. By definition, each time the event occurs an interrupt is generated. The ISR will occur within the rollover period. If that's not true, there are bigger problems.
  • 0 in reply to Greg Winters
    TI__Guru**** 244400 points
    Hello Greg

    Now let us assume that the edge gets captured at a count of 0xFFFE. The interrupt handler takes 12-14 clock cycles to execute. Now the capture time is recorded but the rollover has occurred and the current count is somewhere close to 0x000A. This condition is bound to happen at some point in time.

    I am not sure what you are trying to do by having the edge recorded and current timer value on ISR execution. Maybe a detailed explanation would be useful.
  • 0 in reply to Greg Winters
    Guru 13040 points

    Greg Winters45 said:
    If that's not true, there are bigger problems.

    Greg,

    Then there are indeed bigger problems. But that's not an MCU problem, it is an implementation strategy one.

    When the interrupt occurs, your MCU could be serving a different interrupt - could be a short, simple 25 cycles one - but still, it would finish that before paying proper attention to your timer IRQ. On a different moment, your MCU could be doing nothing in the main thread, and serve the request immediately. Simple: it is not deterministic.

    That's why what you need to do is to make use of the counter value when the transition happened (by means of GPTMTAR register). It does not matter if you deal with your event 14 or 75 cycles later, you will still have the correct instant available for your use!

    Bruno

  • 0 in reply to Greg Winters
    Guru 13040 points
    No, you do not need to use DMA to grab the value of the CCP event timer.
    The discussion on that post only states that, since DMA is faster than interrupt/copy, the choice of using DMA will let you measure events that are "closer apart" than if not using. But this applies only when we are talking nanoseconds.
    Just read GPTMTAR register. Your homework is to figure out what that is, and which Tivaware function, if any, will do that for you.
  • 0 in reply to Bruno Saraiva
    Intellectual 720 points

    Bruno:

    Sorry if I sounded ungrateful for your original post.  That was not my intent, it was kind of fun investigating the DMA path but then when figuring out how to get the DMA to actually trigger, I saw that as you had indicated, at the point of the capture event, the timer module (not the ARM CPU) saves a copy of the current value of the timer into a HW register (GPTMTAR).  This is even faster than DMA since there are no possible bus conflicts.  Then when the ARM CPU finally gets around to servicing the interrupt you can use the difference between GPTMTAV and GPTMTAR to calculate the ARM CPU ISR latency (which is what I want).  So no matter how long it takes for the ISR to start executing, I know exactly when the signal occurred.

    I am directly using the HWREG macro to access the GPTMTAR register.  I have no problem going direct when Tivaware falls short.

    Thanks,

    Greg

  • 0 in reply to Amit Ashara
    Intellectual 720 points
    I thought you were talking about something else when you were saying rollover.
    What you are describing is easily handled by checking for a negative result and if so adding back in the load value (when counting up).
    I already had added code to handle this case.
    Thanks, Greg
  • 0 in reply to Greg Winters
    Guru 13040 points

    Greg Winters45 said:
    Sorry if I sounded ungrateful for your original post.

    Not at all, Greg!!!

    And nor did I mean to imply such! Sometimes texts messages can be read with a twisted tone created by the reader's momentary bias...

    It is always a pleasure to try and help fellows who are dedicated. Over all the posts I ever read/received on this forum, there was only one event which got me sour - and then I was quite clear about the disliking!

    Cheers

    Bruno

  • 0 in reply to Greg Winters
    TI__Guru**** 244400 points
    Hello Greg

    Not just negative result. But way off result. How can we be sure of the number of times the rollover has occurred since the timer does not provide a timeout interrupt or a load interrupt at the time of a roll over.
  • 0 in reply to Amit Ashara
    Intellectual 720 points

    Here is the sequence:

    1. The capture event occurs, this causes two thing to happen:
      1. The current value of the timer is saved into GPTMTAR
      2. A capture interrupt is made pending.
    2. Sometime in the VERY NEAR FUTURE, within the number of counts specified by the value in GPTMTAILR the ARM CPU services the pending capture interrupt (multiple rollovers CANNOT OCCUR).
    3. In the capture ISR, into a variable called 'diff', place GPTMTAV - GPTMTAR
    4. If a rollover has occurred, GPTMTAV will be less than GPTMTAR and the value in 'diff' will be negative. In that case, add in the value stored in GPTMTAILR.  This will give you the correct time delta.

    If you are thinking something could mask interrupts for a very long time causing multiple rollovers to occur, yes that is true in theory, but not in this instance.  Interrupts are not masked long in my application.

  • 0 in reply to Greg Winters
    TI__Guru**** 244400 points

    Hello Greg

    You summed it up very well.

    Greg Winters45 said:
    If you are thinking something could mask interrupts for a very long time causing multiple rollovers to occur, yes that is true in theory, but not in this instance.  Interrupts are not masked long in my application.

    This is what I would like you to guard the code. Also to think of it if something like this did happen in the application, the roll over count may also not be detected prompting for a NMI operation from Watchdog.