MTIM Quirk (QG8) - Reset dependent upon COUNT

[Wings]

In testing whether or not the Modulo Timer's prescaler in a QG8 is reset when you reset the timer or store a new value in the Modulo register (it IS reset, BTW), I discovered a quirk about the timer that can kill ya.

If you reset the timer by setting the TRST bit in MTIMSC or by storing a new value in the MODULO register, the timer WILL STILL TIME OUT ON THE VERY NEXT CLOCK if the COUNT register was equal to the MODULO count at the time of reset.

For example, lets say the output of the prescaler is 1 KHz (1ms period), and your MODULO value was 99. If you set the TRST bit at a count of 98 (or less), then the COUNT will reset to 0 and the timer will not time out until 100ms after setting TRST. This is the expected result. However, if you set TRST while the COUNT is 99 then the timer will time out within 1 ms (at the next clock output from the prescaler).

I've seen warnings in the data sheet before about things that can kill ya but this one should be in a bold red font, and it's not even mentioned.

Talk about a time bomb.

I'm still working on a way around this and when I have something that works 100 percent I'll post it here... or someone else can and save me the time.

[Wings]

Well, I'm stumped in finding a workaround for this.

Setting the TRST doesn't work.

Storing a new, even different, value into MODULO doesn't work.

Stopping the timer then setting TRST and/or saving a new MODULO doesn't work - you still get a timeout within one clock after allowing the timer to run.

After stopping & resetting the timer, then storing a new value into the prescaler (PS) bits, doesn't work.

After stopping & resetting the timer, then reading MTIMSC followed by clearing the TOF bit (pre-acknowledging the upcoming timer overflow), doesn't work either.

So I've knocked on the modulo timer in every way I know how and it is determined to time out one tick later once it hits the modulo value.

The only solution I can see at the moment is to delay re-arming the MTIM until the next timeout if the current COUNT value equals the MODULO value. That's not going to work in my application because I need the timed duration to start right NOW.

Anybody got any ideas?

Message Edited by Wings on 2006-07-30 01:33 PM

[bigmac]

Hello Wings,

If you are using the MTIM on a non-repetitive basis, I wonder if the following approach might work -

1. When the timer times out at the conclusion of the previous delay, stop and reset the timer.
2. When a new delay is required, set the modulo value and start the timer.

By stopping the timer until you need it again should prevent the modulo count condition ever being reached just prior to starting the new delay.

Regards,
Mac

[Wings]

Hey, thanks Mac. I think I can make that work. I use the timer in a repetitive mode for a period of time before I need to use it for my one-shot timer, and I can surely stop the timer on the next ISR when I'm done with it. It should be ready to go without this glitch when I need it for the one-shot, which will always be much later on relative to the timer's period. When the one-shot event is done I can stop it again so it'll be ready for the periodic timer when that's due again. Yeah, this'll work. Thanks again.

(I've got the other timers and the RTI all in use and not easily time-shared or I'd certainly be looking for one of them to do my timing. Using the MTIM for this timeout was supposed to be a piece of cake.)

[Wings]

Well, it's official. I got a response back from filing this issue with Freescale and they say that's the way it works.

So beware. If you use the MTIM a good rule of thumb would be, don't rely on its first timeout being what you expect unless you account for this abnormality.