Hi all!
I'm using CW v4.6 with HCS12...
I have a segment definition as (I only put what matters):
SEGMENTS
PAGE_EEPROM = NO_INIT 0x0400 TO 0x0FFF;
END
PLACEMENT
EEPROM_DATA_PAGE INTO PAGE_EEPROM;
END
Normally, I define a 32bits EEPROM variable as:
#pragma CONST_SEG EEPROM_DATA_PAGE
const dword EEPROM_VARS1;
#pragma CONST_SEG DEFAULT
But as my project grows and so does those variables, the compiler place them wherever it wants, as long as they remain inside 0x0400 - 0x0FFF.
Now I want them to be at a fixed location so they "stay on the same place" with different firmware revisions.
What I did was:
#pragma CONST_SEG EEPROM_DATA_PAGE
const dword EEPROM_VARS1 @0x400;
#pragma CONST_SEG DEFAULT
Then, looking at the .map I can see that:
EEPROM_VARS2 2000 4 4 4 EEPROM_DATA_PAGE
EEPROM_VARS1 2004 4 4 3 .abs_section_2004
Why EEPROM_VARS1 isn't in EEPROM_DATA_PAGE? I mean, it phisically is there, but when I want to check where is each variable this doesn't help me
Maybe I should do the declaration other way.
Thanks!
Solved! Go to Solution.
0x2000 vs 0x400 mismatch is weird. Is it the same with CW5.x?
Do you mean you want to see @-variable in the same section? EEPROM_DATA_PAGE instead of .abs_section_xxx? I think this is not possible. @ forces linker to place object at specific address, ignoring current const/var placement. As a result small .abs_section_XXX section is generated and you see it in map file.
Do you define EEPROM variables in different files? If so, then changing Link Order will shuffle these variables a bit. Defining them in single file may help.
Even if you define them in single file, in case some variable is not used in the code, or access routine(s) is(are) not included in execution path and optimized away, data addresses will change again. But you may use ENTRIES section in PRM file. To force linking all data from eedata.c add
eedata.c.o:*
line to ENTRIES section in PRM file. This will guarantee all vars linked and won't change their addresses until you edit eedata.c
0x2000 vs 0x400 mismatch is weird. Is it the same with CW5.x?
Do you mean you want to see @-variable in the same section? EEPROM_DATA_PAGE instead of .abs_section_xxx? I think this is not possible. @ forces linker to place object at specific address, ignoring current const/var placement. As a result small .abs_section_XXX section is generated and you see it in map file.
Do you define EEPROM variables in different files? If so, then changing Link Order will shuffle these variables a bit. Defining them in single file may help.
Even if you define them in single file, in case some variable is not used in the code, or access routine(s) is(are) not included in execution path and optimized away, data addresses will change again. But you may use ENTRIES section in PRM file. To force linking all data from eedata.c add
eedata.c.o:*
line to ENTRIES section in PRM file. This will guarantee all vars linked and won't change their addresses until you edit eedata.c
Thanks Kef!
Sorry about "0x2000 vs 0x400 mismatch is weird. Is it the same with CW5.x?" I had two projects opened (they got some variables with the same name, and I copy the .prm of one and the -map of the other... It should have been:
EEPROM_VARS2 400 4 4 4 EEPROM_DATA_PAGE
EEPROM_VARS1 404 4 4 3 .abs_section_2004
Do you mean you want to see @-variable in the same section? EEPROM_DATA_PAGE instead of .abs_section_xxx?
Yes, that was the main question. And as you said, I suppose it was not possible.
Do you define EEPROM variables in different files? If so, then changing Link Order will shuffle these variables a bit. Defining them in single file may help.
Yes, I have them in a lot of differente files. Also some project share those files.
But you may use ENTRIES section in PRM file. To force linking all data from eedata.c add
eedata.c.o:*
line to ENTRIES section in PRM file. This will guarantee all vars linked and won't change their addresses until you edit eedata.c
I didn't about about this! Thanks!
I guess I will solve the problem with the @-variable. I search those and place each variable where I want it to be.
Just to clarify a bit more, I'll explain why I asked that. We have a project which can be loaded in flash via bootloader. This project stores some user data/config in EEPROM. The bootloader don't touch EEPROM so after (re)loading code, the data/config remains untocuh.
The problem is that I notice that revision_A and revision_B of the firmware, have some of the EEPROM variables at different address so when upgrade or downgrade the data can't be correctly restore.
Thanks for helping me!
SebaS