HC12: How to minimize amount of code in non-banked rom

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

HC12: How to minimize amount of code in non-banked rom

1,940 Views
AndersJ
Contributor IV
From my understanding of how CW 3.1 for HCS12 locates memory segments,
I believe that at least the following segments end up in non-banked rom.
 
* Vector table
* Startup code
* Startup code data structure
* Arithmetic run-time functions
* Constants, declared with CONST
* Autoinitialized variables
 
What do I need to do to make sure most of these, if not all,
 (OK I give up on the vectortable)
are located in banked memory of my choice?
 
I need this to be able to upload a new version of the running program
to a free memory bank, without crashing the already running program.
 
Then at my convenience:
* I will reprogram a "pointer to firmware to run after reset"
* Cause a COP timeout to reset
After the reset, the new version will run, effectively swapping to a updated
program after only a 1 second downtime.
 
This entire concept seems impossible due to the fact that CW 3.1
always puts the above mentioned memory segments in non-banked memory,
which prevents the "new version" from being uploaded since it
needs memory that is in use by the already running program.
 
After being in contact with Freescale support I have been told that CW 4.5
has an option to select a "minimal startup routine", that will minimize the
amount of code placed in non-banked memory, but it will not remove everything.
 
All comments and advice are very much appreciated.
 
Thanks,
Anders J

Message Edited by CrasyCat on 2007-04-13 01:40 PM

Labels (1)
Tags (1)
0 Kudos
2 Replies

516 Views
Lundin
Senior Contributor IV
CW places the memory segments where you tell it to place them. Check out the .prm file. RTFM for details.

To be able to burn flash while a program is running elsewhere in the flash, you need to use a S12 derivate with more than one 64k block, since you can't execute code from the same block you are programming. For example, it works with Dx128 or larger, but it doesn't work with any member of the C family since it uses one block only. Depending on the size of your program, you may or may not be able to burn it in less than a second. Also, don't forget to add some kind of validation of the program, since you may get power down / external reset during programming.

Minimal startup skips the initialization of static and global variables. Personally, I think that startup12.c is one big compiler-switch mess and does nothing useful, so I don't use static initialization of my variables and skip the startup code. I write my own reset ISR where I set the stack pointer etc then call main() from there.

516 Views
sjmelnikoff
Contributor III


Lundin wrote:
To be able to burn flash while a program is running elsewhere in the flash, you need to use a S12 derivate with more than one 64k block, since you can't execute code from the same block you are programming. For example, it works with Dx128 or larger, but it doesn't work with any member of the C family since it uses one block only.

Yes it does! True, you can't execute code from a flash block which is being programmed - which is why you copy some or all of your bootloader into RAM, and run it from there instead.
 
With regard to lack of space in non-banked flash, constants and interrupt vectors do need to be there, as they are pointed to by 16-bit pointers (so a bank cannot be specified). However, you can partition this space into an area used by the bootloader, and an area used by your main program.
 
There are also some clever tricks you can do to place constants in banked flash, using a special function in the same bank to read them.
 
I strongly suggest that both of you read the various app notes about how to write a bootloader.
 
Steve M.