Hello,
I am trying to generate a hex file that places 0s in all unused bytes of my defined execution regions. I am having a hard time figuring out how to do this and would really appreciate some guidance.
Here's my scatter file:
LR_STARTUP_CONFIG 0 0x1000 { ER_IROM0 0 0x1000{ *.o (RESET, +First) *(InRoot$$Sections) LPC2400.o(+RO) } } LR_RTOS 0x1000 0x2000{ ER_IROM1 0x1000 0x2000{ rt_*.o(+RO) } } DEFAULT_IROM 0x00003000 0x00070000 { ; load region size_region ER_IROM2 0x00003000 0x00070000 { ; load address = execution address .ANY (+RO) } RW_IRAM1 0x40000000 0x00010000 { ; RW data DF00 .ANY (+RW +ZI) } }
Specifically I want to make sure that all of the remaining bytes in ER_IROM0, ER_IROM1, ER_IROM2 are set to zero (the allocated space is more than is required by the files being placed there).
Is there a option to force the linker to fill these regions with 0s?
(I am using RV MDK 4.01, RL-ARM 4.01, ArmLink 4.0.0.524 [comes with UV4/RVMDK])
That is not necessarily a job for the linker. It's typically left to hex file post-processing.
That said, why pad with zero? Flashing already fills all unused areas with 0xff without further ado from your end. So why go out of your way to make your flashable hex files bigger?
Thanks for the quick reply.
My answer is that I am trying to structure my code so that certain portions can be edited without having to re-flash the entire ROM (for flashing over COM port). But if the hex file is continuous, the utility that I use to flash the application has checksum problems. So basically I am trying to make this structural change with my code compatible with the utility I use to flash with.
-Eric
My answer is that I am trying to structure my code so that certain portions can be edited without having to re-flash the entire ROM (for flashing over COM port)
That's grounds for creating gaps in code space, but not for filling them with a particular value.
But if the hex file is continuous, the utility that I use to flash the application has checksum problems.
If so, you're trying to go in exactly the wrong direction! Filling the gaps instead of leaving them as gaps makes your hex file exactly what you say your tool can't handle: continuous. And it's even less of a reason to insist on doing this in the linker script, rather than hex file post-processing.
And even if your hex utility needs a contiguous hex file, that's by no means a good reason to insist on zero as the fill value.
Hi,
Sorry, this was a mistake: But if the hex file is continuous, the utility that I use to flash the application has checksum problems.
It should read: But if the hex file is not continuous, the utility that I use to flash the application has checksum problems.
Why is it a bad idea to fill in these gaps? (Are you suggesting that it is a better idea to fill them in with 0xFF as this is what the flash erases too? or are you saying that it is a bad idea in general to fill in these gaps?)
Thanks for taking the time to talk with me about this. I really do appreciate your guidance.
Why is it a bad idea to fill in these gaps?
It's not necessarily a bad idea. But neither is it particularly good. But either way, the linker script is not the place to do it.
Any utility that takes hex files for input (like that flash tool you're using) really should be prepared for them being non-contiguous, out-of-order or otherwise disorganized. If your tool is broken enough not to be able to cope with such input, you can always normalize it using any of the myriad of hexfile handling tools out there (srecord at SourceForge, e.g.). But do that after you've got a hex file out of Keil.