bootloader clock blues

Started by Steve Henck September 9, 2004

Hello.

I'm trying to get a bootloader based on AN153.pdf working on a device using
an MC9S12A256.

The crystal is 16Mhz and, my understanding is that I should just have to
change the OscClk definition in the bootloader code to reflect that, as
SYNRVal, FCLKDIV, etc. are calculated from the three settings.

HOWEVER, I cannot get the bootloader to work at all unless I do the following:

Set fEclock to 8000000 and execute the bootloader from the Zap debugger
using the "Animate" option. If I use the normal "run" option, I get a "lost target
synchronization" error. If I just disconnect the BDM and reset the device, I get
nothing at all over the serial port (giving the bootloader plenty of time to load
into RAM).

If I set fEclock to 8000000 and execute it with the "Animate" option, it works
fine (albiet slowly). I suspect that the "Animate" option slows things down,
having the side-effect of getting the clock rates closer to what they should
be(I'm showing my ignorance here).

I have another program (written in C) which works properly on the same
hardware and communicates over the serial port. I've tried to run this
application with Zap, then examine the various relevant registers to try to
extrapolate the correction settings for the bootloader, but have just gotten
more confused.

For the C program which works, the debugger gives the following values:

SYNR= 0x34

ECLKDiv=0x110

FCLKDIV=0x100

The only one of these I can fine which is set explicitly by the C code is
"ECLKDiv" which is set to 0x27 at startup (not 0x110)!

Unfortunately, I'm not really an embedded systems programmer and am not
much of a hardware person. This project just sort of landed in my lap, so
forgive my ignorance. Can anyone offer any assistance???

Thanks,
Steve Henck
Clinical Data, Inc.



Steve,

>For the C program which works, the debugger gives the following values:
>SYNR= 0x34
>ECLKDiv=0x110
>FCLKDIV=0x100

The above are addresses rather than initialization values:
SYNR resides at address 0x0034
ECLKDIV resides at address 0x110
FCLKDIF resides at address 0x100

I am not an expert with the Zap debugger, but you are probably looking for
the content of these registers rather than their addresses.

Hope this helps,
Doron
Nohau Corporation
HC12 In-Circuit Emulators
www.nohau.com/emul12pc.html At 01:57 10/09/2004 +0000, you wrote: >Hello.
>
>I'm trying to get a bootloader based on AN153.pdf working on a device using
>an MC9S12A256.
>
>The crystal is 16Mhz and, my understanding is that I should just have to
>change the OscClk definition in the bootloader code to reflect that, as
>SYNRVal, FCLKDIV, etc. are calculated from the three settings.
>
>HOWEVER, I cannot get the bootloader to work at all unless I do the following:
>
>Set fEclock to 8000000 and execute the bootloader from the Zap debugger
>using the "Animate" option. If I use the normal "run" option, I get a
>"lost target
>synchronization" error. If I just disconnect the BDM and reset the
>device, I get
>nothing at all over the serial port (giving the bootloader plenty of time
>to load
>into RAM).
>
>If I set fEclock to 8000000 and execute it with the "Animate" option, it
>works
>fine (albiet slowly). I suspect that the "Animate" option slows things down,
>having the side-effect of getting the clock rates closer to what they should
>be(I'm showing my ignorance here).
>
>I have another program (written in C) which works properly on the same
>hardware and communicates over the serial port. I've tried to run this
>application with Zap, then examine the various relevant registers to try to
>extrapolate the correction settings for the bootloader, but have just gotten
>more confused.
>
>For the C program which works, the debugger gives the following values:
>
>SYNR= 0x34
>
>ECLKDiv=0x110
>
>FCLKDIV=0x100
>
>The only one of these I can fine which is set explicitly by the C code is
>"ECLKDiv" which is set to 0x27 at startup (not 0x110)!
>
>Unfortunately, I'm not really an embedded systems programmer and am not
>much of a hardware person. This project just sort of landed in my lap, so
>forgive my ignorance. Can anyone offer any assistance???
>
>Thanks,
>Steve Henck
>Clinical Data, Inc.