Unexpected Behavior of TIMER A/B

hello,

can anyone suggest any solution?

Thanks,

Joy

Not if you never post the code that does the read.

Dear Darkward,

Pls see attached Code for your persual.

Best regards,

Joy

If you stop the timer in up mode when it has the same value as TACCR0, this means that the timer is stopped in the middle of being set back to 0. Tihs makes the timer content fragile. Note that this applies only if the timer is stopped while being in the process of being reset to 0 by CCR0.

If you don't stop the timer and the timer is synchonized with MCLK (meaning the timer clock and MCLK are sourced by the same clock source), then there is no problem at all.

If the timer is clocked by a different clock source than MCLK (including external clock) and this source is slow compared the MCLK, then I can imagine this happen too even if the timer has not been stopped. Anyway, that's not what the errata sheet talks about. At least not the one for the 5438 which is form the same family and most likely has the same timer circuit.

Dear Jens-Michael,

Thanks for your comments.

In the project, Timer0_A5 using ACLK and it is working as continuous mode, so I feel when ever I check TA0R it should give some incremental value, when it reached 0xFFFF reset to 0 and start to increase again. For my case some times this TA0R register giving unexpected value.

Thanks,Joy

Dear Darkwzrd,

The timer A configured as continuous mode. So when ever check the TA0R value, it should give the corresponding value.

Thanks, Joy

Joy Tan said:

For my case some times this TA0R register giving unexpected value.

The debugger tries to halt timers/clocks, but it cannot stop the crystal. So even if the debugger is able to halt the timer, there likely will be a jump of the timer value from one signle step to the next. (since the crystal has clocked really many periods while you were pressing the stepping button)

There are many things in your timer functions which look strange. e.g. this function description:

"This routine delays the specified number of milliseconds using the system timer, thus we can sleep if the delay is long enough."
Yet thsi function just doe sbusy-waiting. No sleep at all.

It would be easier to write the delay into a global variable and go to sleep. the tiemr interrupt will count this variable down (actually it's a bit more difficult sicne your clock is 30.5µs, so you need to count fractions) and once you reached 0, the timer will wakeup the main thread. The CPU is sleeping except for the timer interrupts, no comparisons, all is fine. If you want, you can take the current fracion of a timer tick into account when settign up the countdown delay counter. And if you need it  really eaact, wake up one timer interrupt earlier and do the rest of the delay busy-waiting.
But note that waking up from LPM takes another 6µs that add to the interrupt latency time.

Anyway, your tierm doe snot run synchronized with the MCLK. So reading the tierm register while it is jsut updated by its unsynced clock will result in an erroneous reading. This is described in the description of the timer module. To have a correct reading, it is advices to read it three times and make a majority vote. (actually 4 reads may be necessary, so the two which are identical reflect the real state, as it is possible to get oen reading before, one during and one after the update, so three different readings.

There is, however, a situation in which you will never get two subsequent identical readings: if every timer tick triggers an interrupt and the interrupt execution time is long, you will at some point always read one value before and one after the timer update. But then you have more serious problems than reading the timer register :)

Dear Jens,

Sorry, need your advise.

Can I check with you that the TA0R will not corrupt when working as continuous up mode?

Thanks,

Joy

Jens-Michael Gross said:

Hmmm, how do you know? With a debugger? Debuggers are intrusive. The fact you're observing something through the debugger, changes the thing you observe. 

I agree that the code is a bit strange, but the TIMER0_A5_Get_Millisecond function does not look erroneous as far as the TAR read. We'll have to hear more about how and why the OP thinks the results read are bad.

The function WAKEUP_Start could potentially cause issues since it only reads TAR once (and TAR is assumed asynchronous based on the init routine), however, it doesn't seem to be called within the sample project supplied, so I cannot speculate further.

Joy Tan said:

Can I check with you that the TA0R will not corrupt when working as continuous up mode?

But your readings of TAR may still be incorrect if you perform the read in the very moment of TA0R being updated/incremented by a clock that is not synchroneous to MCLK. Hence the 'read 4, take the two identical' approach to be sure.

Dear Darkwzrd,

Thanks for the advice and reply.

Thanks, Joy