HC908GR8: TBM interrupt periods are not regular

[Simen]

Hi,

I use the TBM interrupt in GR4.
The result shows the interrupt periods are not regular.
Please tell me what 's wrong with my code.

Thanks a lot!

----------------------------------------

__interrupt void isrINT_TBM(void)
{
   TBCR=TBCR|0x08;        // clear TBIF,set 1 to TACK
         PTD^=0x10;

}


--
Alban Edit: Please always include FSL Part Number in Message Subject line.
http://forums.freescale.com/freescale/board/message?board.id=FORUMUSE&message.id=865

Message Edited by Alban on 2007-10-16 08:26 AM

16-10-07_1048.jpg

GR4_AR9.zip

Message Edited by t.dowe on 2009-10-27 02:11 PM

[Simen]

My files was created by CodeWarrior V6.0 Special Edition.

I set PLL clock enable and oscillator is 32.768KHz.
Internal bus clock is 4Mhz.

The TBM interrupt periods are regular if PLL clock is disable.

I think that the TBM interrupt cannot run in PLL enable mode.Just for Internal bus clock 32.768KHz.

Is it right?

[Ake]

Hi,

If you look in the MC68HC908GR8 manual, Figure 21-1, it shows that the TBM is connected to the CGMXCLK signal. Then if you page back to Figure 7-1, you see the signal CGMXCLK coming out of the circuitry. It is easy to see how the signal from the OSC1 pin is connected to the CGMXCLK.

This means that the TBM is not dependant on the CPU clock CGMOUT, but is a fixed frequency.

In the TBM, the CGMOUT can be divided from 8 down to 32768, which means that the frequency can be 32768/8 down to 32768/32768 or 4086 Hz to 1 Hz.

I believe that there can be some drift in the output pulses, as the TBM design is made for lower frequencies.

If ýou are using the PLL to multiply the incoming frrequency, there will be a small amount of jitter in frequency, so perhaps what you saw was this jitter in CPU frequency and not in the TBM frequency.

The problem with the CodeWarrior software I don't understand though.

Regards,

Ake 

[Ake]

Hello again,

I got the software running but I could not get your Processor Expert to run, so I wrote a small C-program.

I then put in an IO-pin, PTB1 to go high at the beginning and go low at the end of the interrupt routine.

A second pulse was negated during each interrupt.

PTB0 was added to generate a pulse that was inverted each time the interrupt was executed.

On the oscilloscope photo you can see the the PTB0 freguency at the top.

It is about 28.25 kHz and PTB1 at the bottom toggling at 52.57 kHz.

Yes you are right, there is a quite large amount of jitter , < 5 uS or 5 uS* 28.25 kHz = 14 %, on the interrupt timing which shows on the top and the bottom traces.

This is jitter only, there is not long time error introduced.

I think that the reason is because the Timebase is built by a ripple-though counter which gives the jitter. See MC68HC908GR8, Figure 21-1.

The counter is not guaranteed to run at > 32 kHz, See section 21.2, which is far below the 2.3 MHz the ICS08GR is running at.

The error would probalby be reduced to 32 kHz/2.3 MHz * 14% = 0.2 %.

But it is not possible to get a 32 kHz clock that runs so 28 kHz can be measured. The fastest TBM clock is 4.096 kHz.

Regards,

Ake

[mke_et]

My first question is to ask you to define what you mean by 'not regular'.

I didn't look at your code, but I have seen complaints from people about interrupts in general not being accurate with all kinds of processors. Usually, when trying to track it down, it's simple things that cause the problem.

The big misconception... Interrupts are NOT guaranteed to be precise time markers. Ok, let me rephrase that. The EVENT can be a precise time marker, but when the interrupt actually occurs and is serviced is not. I had a friend trying to generate a voice from a data stream using an interrupt, and it mostly worked. Mostly. What was wrong? He forget that the interrupt he was using to try to stream D2A data could get held off by other interrupts. His voice interrupt would eventually get serviced, but the delay caused unacceptable distortion in the voice.

You can control this to some extent, but you can't fix it 100% unless you make sure
that the interrupt in question is the ONLY interrupt running, and that you never put the machine into a state with disabled interrupts. Even then, interrupts happen at the slice between instructions, and can be held off until the completion, which, on some processors can be quite variable.

[Ake]

Hi,

I thought I would try to see if I could help you, so I loaded your files into my CodeWarrior 6.0.

But it seemed to be incompatible.

How have you created your files?

Regards,

Ake