Bootload Problem with MC9S12A256B

[Motoman]

I am running an application on MC9S12A256B. I am using FAR strings to store some of my strings since I have run out of RAM in the STRINGS section. Paging is enabled, so all my program code resides in the FAR memory.

To Bootload the code, I'm using a serial connection from a Visual Basic program which we designed. The Microprocessor code has Start12.cpp and another file called Bootload.cpp which will erase all the flash except the bootloader code and write the new code into the appropriate locations as specified by the linker. The location where the bootloader code resides is specified by the linker file.

Problem Description:
I have a version A.0 of the code which I loaded into the micro using the BDM. I made code changes in the logic and also added new strings in the FAR memory in addition to the already existing ones to create Version B.0.

The problem is I'm unable to bootload version A.0 to B.0 as is. However if I comment out the newly added strings in FAR memory in B.0, I am then able to bootload from A.0 to B.0. If add some dummy code instead of the new strings in B.0 I can bootload. It appears that adding new strings in FAR memory to the already exisitng ones is the inhibhiting factor which prevents the bootload. At least that is what the symptoms show.

Could anyone please provide thoughts on this? I understand my question might be vague but I hope some ideas as to the direction I can look into can help.

Thanks in advance,
Motoman

[kef]

Building common app+bootloader application, I don't know how to reliably separate bootloader part of the code (nonpaged address range, paged address range, vectors, strings, ISRs etc..) and app part of the code. So why not simplify the matter and build two separate applications: bootloader and the app with vectors in the secondary vector table? And you make your bootloader redirecting normal vectors to secondary vector table.

For debugging purposes you just build your app with interrupt vectors in their normal locations and debug as there was no bootloader. To build loadable image you use conditional compiling and recompile the app with all interrupt vectors moved to secondary vector table. If you are using CW and their interrupt N syntax, then it could look like

void interrupt (N+(bootloadersize/2)) ISR(void)

{

}

, of course if secondary vector table is in nonbanked mem just below the bootloader. The best is to write protect bootloader memory and set bootloadersize to the size of write protected region...