MC9S08QG8 MTIM inconsistant IRQ timing

[paulsavage]

Hi All,

We are using the MTIM module to generate an periodic interrupt for a software loop. When I fine tune the value in the MTIMOD register to get a 10Hz IRQ it works fine. I am toggling a bit to look at the period on a scope. Without changing and code if I reflash the part the value drops from 10.1Hz to 9.66Hz.

Could some one tell us what the problem could be?

Thanks,

Paul

;            mov     #%11000011,MTIMMOD  ;load modulo counter value, do not change, 11000011 makes 10.0Hz MTIM IRQ's

;            mov     #%00010011,MTIMCLK  ;select XCLK, prescale div 4, provides 100ms MTIM TOF IRQ's

;            mov     #%01100000,MTIMSC   ;enable overflow interupts, reset and make counter active

;            cli ; enable interrupts

　 

; main loop

　 

;Standby:    wait        ;wait for 100ms modulo timer interrupt to execute Main Loop

;            bset 1,PTBD

;           lda #1

;           jsr DLYXMS

;           bclr 1,PTBD

;           bra Standby

[paul_1951]

Hi Tony,

We are using CodeWarior 16.0 and a TWR S08UNIV demo board with a QG8 daughter board.

After compiling code I open the debugger and see the trim value being loaded when the part is being flashed. The text runs by very fast but it seems as though its working.

Thanks for your help.

Paul

[tonyp]

By IRQ I suppose you mean interrupt (not the IRQ interrupt specifically).

Sounds like a trimming problem.  Using the internal oscillator is subject to trimming to get relatively accurate clock.  But, even trimming the exact same chip can use a slightly different value between two successive 'burns'.

Once you have calculated the value for the MTIMOD to produce the required frequency you shouldn't have to fine tune it.  It's fixed.  What needs 'fine-tuning' is the trim value.  But, no matter how good it is it can never be 100% as accurate as an external crystal.

[paulsavage]

Hi Tony ,

Thanks for the response. Since this error is being divided down through a seconds, minutes and hours counter chain I suspect this error will be very small when we get to the hours counter.

Question...

Will adding the following code do anything to improve the trim value, I saw it in an app note somewhere.

;************************************************************************************************

; used to trim frequency of ICS with trim value    ;

;************************************************************************************************

;        lda     $FFAE           ;get fine trim bit from flash memory

;        and     #%00000001      ;only enable the lsb, FTRIM bit

;        sta     ICSSC           ;save bit in ICS Status and Control register

;        lda     $FFAF           ;get 8 bit trim from flash memory

;        sta     ICSTRM          ;save in ICS Trim Register

Thanks for your response.

Paul

[tonyp]

Actually, you *DO* need to add this code for loading the relevant registers with the value saved in Flash by your programming tool (and, I'm assuming the option in your tool is available/enabled).

I had assumed you were already doing that.  If you don't then you're effectively not using a trim value at all (except for lucky coincidence that the default of $80 is the right value).

So, it's not a question of "improving."  If you don't load the ICSTRM register with an appropriate trim value, then your part is completely off by as much as 25% (IIRC).

Based on specs, a trimmed MCU runs with as much as 0.2% deviation which, if I did the math correctly, can lead to a clock drift of up to ~172.8 seconds (~2.8 minutes) per day.  (Deviation based on temp and/or voltage can be up to 2% but I'm assuming you can keep these relatively stable.)

BTW, I think you do not need the

and

#%00000001

;only enable the lsb, FTRIM bit

because there are no other used bits in that register for QG8.

Hope this helps.

[paul_1951]

Hi Tony,

Actually Is was using this code but did not mention it. I tried it with and without it and got the same results.

So you are saying I can delete the and #%00000001 ? I missed that only the lsb is used.

Thanks for your help.

Paul

[tonyp]

Well then, if you get the same results with and without loading the ICSTRM register then it can only mean (or, I cannot think of anything else at the moment) you have no correct trim value saved in Flash.

Are you sure your programming tool is calculating one, and saving it in the appropriate Flash location (NVICSTRM or $FFAF)?