I am writing a C program that will be loaded into flash memory while the target device is already running; in other words, this C program is NOT run immediately out of reset.
I need to modify the startup.s file to provide the following layout when linked with my C code:
Start of module: ValFlag, a 4-byte validity flag at start of the module, Branch instruction to module execution address, Header, a 256-byte empty area of memory (starts at ValFlag+0x10), Execution address and remainder of code.
I'm having problems generating the Header area. I can't figure out how to force the assembler/linker to leave a gap at exactly that address range. The linker must not generate ANY hex records for this area of memory. This area will be overwritten later with custom hex records containing info such as CRC, copyright, etc.
I suspect this is normally done with the scatter file, but I really want to avoid that. I would prefer having the IDE generate the scatter file from the target options settings, to minimize the chance for errors should someone need to move this module to another area in the target device's memory.
Karl
Hi Karl
> I'm having problems generating the Header area. I can't figure out > how to force the assembler/linker to leave a gap at exactly that > address range.
infocenter.arm.com/.../Cacgadfj.html
> The linker must not generate ANY hex records for this area of > memory. This area will be overwritten later with custom hex records > containing info such as CRC, copyright, etc.
What do you mean by that? You cannot create space that is completely empty unless you specify data addresses in the output file, too. Why are you so concerned about this when data in those "empty" regions will be overwritten anyway.
Regards Marcus http://www.doulos.com/arm/
Use the dialogs, and instead of specifying that you have one ROM, do specify two ROM areas. The gap between the two ROM areas will not be used, i.e. the Intel-hex file will not have any lines specifying this address range.
If you do create a binary file, then it will contain this gap, since a binary file can't have caps.
Since binary is not case-sensitive...
;-)
The danger of posting without proof-reading :)