MTIM-timer accuracy and stability in MC9S08QG8

[sfo]

Greetings All,

I have a question regarding stability of wave frequency, which produced by MTIM timer module in MC9S08QG8 device. The problem appears when timer runs in high speed - the frequency of produced wave is not stable (more then 2%)!

I evaluate this chip using internal click source at maximal buss speed after trimming correction.

Platform: Freescele EVB - DEMO09S08QG8.

I set timer by following values:

 MTIMCLK_PS = 2;        // 2*38=>should give 25us period
 MTIMCLK_CLKS = 0;   // 0-Bus clock; 1-fixed-freq. clock
 MTIMMOD = 38;           // Modulo value for 25us period

 MTIMSC &=~ 0x90;      // clear TOF and exit stop TSTP
 MTIMSC |= 0x60;          // reset and start MTIM, enable interrupts (TOIE)

COP is fed regularly.

The only allowed interrupt is conducted with MTIM with toggling some hardware pin with connection to scope allowing accurate frequency measure.

The interrupt looks like:

interrupt 12 void   MTIM_ISR(void)
{
   volatile U_CHAR x;
   LED2 = ~LED2;          // toggle pin - set to high – connected to the scope
   x = MTIMSC_TOF;
   MTIMSC_TOF = 0;     // clear TOF flag
   MTIMSC_TRST = 1;   // reset counter
   LED2 = ~LED2;          // toggle pin - set to low – connected to the scope
}

As I mentioned, the output signal is not stable. The stability is above 2%. Accuracy depends on quantity of tasks inside main loop (again: there are no additional interrupts in my code).

I have tested it also on demo application demo9S08QG8_test.c, which comes with EVB. The same result - when I speed up the timer frequency, the signal becomes unstable.

Had some body experience the same problem or can advice.

Thanks in advance.

[peg]

Hi sfo,

You do not mention if the problem is short time jitter or long term in accuracy. My guess is that the long term frequency is perfect and that you are observing the period jittering. This would be due to the problems already pointed out.

This task is far better suited to the TPM module rather than the MTIM. The flashing of an LED from the TPM will be as accurate as your clock. The toggling of the output can be made to occur via hardware thus avoiding software latency issues.

[YeOldeBDM]

As someone else has already pointed out, (I cant find the thread) resetting the MTIM module does NOT affect any counts held in the prescaler to the MTIM counter. I gave up using the MTIM module to count edges over a very precise time interval because of this problem.

Now, I am not sure this directly addresses your problem, but I see you use the TRST bit to reset the counter. Don't assume that the prescaler to the MTIM counter gets reset by this action.

Message Edited by YeOldeBDM on 2007-04-0511:28 PM

[rocco]

Hi, Sfo:

In addition to what Mac stated, I noticed that you are reseting the counter in the ISR. Not only is this unnecessary, but it will introduce counter errors.

If you allow the timer to restart on it's own, no counts will be lost. By clearing it within the ISR, you will loose counts, and the number of counts lost will vary with the interupt latency.

Also, since the LED is toggled in the ISR, what you see on the LED will include the interupt latency.

[bigmac]

Hello,

If you are expecting an interrupt to occur every 25 microseconds, the ISR would need to complete in substantially less than this period.  You will need to accurately ascertain the number of bus cycles that the ISR requires (perhaps using the debugger), to make sure that this is not a problem.  You may need to consider writing the ISR in inline assembly if a reduction of the number of cycles is required.

If the ISR execution time were to slightly exceed 25 us, the commencement of each interrupt processing would be delayed, and eventually an interrupt would be missed.

Regards,

Mac

Message Edited by bigmac on 2007-04-0612:36 AM

[sfo]

Thanks to everybody, who participated in my question discussion.

To bigmac: the ISR execution time is less then 25 us. It is about 8us, so the are no overlapping. I have calculated cycles amount and checked it with the scope.

To rocco: you are right - I do not have to clear counter manually inside the interrupt. It was my mistake in attempt to stabilize timing. Fixing it doesn't resolve my problem, but improves absolute time counting.

The interrupt latency should add some constant delay, but should not change the frequency of the interrupt appearance.

To peg: as you have mentioned, the problem is in short time jittering. Actually, LED flashing has just evaluation reason - it is easy to measure by scope. The real purpose of this ISR is sampling some serial input line from wireless device, so I have to use interrupt.

Any other idea?

Thanks again, guys.

[bigmac]

Hello,

I assume you no longer have the 2.5+ % frequency error.  The removal of the extra counter reset, per Rocco's suggestion, should have fixed this.

Short term jitter of the output would likely be occurring because of the need to complete execution of the current instruction (within the main loop) before commencing the ISR.  While only a very few cycles uncertainty, it may be significant over only 25us, depending on your actual requirements.

Use of the hardware facilities of the TPM should avoid the uncertainty.  For an generating a signal, use the output compare, or for monitoring a signal, use the input capture facility.

Another source of short term jitter is the FLL used for clock generation.  The shorter the averaging period, the more significant this will be.  For critical applications, you may need to avoid FLL use.

Regards,

Mac

[sfo]

Hi Mac,

I still have the 2% error. Removing counter reset inside ISR just changed a bit the frequency, but it remains unstable.

I think, that this jitter occurs because command accomplishment cycles in main loop, as you mentioned. Followed calculation can approve it:

25us * 2% = 0.5us;

0.5us it is a time of 4 cycles @ 16MHz clock.

I guess, it could not be improved and I have to build my algorithm to tolerate this jittering.

Thank you again.

Regards,

Alexander Udler