• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 79 subscribers
  • Views 234 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.

MSP430F2132: Timers Out of Sync

Calex36
Intellectual 1695 points
Part Number: MSP430F2132

Hi, 

We have two versions of the same code (in assembler) running on an MSP430F2132, where one uses the watchdog timer in interval mode and the other timer A0 in continuous mode, to interrupt at a period of 15.625ms.

Both the watchdog and the timer are using the same reference clock and the registers divide the clock down to the same period.

 

The 15.625ms time is used to flash an LED once every second by counting 64 interrupts and then turning the LED on.

 

We have the ability to synchronize the two versions of the code (running at the same time on separate devices) so that the LEDs flash in unison with each other. However, over a period of 3 minutes, the two LED flashes drift apart and go out of sync with each other (this is noticeable by eye).

 

If we flash both devices with the same version of code (either both using the WDT or both using timer A0) then the LEDs stay in sync indefinitely.

 

The code inside the WDT interrupt and Timer A0 interrupts are almost identical. The only difference is that the timer A0 code adds the period onto its current CCR0 value to set up for the next interval.

 

If we reduce the timer CCR0 value by 2 counts (equivalent of 3.81us) then the two remain almost in sync (after 30 mins it becomes noticeable).

 

Do you know of any differences between the watchdog timer and timer A0 that would cause the timer period to be slightly slower than the watchdog. Such as time to service the interrupt.

Regards

Calex

  • 0
    TI__Mastermind 49692 points

    Hello Calex,

    Thanks for your detailed post. I suspect that this issue is caused by one or more Timer_A-related errata. Please refer to the erratasheet for more details.

    Regards,

    James

  • 0 in reply to James Evans
    TI__Intellectual 1695 points

    Thank you,

    Relating to the details would you agree that it is most relatable to TA12 in the errata?

    Regards

    Calex

  • 0 in reply to James Evans
    TI__Intellectual 1695 points

    Just to clarify,

    the errata uses the example of CCRx + 1, would the same issue occur if we were incrementing by a larger number (we are incrementing CCR0 by 8192).
    We don’t think its TA21 or TA16 as we are not experiencing PUC/TACLR and we’re not using up mode. We’re in continuous mode and add 8192 to the previous CCR0 value as the first line in the interrupt

  • 0 in reply to Calex36
    TI__Intellectual 1695 points

    Update, we tried all the workarounds in the errata and it made no difference, any other suggestions?  

  • 0 in reply to Calex36
    TI__Mastermind 49692 points

    Hello,

    Thanks for checking and confirming that the erratas don't affect this behavior.

    Could you help me understand this exercise? Is it just a comparison between the modules to decide which timer module you'll use in your design?

    Unless I'm missing the purpose of this exercise, the behavior doesn't concern me because using the same modules and code on different devices (same P/N) with the same clock source yields synchronized behavior. Otherwise, I would be concerned.

    Hardware differences

    Even if they have the same clock source, the WDT and Timer0 modules are going to be implemented differently in the device. One may have more propagation delay or some other physical characteristic that causes the small timing difference or drift. For example, the WDT is typically used to perform a reset when a software problem occurs. That wouldn't need to be very precise, just as long as the device gets reset in a timely manner. However, the Timer0 would be used to perform a very time-crucial task that requires higher precision.

    Software differences

    Now, if the code is different in the ISR, then there could be a few CPU cycles between when the timers actually get triggered that could add up over time and cause this behavior.

    I would recommend using the same module and same clock source on different devices (same P/N) to avoid this condition.

    Regards,

    James

  • 0 in reply to James Evans
    TI__Intellectual 1695 points

    Thanks James,

    We think we’ve worked out what was causing the problem.

    Swapping from the watchdog to the timer seems to cause a “collision” of two interrupts. It appears that when the timer interrupt wants to be processed, occasionally its already in another, which delays timer A0 (which is timing critical) for a short period of time.

    Knowing this now is enough for us to potentially fix it.

    Regards

    Calex

  • 0
    Prodigy 250 points

    it is hard to tell, without saying your code or clarifying your description of the issues.

    post something minimalist and help others help you.

**Attention** This is a public forum