HC08 and RAM bootloader routine

From: Marcus (starvinmarvin2004_at_hotmail.com)
Date: 08/31/04 

Date: 31 Aug 2004 08:23:08 -0700

I'm trying to build a RAM-executing routine for the HC08(AZ60A)
documented in Motorola AppNote #AN1828. Basically, you generate a
self-contained S19 file for a RAM-based message loop. This loop
contains FLASH programming routines and acts upon subsequent messages
which contain the ultimate S19 file user code.

Writing everything in C (using Cosmic compiler) I've got my initial
"maintenance" loop working fine. I then can send the LRAE (load ram
and execute) FLASH routines, via CAN messages, to the HC08 with no
problem. I then can tell it to execute from the address I specify.
Everything works fine until my RAM-based application (FLASH
programming routines) exceeds approx 300 bytes in size (which should
be no problem in my 1,024 B block). I'll try to optimize or hand code
this later, but for the time being, it shouldn't be a problem(?). Any
code located beyond that +/-300 byte point fails to respond. I've
verified that:

-nothing else uses this block of RAM and my stack is located at the
top of the other block.
-the entire LRAE application gets loaded properly - I've checked all
of the bytes and locations.
-nothing subsequently overwrites the RAM areas in question.
-if I move portions of the code around, it will begin responding as
long as that code is under the +/- 300 byte mark.

Because it is a self-contained RAM-based application, I assume I must
include startup code in order to reset the stack and heap pointers
(not sure about this). Cosmic provides a library file to reset the
stack pointer and heap pointer as well as defining a user code entry
point. I've tried both including this file and leaving it completely
out with no effect at all.

Originally, I thought the heap was running into the stack - due to the
existing user code (already programmed and running on the target)
having a much higher heap-start address. Without a reset, I thought
that might be causing a problem. However, I would think that
including that startup code to reset the heap and stack pointers would
have taken care of it.

I don't know if this is compiler-related or not. But if anyone has
any hints and/or suggestions, please let me know. I'm at a loss.

Marcus

Relevant Pages

  • Re: generic routines, to what end?
    ... almost identical code, and to endure the consequent pain of having to ... The specific routines must have the ... cases you are faced with writing clever obscure code that abstracts ... loop, and each pass through the loop outputs a new version of the ...
    (comp.lang.fortran)
  • Re: HP35s - solving functions in user programs
    ... user-programmed routines. ... wonder why the HP-35s cannot solve certain user routines just as the 34C ... => SOLVING ... Now try the same function with a loop inside: ...
    (comp.sys.hp48)
  • Re: you cant bash Microsoft enough
    ... all the regs onto the current stack on a hardware interrupt or an SWI. ... writing a set of 32 bit integer math routines and doing your own ... there needs to be a VMT for each type. ...
    (sci.electronics.design)
  • Re: Help! Bug that I can not figure out
    ... depend on exactly how the C routines are declared. ... and the callee doesn't. ... Fortran however doesn't do optional arguments like ... Hence Fortran routines pop the stack just before ...
    (comp.lang.fortran)
  • Re: Dir() question
    ... considered going with the API commands, ... If you are in a Dirloop, then another call to Dir upsets the loop ... especially in 'buried' routines. ... However, in this case the GetAttr function will work fine, although ...
    (microsoft.public.vb.general.discussion)