HC08 and RAM bootloader routine

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

Follow Up:  It's definitely going crazy after it reaches 255 bytes in
length.  What it is about executing this in an empty and unused 1024
byte RAM block that's preventing it from continuing code execution
past 255 bytes?

Thx for any thoughts.



starvinmarvin2004@hotmail.com (Marcus) wrote in message news:<e3f5dd5f.0408310723.351d470c@posting.google.com>...
> 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

Never mind.  I was being a complete idiot.  Just needed to link this
to the RAM location with a special linker switch.  It was still
linking to ROM addresses.  Oops.