Device Initialisation TPM timer interrupt 9S08QG8

[stevec]

Hi, thanks to all those who've helped me so far.
Now I have got a program running I find its not doing what I expect. Basically I've set up a 1mS interrupt to toggle PB7 on my demo board and used Device Initialisation to set this up. In the interrupt I check for when 5000 interrupts have happened and toggle the o/p pin. I expect to see a toggle every 5 seconds but actually see a toggle every 54mS. I have set up the TMR in Device Initialisation as follows
Clock Settings
   Clock Source: Bus Rate Clock
   PreScaler = 1
   Modulo counter = 105c (which gives)
   Period 1mS

Interrupts
   Overflow Interrupt Enabled

PB7 was set up as o/p .

All other Bean parameters for TMR were unchanged.

What am I missing? Is there another Bean to sort out as well?

Steve

[stevec]

Ok. I've sorted it. Nothing to do with the Initialisation. Just forgot to reset the TOF in the interrupt routine, so it was continually calling the interrupt. Put it down to not having woken up yet (and not reading the manual).

Steve

[stevec]

Well I thought I'd got it sorted. However I have a toggle period of 2.8 seconds instead of the expected 1 second. The bean says I should have an interrupt period of 1mS and I'm counting 1000 of them before toggling the port pin and resetting the count. Is there an explanation for this?

Steve

[bigmac]

Hello Steve,

If you have a modulo value of 0x105C (4188 decimal), and a prescale of 1, this implies that you have a bus frequency of about 4.2MHz to achieve a 1ms overflow period.

Perhaps you could use full chip simulation to verify 4189 cycles, or thereabouts, between overflow interrupts.  If this is correct, the problem is likely to be the set up of the bus frequency.

Regards,

Mac

[stevec]

I thought the bus frequency was sorted by the trim value. I think I need a bit more understanding of the clock sources. All my other processor work has been done with devices which only had an external crytal. Made life a lot simpler (but not necessarily easier).
I haven't got round to using simulation yet.
If it is "likely to be the set up of the bus frequency", how is this rectified apart from trial and error. I shall also be using the SCI so have to get this sorted for the correct baud clock.

I've put a similar query on the CW 8/16 bit forum as I thought this thread had died. Apologies for the duplication.

Steve

[peg]

Hi Steve,

We would need to know how your clock is setup. You are presumably using the internal reference and you are presumably stepping this up to some buss frequency. If we don't know what this is, telling us the details of the timer setup is useless.

So what are you setting ICSC1 and ICSC2 to?

The error you are getting is unlikely to be just an incorrect trim.

[stevec]

Peg,
Thanks for the reply, I need to read up on all this. I thought I could rely on the Device Initialisation to sort things.
The ICSC1 is set to 0x04
ICSC2 is set to 0x40

Both set up by MCU_Init.

I'll go away and study.

Steve

[peg]

Hi Steve,

The buss frequency you are generating is 4.2MHz which is actually the power on default.

The value you are using in the TPM is correct to get 1ms.

I now see that the error you are quoting in your other post is 8% slow.

What value are you ending up with in the ICSTRM register.

It is always unclear to me exactly what frequency the BDM module and software is trying to achieve in these circumstances. Exactly 4.2MHz or 4.194304????? (2^22)

[stevec]

Am I right in assuming that the basic oscillator is 32kHz and the FLL will multiply this by 512 (if BDIV and RDIV are set to divide by 1). I make this 16MHz. Where does 4.2MHz come from?

Steve

[bigmac]

Hello Steve,

If the internal oscillator is trimmed for a value of 32.768 kHz, the DCO output from the FLL would be 16.777... MHz (512 times). 

However, the reset default value for BDIV (within ICSC2 register) is 1, giving a division of 2 for ICSOUT.  See fig. 10.2 within the data sheet.  There is a further division of the frequency by 2, to derive BUSCLK (see fig. 1.2).  This means that the default bus frequency is 32.768 * 512 / 4 = 4194.304 kHz, subject to trimming.

It is apparent that this is what PE has assumed in setting up the 1ms overflow interrupt.  If you are using BDIV = 0, either the modulo value, or timer prescale would need to be doubled.  For BDIV > 1, the modulo value would need to be reduced to maintain 1ms overflow period.

If I needed to achieve a delay of one second or more, I probably would not bother setting the modulo value to less than the default, unless there were other specific reasons for doing so.  This would give a timing granularity of 15.6ms, rather than 1ms, but would probably still be adequate in most instances for the longer time delays.  This would reduce the number of timer overflow interrupts and give more flexibility for additional use of the TPM channels for input capture or output compare.

Regards,

Mac

[stevec]

Thanks bigmac,

I really appreciate all the assistance, it's absolutely invaluable. Can I bring up a few quieries from your comments.

<If the internal oscillator is trimmed for a value of 32.768 kHz, the DCO output from the FLL would be 16.777... MHz (512 times). >
    Is this what the trim value is trying to achieve? It must have a figure  to aim for. Does the programmer measure the clock period and compute a trim figure to achieve 32.768kHz? The section on the trim registers doesn't quantify anything. Assuming a 32kHz internal clock (section 10.1.2) what effect does the lsb of the trim reg have in terms of Hz (FTRIM)?

<However, the reset default value for BDIV (within ICSC2 register) is 1, giving a division of 2 for ICSOUT.  See fig. 10.2 within the data sheet.  There is a further division of the frequency by 2, to derive BUSCLK (see fig. 1.2).  This means that the default bus frequency is 32.768 * 512 / 4 = 4194.304 kHz, subject to trimming.>
    Ok, hadn't read the datasheet close enough.

<It is apparent that this is what PE has assumed in setting up the 1ms overflow interrupt.  If you are using BDIV = 0, either the modulo value, or timer prescale would need to be doubled.  For BDIV > 1, the modulo value would need to be reduced to maintain 1ms overflow period.>
    I'm using the values that Device Initialiser determines..but I still get a 6% error. Is Device Initialiser getting it wrong       somewhere , or making assumtions about other settings that I havent initialised yet?

<If I needed to achieve a delay of one second or more, I probably would not bother setting the modulo value to less than the default, ........>
    One of the first things I get going on any new target is a 1mS tick. It gives me some confidence about the clock for any serial comms (I do a lot of serial comms). So far I'm not confident about what the baud clock will turn out to be. I certainly can't afford a 6% error.

Am I best to keep trying different trim values until I get the result I require? I'm still uncertain as to the cause of this error.

Steve

[peg]

Hi Steve,

Bigmac said "PE ia assuming" the bus frequency. I don't believe it would be, more than likely it is setting the bus frequency to what you told it or its own default, which happens to be the same as the QG default. So it is not assuming, but knowing.

Now to check it all out we only need to check the two clock setup registers.

IREFS = 1 so we use the internal clock of roughly 32k

RDIV = 000 so we divide this by 1

The FLL multiplies this by 512

CLKS = 00 so we use this output of the FLL

BDIV = 01 so we divide this by 2

now we have ICSOUT

this is again divided by 2 to produce BUSCLK

So the above gives approx 4.2MHz

But the thing that we know for sure is it is 128 times the internal clock

Now if MTIMCLK's CLKS is 00 then we use the BUSCLK above

and if PS is 0000 we divide this by zero

Now if MTIMMOD MOD is $105C, this divides the BUSCLK by 4188.

Thats it there are NO other variables or oportunities to alter it.

The value for the modulo seems a little off, I don't know why. The problem is it is off in the opposite direction than the error we are looking at.

The thing is if you truly believe what you are seeing at the output then the problem has to be the trim of the internal reference. If it s wrong, trim it till it is right!

This brings us to why the trim is wrong. Are you calculating the trim value (when you connect and programme the device) at the same voltage as when you run it? The internal reference is affected a fair bit by voltage (and temperature).

[stevec]

Peg,
Thanks for the detailed explaination. Makes things much clearer.

The modulo figure which you put suspicion on was determined by the Device Initializer.

The trim value of  A6 01 was written to flash at programming time and (presumably) determined by the P&E Multilink s/w.

I have manually set the trim value to 0x92 to get the timing right. However, I can't do this in a production environment, but will have to come up with some automatic way to set the trim value if I have to. It's just more time and effort which I hoped would be unnecessary.

I have put a Service Request in to Freescale on this topic. I hope they can come up with something. Whilst I have some keypress timers to action, they are not too time critical. It's the baud rate clock I'm concerned about for serial comms.

I am using the DEMO9S08QG8 board for this, so programming and running use the same power supply.

I have no reason to suspect my test equipment. I'm using a Tektronix digital scope and the timings are confirmed by a universal counter.

There is of course the possibility that I have made some gross error somewhere but I have only hand written about 5 lines of code (clear int flag, check count of interrupts, toggle o/p pin). All the other code for processor set up has been done via the 'beans'. However I'm only a 10 days down the road in using this processor!

Steve

[stevec]

I put this problem in as a Service Request to Freescale and had an answer today. This is what they said.

"The problem is that trimming is made to 31.25kHz (see datasheet-it is minimal Average internal reference frequency - trimmed) instead of to 32.7 (Typical Average internal reference frequency - untrimmed). But in device initialisation 32.7 kHz is used as Internal oscillator frequency. So as a workround I suggest you modify the value if internal oscillator frequency in CPU Bean to 31.25 (and then also change the modulo register settings to 0x0FA0 to obtain 1ms interval) and then it will work"

They have logged this into their bug database so it must therefore be seen as a bug and not me messing things up.

It certainly sees to work.

Comments anyone?

Steve

[peg]

Hi Steve,

This is what I was alluding to back in my second post.

It seems that P&E's and Unis' interpretation of this unclear point in the datasheet are different.

They don't tell you what the 'desired' frequency of the internal oscillator is.

[peg]

Woops, edit time has expired!

In the previous post:

MTIMCLK PS = 0000 is divide by one (divide by zero would create some havoc)

[stevec]

Just measured waveform again. Its actually 1.06mS so 6% slow. I read it wrong on my scope display. I must get some glasses!!

Also realised 32kHz *512 is actually 16384kHz. I was using the lower figure of 31.25kHz as mentioned in the FEI section of the datasheet.

Steve

[stevec]

Thanks peg,

ICSTRM is loaded with 0xA6
ICSSC is loaded with 0x01

If you're confused, think what it's like for us new to this device.

Steve