Hi,
Is there a way to explicitly place variable initializer values in a defined flash region using scatter files?
For example, using the scatter file below,
LOAD_ROM 0x0000 0x8000 ; Name of load region (LOAD_ROM), ; Start address for load region (0x0000), ; Maximum size of load region (0x8000) { EXEC_ROM 0x0000 0x8000 ; Name of first exec region (EXEC_ROM), ; Start address for exec region (0x0000), ; Maximum size of first exec region (0x8000) { * (+RO) ; Place all code and RO data into ; this exec region } SRAM 0x10000 0x6000 ; Name of second exec region (SRAM), ; Start address of second exec region (0x10000), ; Maximum size of second exec region (0x6000) { * (+RW, +ZI) ; Place all RW and ZI data into ; this exec region } }
If I declare
int aGlobalVar = 0xDEADBEEF;
aGlobalVar will get placed in SRAM, and the initializer value 0xDEADBEEF will get placed at the end of EXEC_ROM (this seems to be the case according to my experiment).
Is there a way for me to force explicit placement of 0xDEADBEEF in a flash region?
Thanks, LJ
Just to add to the original question: After the project is compiled, if I look at the .map file, I would see an entry for aGlobalVar getting placed at some RAM address. But there wouldn't be any entry for placing 0xDEADBEEF in the flash anywhere (although we know it must live somewhere in FLASH).
Am I not looking at the right places?
The linker builds it into a static initialization table that unpacks the load region into volatile memories. The code doing the static copy is in __main and once complete jumps to your main() function.
To have a variable in ROM, that stays there, consider using "static const"
Want it at some specific address? Consider making a different load region where you shrink the current one slightly, and have the second one at the end, and then direct specific content into sections therein.
ie
LOAD_ROM 0x0000 0x7F00 { .. } CONST_ROM 0x7F00 0x0100 { .. }
We are not trying to store a const value in FLASH.
We are wondering where in FLASH are all the values used to initialize RAM variables are stored, and if it is possible to explicitly place those values in a known FLASH region.
The reason we are asking is we are seeing unexpected values getting placed in the last FLASH region we declared in the scatter file, and the values match those used to initialize some global variables.
Attaching our scatter file:
LR_IROM1 0x0001D000 0x00023000 { ; load region size_region ER_IROM1 0x0001D000 0x00004000 { ; load address = execution address *.o (RESET, +First) *(InRoot$$Sections) .ANY (+RO) } ER_BEACON_POWERSTATE_DATA 0x00021000 FIXED 0x400 { ; Power state data used by the beacon powerstate.o (+RO +RW) } ER_BEACON_TRANSMITLEVEL_DATA 0x00021400 FIXED 0x400 { ; Transmit power level of the beacon transmitpower.o (+RO +RW) } ER_BEACON_CONFIGURATION_DATA 0x00021C00 FIXED 0x400 { ; Beacon configuration beaconconfiguration.o (+RO +RW) } RW_IRAM1 0x20002200 0x00001E00 { ; RW data .ANY (+RW +ZI) } }
We are seeing unexpected values getting placed in ER_BEACON_CONFIGURATION_DATA region that clearly do not belong to beaconconfiguration.o. These values do not have an entry in the .map file, and they match values we use to initialize some global variables.
The Load Region describes where to store things, the link packs things there, and the scatter loader (__main) unpack them.
Everything you describe in LR_IROM will be packed in there end-to-end, along with a linker generated table describing where things are, and where they go.
www.keil.com/.../armlink_pge1362065953229.htm
http://www.keil.com/support/docs/3629.htm
I don't feel like our questions are answered. We have the exact same issue as described in here: www.keil.com/.../
The questioner there is using the load region entirely wrong.
Look it's not my job to train you to do your job, or perform your job.
If you don't understand the concepts of the scatter file, and the role of the linker, and startup code, it's not really my problem. Trying to point you in the right direction to find a solution to your issue, but not paid enough to do it for you, and get you past the mind-block where you insist it must do things a certain way without understanding how the mechanics actually work and the degrees of freedom you have to change things, or alter the outcome.
Feel free to Please read the manual, and understand it, and work with your Keil account manager to resolve your support issues.
View all questions in Keil forum