<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>8-bit MicrocontrollersのトピックRe: MTIM-timer accuracy and stability in MC9S08QG8</title>
    <link>https://community.nxp.com/t5/8-bit-Microcontrollers/MTIM-timer-accuracy-and-stability-in-MC9S08QG8/m-p/129793#M2187</link>
    <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;DIV&gt;&lt;FONT size="2"&gt;Hello,&lt;/FONT&gt;&lt;/DIV&gt;&lt;DIV&gt;&lt;FONT size="2"&gt;&lt;/FONT&gt;&amp;nbsp;&lt;/DIV&gt;&lt;DIV&gt;&lt;FONT size="2"&gt;I assume you no longer have the 2.5+ % frequency error.&amp;nbsp; The removal of the extra&amp;nbsp;counter&amp;nbsp;reset, per Rocco's suggestion, should have fixed this.&lt;/FONT&gt;&lt;/DIV&gt;&lt;DIV&gt;&lt;FONT size="2"&gt;&lt;/FONT&gt;&amp;nbsp;&lt;/DIV&gt;&lt;DIV&gt;&lt;FONT size="2"&gt;Short term jitter of the output&amp;nbsp;would likely&amp;nbsp;be occurring because of the need to complete execution of the current instruction (within the main loop) before commencing the ISR.&amp;nbsp; While only a very few cycles uncertainty, it may be significant over only 25us, depending on your actual requirements.&lt;/FONT&gt;&lt;/DIV&gt;&lt;DIV&gt;&lt;FONT size="2"&gt;&lt;/FONT&gt;&amp;nbsp;&lt;/DIV&gt;&lt;DIV&gt;&lt;FONT size="2"&gt;Use of the hardware facilities of the TPM should avoid the uncertainty.&amp;nbsp; For an generating a signal, use the&amp;nbsp;output compare,&amp;nbsp;or for monitoring a signal, use the input capture facility.&lt;/FONT&gt;&lt;/DIV&gt;&lt;DIV&gt;&amp;nbsp;&lt;/DIV&gt;&lt;DIV&gt;&lt;FONT size="2"&gt;Another source of short term jitter is the FLL used for clock generation.&amp;nbsp; The shorter the averaging period, the more significant this will be.&amp;nbsp; For critical applications, you may need to avoid FLL use.&lt;/FONT&gt;&lt;/DIV&gt;&lt;DIV&gt;&amp;nbsp;&lt;/DIV&gt;&lt;DIV&gt;&lt;FONT size="2"&gt;Regards,&lt;/FONT&gt;&lt;/DIV&gt;&lt;DIV&gt;&lt;FONT size="2"&gt;Mac&lt;/FONT&gt;&lt;/DIV&gt;&lt;DIV&gt;&amp;nbsp;&lt;/DIV&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
    <pubDate>Tue, 10 Apr 2007 23:25:02 GMT</pubDate>
    <dc:creator>bigmac</dc:creator>
    <dc:date>2007-04-10T23:25:02Z</dc:date>
    <item>
      <title>MTIM-timer accuracy and stability in MC9S08QG8</title>
      <link>https://community.nxp.com/t5/8-bit-Microcontrollers/MTIM-timer-accuracy-and-stability-in-MC9S08QG8/m-p/129787#M2181</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;DIV&gt; &lt;/DIV&gt;&lt;P&gt;&lt;SPAN&gt;Greetings All,&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN&gt;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 (&lt;STRONG&gt;more then 2%&lt;/STRONG&gt;)!&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN&gt;I evaluate this chip using internal click source at maximal buss speed after trimming correction.&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN&gt;Platform: Freescele EVB - DEMO09S08QG8.&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN&gt;I set timer by following values:&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN&gt;&amp;nbsp;MTIMCLK_PS = 2;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; //&amp;nbsp;2*38=&amp;gt;should give 25us period&lt;BR /&gt;&amp;nbsp;MTIMCLK_CLKS = 0;&amp;nbsp;&amp;nbsp; // 0-Bus clock; 1-fixed-freq. clock&lt;BR /&gt;&amp;nbsp;MTIMMOD = 38;&amp;nbsp;&amp;nbsp;&amp;nbsp; &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; //&amp;nbsp;Modulo value for 25us period&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN&gt;&amp;nbsp;MTIMSC &amp;amp;=~ 0x90;&amp;nbsp; &amp;nbsp;&amp;nbsp; &lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;// clear TOF and exit stop TSTP&lt;BR /&gt;&amp;nbsp;MTIMSC |= 0x60;&amp;nbsp; &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; &lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;// reset and start MTIM, enable interrupts (TOIE)&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN&gt;COP is fed regularly.&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN&gt;The only allowed interrupt is conducted with MTIM with toggling some hardware pin with connection to scope allowing accurate frequency&amp;nbsp;measure.&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN&gt;The interrupt looks like:&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN&gt;interrupt 12 void&amp;nbsp;&amp;nbsp; MTIM_ISR(void)&lt;BR /&gt;{&lt;BR /&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp;volatile U_CHAR x;&lt;BR /&gt;&lt;/SPAN&gt;&lt;SPAN&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp;LED2 = ~LED2;&amp;nbsp;&amp;nbsp;&amp;nbsp; &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; // toggle&amp;nbsp;pin&amp;nbsp;- set to high – connected to the scope&lt;BR /&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp;x = MTIMSC_TOF;&lt;BR /&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp;MTIMSC_TOF = 0;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; // clear TOF flag&lt;BR /&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp;MTIMSC_TRST = 1;&amp;nbsp;&amp;nbsp;&amp;nbsp;// reset counter&lt;BR /&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp;LED2 = ~LED2;&amp;nbsp;&amp;nbsp;&amp;nbsp; &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; // toggle pin - set to low – connected to the scope&lt;BR /&gt;}&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN&gt;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).&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN&gt;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.&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN&gt;Had some body experience the same problem or can advice.&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN&gt;Thanks in advance.&lt;/SPAN&gt;&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Thu, 05 Apr 2007 20:33:42 GMT</pubDate>
      <guid>https://community.nxp.com/t5/8-bit-Microcontrollers/MTIM-timer-accuracy-and-stability-in-MC9S08QG8/m-p/129787#M2181</guid>
      <dc:creator>sfo</dc:creator>
      <dc:date>2007-04-05T20:33:42Z</dc:date>
    </item>
    <item>
      <title>Re: MTIM-timer accuracy and stability in MC9S08QG8</title>
      <link>https://community.nxp.com/t5/8-bit-Microcontrollers/MTIM-timer-accuracy-and-stability-in-MC9S08QG8/m-p/129788#M2182</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;DIV&gt;&lt;/DIV&gt;&lt;DIV&gt;&lt;FONT size="2"&gt;Hello,&lt;/FONT&gt;&lt;/DIV&gt;&lt;DIV&gt;&lt;FONT size="2"&gt;&lt;/FONT&gt;&amp;nbsp;&lt;/DIV&gt;&lt;DIV&gt;&lt;FONT size="2"&gt;If you are expecting an interrupt to occur every 25 microseconds, the ISR would need to complete in substantially less than this period.&amp;nbsp; 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.&amp;nbsp; You may need to consider writing the ISR in inline assembly&amp;nbsp;if a&amp;nbsp;reduction of&amp;nbsp;the number of cycles is required.&lt;/FONT&gt;&lt;/DIV&gt;&lt;DIV&gt;&lt;FONT size="2"&gt;&lt;/FONT&gt;&amp;nbsp;&lt;/DIV&gt;&lt;DIV&gt;&lt;FONT size="2"&gt;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.&lt;/FONT&gt;&lt;/DIV&gt;&lt;DIV&gt;&lt;FONT size="2"&gt;&lt;/FONT&gt;&amp;nbsp;&lt;/DIV&gt;&lt;DIV&gt;&lt;FONT size="2"&gt;Regards,&lt;/FONT&gt;&lt;/DIV&gt;&lt;DIV&gt;&lt;FONT size="2"&gt;Mac&lt;/FONT&gt;&lt;/DIV&gt;&lt;DIV&gt;&lt;FONT size="2"&gt;&lt;/FONT&gt;&amp;nbsp;&lt;/DIV&gt;&lt;P&gt;Message Edited by bigmac on &lt;SPAN class="date_text"&gt;2007-04-06&lt;/SPAN&gt;&lt;SPAN class="time_text"&gt;12:36 AM&lt;/SPAN&gt;&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Thu, 05 Apr 2007 21:28:41 GMT</pubDate>
      <guid>https://community.nxp.com/t5/8-bit-Microcontrollers/MTIM-timer-accuracy-and-stability-in-MC9S08QG8/m-p/129788#M2182</guid>
      <dc:creator>bigmac</dc:creator>
      <dc:date>2007-04-05T21:28:41Z</dc:date>
    </item>
    <item>
      <title>Re: MTIM-timer accuracy and stability in MC9S08QG8</title>
      <link>https://community.nxp.com/t5/8-bit-Microcontrollers/MTIM-timer-accuracy-and-stability-in-MC9S08QG8/m-p/129789#M2183</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;Hi, Sfo:&lt;BR /&gt;&lt;BR /&gt;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.&lt;BR /&gt;&lt;BR /&gt;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.&lt;BR /&gt;&lt;BR /&gt;Also, since the LED is toggled in the ISR, what you see on the LED will include the interupt latency.&lt;BR /&gt;&lt;DIV&gt;&lt;/DIV&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Fri, 06 Apr 2007 02:41:29 GMT</pubDate>
      <guid>https://community.nxp.com/t5/8-bit-Microcontrollers/MTIM-timer-accuracy-and-stability-in-MC9S08QG8/m-p/129789#M2183</guid>
      <dc:creator>rocco</dc:creator>
      <dc:date>2007-04-06T02:41:29Z</dc:date>
    </item>
    <item>
      <title>Re: MTIM-timer accuracy and stability in MC9S08QG8</title>
      <link>https://community.nxp.com/t5/8-bit-Microcontrollers/MTIM-timer-accuracy-and-stability-in-MC9S08QG8/m-p/129790#M2184</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;DIV&gt;&lt;/DIV&gt;&lt;DIV&gt;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.&lt;/DIV&gt;&lt;DIV&gt;&amp;nbsp;&lt;/DIV&gt;&lt;DIV&gt;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&amp;nbsp;MTIM&amp;nbsp;counter gets reset by this action.&lt;/DIV&gt;&lt;P&gt;Message Edited by YeOldeBDM on &lt;SPAN class="date_text"&gt;2007-04-05&lt;/SPAN&gt;&lt;SPAN class="time_text"&gt;11:28 PM&lt;/SPAN&gt;&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Fri, 06 Apr 2007 05:27:42 GMT</pubDate>
      <guid>https://community.nxp.com/t5/8-bit-Microcontrollers/MTIM-timer-accuracy-and-stability-in-MC9S08QG8/m-p/129790#M2184</guid>
      <dc:creator>YeOldeBDM</dc:creator>
      <dc:date>2007-04-06T05:27:42Z</dc:date>
    </item>
    <item>
      <title>Re: MTIM-timer accuracy and stability in MC9S08QG8</title>
      <link>https://community.nxp.com/t5/8-bit-Microcontrollers/MTIM-timer-accuracy-and-stability-in-MC9S08QG8/m-p/129791#M2185</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;DIV&gt;Hi sfo,&lt;/DIV&gt;&lt;DIV&gt;&amp;nbsp;&lt;/DIV&gt;&lt;DIV&gt;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.&lt;/DIV&gt;&lt;DIV&gt;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.&lt;/DIV&gt;&lt;DIV&gt;&amp;nbsp;&lt;/DIV&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Fri, 06 Apr 2007 06:02:43 GMT</pubDate>
      <guid>https://community.nxp.com/t5/8-bit-Microcontrollers/MTIM-timer-accuracy-and-stability-in-MC9S08QG8/m-p/129791#M2185</guid>
      <dc:creator>peg</dc:creator>
      <dc:date>2007-04-06T06:02:43Z</dc:date>
    </item>
    <item>
      <title>Re: MTIM-timer accuracy and stability in MC9S08QG8</title>
      <link>https://community.nxp.com/t5/8-bit-Microcontrollers/MTIM-timer-accuracy-and-stability-in-MC9S08QG8/m-p/129792#M2186</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;DIV&gt;&lt;/DIV&gt;&lt;P&gt;&lt;SPAN&gt;Thanks to&amp;nbsp;everybody, who participated in my question discussion.&lt;/SPAN&gt;&lt;SPAN&gt;&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;U&gt;&lt;SPAN&gt;To bigmac:&lt;/SPAN&gt;&lt;/U&gt; &lt;SPAN&gt;the ISR execution time&amp;nbsp;is less&amp;nbsp;then&amp;nbsp;25 us. It is about 8us, so the are no overlapping. I have calculated cycles amount and checked it with the scope.&lt;/SPAN&gt;&lt;SPAN&gt;&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;U&gt;&lt;SPAN&gt;To rocco&lt;/SPAN&gt;&lt;/U&gt;&lt;SPAN&gt;: you are right - I do not have to clear counter manually&amp;nbsp;inside the interrupt. It was my mistake in attempt to stabilize timing. Fixing it doesn't resolve my problem, but improves absolute time counting.&lt;/SPAN&gt;&lt;SPAN&gt;&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN&gt;The interrupt latency should add some&lt;/SPAN&gt; &lt;I&gt;&lt;SPAN&gt;constant&lt;/SPAN&gt;&lt;/I&gt; &lt;SPAN&gt;delay, but should not change the frequency of the interrupt appearance.&lt;/SPAN&gt;&lt;SPAN&gt;&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;U&gt;&lt;SPAN&gt;To peg&lt;/SPAN&gt;&lt;/U&gt;&lt;SPAN&gt;: as you have mentioned, the problem is in short time jittering. Actually, LED&amp;nbsp;flashing&amp;nbsp;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.&lt;/SPAN&gt;&lt;SPAN&gt;&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN&gt;Any other idea?&lt;/SPAN&gt;&lt;SPAN&gt;&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN&gt;Thanks again, guys.&lt;/SPAN&gt;&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Tue, 10 Apr 2007 16:38:47 GMT</pubDate>
      <guid>https://community.nxp.com/t5/8-bit-Microcontrollers/MTIM-timer-accuracy-and-stability-in-MC9S08QG8/m-p/129792#M2186</guid>
      <dc:creator>sfo</dc:creator>
      <dc:date>2007-04-10T16:38:47Z</dc:date>
    </item>
    <item>
      <title>Re: MTIM-timer accuracy and stability in MC9S08QG8</title>
      <link>https://community.nxp.com/t5/8-bit-Microcontrollers/MTIM-timer-accuracy-and-stability-in-MC9S08QG8/m-p/129793#M2187</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;DIV&gt;&lt;FONT size="2"&gt;Hello,&lt;/FONT&gt;&lt;/DIV&gt;&lt;DIV&gt;&lt;FONT size="2"&gt;&lt;/FONT&gt;&amp;nbsp;&lt;/DIV&gt;&lt;DIV&gt;&lt;FONT size="2"&gt;I assume you no longer have the 2.5+ % frequency error.&amp;nbsp; The removal of the extra&amp;nbsp;counter&amp;nbsp;reset, per Rocco's suggestion, should have fixed this.&lt;/FONT&gt;&lt;/DIV&gt;&lt;DIV&gt;&lt;FONT size="2"&gt;&lt;/FONT&gt;&amp;nbsp;&lt;/DIV&gt;&lt;DIV&gt;&lt;FONT size="2"&gt;Short term jitter of the output&amp;nbsp;would likely&amp;nbsp;be occurring because of the need to complete execution of the current instruction (within the main loop) before commencing the ISR.&amp;nbsp; While only a very few cycles uncertainty, it may be significant over only 25us, depending on your actual requirements.&lt;/FONT&gt;&lt;/DIV&gt;&lt;DIV&gt;&lt;FONT size="2"&gt;&lt;/FONT&gt;&amp;nbsp;&lt;/DIV&gt;&lt;DIV&gt;&lt;FONT size="2"&gt;Use of the hardware facilities of the TPM should avoid the uncertainty.&amp;nbsp; For an generating a signal, use the&amp;nbsp;output compare,&amp;nbsp;or for monitoring a signal, use the input capture facility.&lt;/FONT&gt;&lt;/DIV&gt;&lt;DIV&gt;&amp;nbsp;&lt;/DIV&gt;&lt;DIV&gt;&lt;FONT size="2"&gt;Another source of short term jitter is the FLL used for clock generation.&amp;nbsp; The shorter the averaging period, the more significant this will be.&amp;nbsp; For critical applications, you may need to avoid FLL use.&lt;/FONT&gt;&lt;/DIV&gt;&lt;DIV&gt;&amp;nbsp;&lt;/DIV&gt;&lt;DIV&gt;&lt;FONT size="2"&gt;Regards,&lt;/FONT&gt;&lt;/DIV&gt;&lt;DIV&gt;&lt;FONT size="2"&gt;Mac&lt;/FONT&gt;&lt;/DIV&gt;&lt;DIV&gt;&amp;nbsp;&lt;/DIV&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Tue, 10 Apr 2007 23:25:02 GMT</pubDate>
      <guid>https://community.nxp.com/t5/8-bit-Microcontrollers/MTIM-timer-accuracy-and-stability-in-MC9S08QG8/m-p/129793#M2187</guid>
      <dc:creator>bigmac</dc:creator>
      <dc:date>2007-04-10T23:25:02Z</dc:date>
    </item>
    <item>
      <title>Re: MTIM-timer accuracy and stability in MC9S08QG8</title>
      <link>https://community.nxp.com/t5/8-bit-Microcontrollers/MTIM-timer-accuracy-and-stability-in-MC9S08QG8/m-p/129794#M2188</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;DIV&gt;&lt;/DIV&gt;&lt;P&gt;&lt;SPAN&gt;Hi Mac,&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN&gt;I still have the 2% error. Removing counter reset inside ISR just changed a bit&amp;nbsp;the frequency, but it remains unstable.&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN&gt;I think, that this jitter occurs because command accomplishment cycles in main loop, as you mentioned. Followed calculation can approve it:&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN&gt;25us * 2% = 0.5us;&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN&gt;0.5us it is a time&amp;nbsp;of 4 cycles @ 16MHz clock.&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN&gt;I guess, it could not be improved and I have to build my algorithm to tolerate this jittering.&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN&gt;Thank you again.&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN&gt;Regards,&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN&gt;Alexander Udler&lt;/SPAN&gt;&lt;SPAN&gt;&lt;/SPAN&gt;&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Wed, 11 Apr 2007 20:10:06 GMT</pubDate>
      <guid>https://community.nxp.com/t5/8-bit-Microcontrollers/MTIM-timer-accuracy-and-stability-in-MC9S08QG8/m-p/129794#M2188</guid>
      <dc:creator>sfo</dc:creator>
      <dc:date>2007-04-11T20:10:06Z</dc:date>
    </item>
  </channel>
</rss>

