9S08SH Modulo timer sometimes doesn't reset

[Obetz]

Hello All,

did anybody observe that the modulo timer isn't reliably reset by writing to MTIMMOD?

As far as I see, a write to MTIMMOD doesn't reset TOF if the write occurs during an overflow event.

Tested with a bus clock and /4 prescaler.

Any workaround?

Oliver

[bigmac]

Hello Oliver,

I have not tested operation for similar problems, but an alternative method of resetting the MTIM counter, and clearing the flag, would seem to be to write a 1 to the TRST bit of the MTIMSC register.

Maybe the other method stated is a remnant from the datasheet for an earlier device, that did not include the TRST bit.

Regards,

Mac

[Obetz]

Hello Mac,

clearing the counter by setting TRST has the same flaw: If the write occurs in the prescaler cycle where the overflow occurs, TOF remains set (or is set again).

And since I use the modulo timer as a variable one shot delay, I need to write the new modulo value each time.

With a /4 prescaler, there is a three cpu cycle window each overflow where the error arises. I guess (but didn't try) that with larger prescalers, the window is also larger.

The fastest workaround I can think of is to write MTIMMOD twice. Sadly the 5c additional processing degrade the performance of my product.

And for larger prescaler values, even more effort is needed.

BTW: I don't think the MTIMMOD method is a "remnant". Both methods have their advantages. As you see, I want to select a new delay value on each write, and I can do this easily by writing the desired value to MTIMMOD.

Oliver

[bigmac]

Hello Oliver,

I am guessing, but the actual update of MTIMMOD might be delayed until the next MTIM clock transition.  For the case you mention, the next count state would be zero anyway.  So the issue is really that the flag becomes set under these circumstances.  Your delay timing application seems unusual in that you are attempting to zero the count prior to overflow having occurred.

One thing you could try is to stop the counter prior to loading a new value to MTIMMOD, and see whether this makes a difference (maybe now synchronised to the bus clock).  Perhaps the counter should also be stopped following each overflow, ready for the next write of MTIMMOD.

Are you polling the overflow flag, or using the interrupt.  If you are polling there will be at least a 5 cycle detection uncertainty.  If using interrupts, the interrupt latency would be greater.  I am not sure how the extra few cycles would degrade your product, since this would amount to a fixed delay correction.  The minimum modulo value is probably 2.or 3 with the current prescale setting, or more if using interrupts.

Regards,

Mac

[Obetz]

Hello Mac,

"stop the counter prior to loading a new value to MTIMMOD" is even slower than writing twice.

I'm polling the overflow flag. Interrupts are too slow.

The performance is affected at two places: 1. When the timer starts, there are several actions which have to be executed in quick sequence. I can't move the timer start to a less critical point because there is variable execution time between. 2. The code between timer start and query/wait can run shorter or longer than the (minimum required) delay.

The penalty is now 4c (writing TRST after writing MTIMMOD), we can bear with this.

Nevertheless I consider the observed behaviour as an error which should be documented.

Oliver

[Wingsy]

I'm a little late to this thread, but anyway....

I (for one) brought this quirk to the attention of Freescale over 4 years ago (for a QG8 chip) and I've not seen any documentation from them that either declares it to be a flaw or even to bring it to the attention of their users. Listed below is the first of many exchanges I had with them over this subject. The end result was that they tell me that once the modulo count is reached, an overflow event is inevitable on the next timer count. Well, yeah, that's what I was trying to tell them. Kinda screws it up for use as a one-shot timer.

Subject: MC9S08QG8: MTIM Reset Success Dependent Upon COUNT value

Description: If you reset the modulo 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).

The implications of this is that one cannot

configure the MTIM for a desired timeout value if

the COUNT register currently equals the MODULO

register. If you do the timer will time out sooner

than expected (on the next clock pulse from the

prescaler). This can go undetected during product

testing but can/will show up later when these

conditions are true.

[Obetz]

Hello Wingsy,

thanks for the confirmation!

I also had many hard discussions with Freescale support in the past years. Usually it takes several rounds to demonstrate the problem, and then it takes years until it gets documented (if ever).

For the modulo timer, I needed four mails to the support. I even had to provide test code to demonstrate the problem. Since 2010-11-18 they are "reviewing and testing"...

That's so much the worse since the problem should be well known at least to Freescale support as you already reported it.

It seems we are wasting our time by reporting bugs more often than not.

That's such a waste of working time especially for all the other developers stumbling again over the bugs.

Frustrating, isn't it?

Oliver

[Eng8492]

And if I recall correctly, setting TRST does NOT reset the prescaler.