topic Re: 2 Sections/Segments (one in RAM, one in ROM) containing the same data (CW 5.5.1272, 9S12DP256B) in CodeWarrior for MCU

2 Sections/Segments (one in RAM, one in ROM) containing the same data (CW 5.5.1272, 9S12DP256B)

m_wohlwender — Tue, 16 Dec 2008 17:23:08 GMT

Hi,

I am trying to set up a calibration protocol (XCP over CAN) on my controller (9S12DP256B).

To be able to modify parameter data online I need a section in RAM which contains all Parameters. At system startup this RAM section must be initialized with a Section in ROM containing the same data and the same mapping. The values in the ROM section are initialized either at compile time with the init-Values used in code or with the values from the last calibration session stored from the RAM to the ROM section after reception of a special XCP-Message.

My question: How can I tell the linker to map the parameters into RAM but having the same parameters (at a location with constant offset) stored in ROM?

I tried to map the parameters to RAM and use the automatic generated .copy section but there are some problems:

* the .copy section is optimized, e.g. parameters intialized to 0 in code are not member of the .copy section

* inside the copy section there are some other variables used to init RAM-Variables

-> the whole mapping of the parameters inside the .copy section is different to the RAM section

sample Code to create/initialize parameter:

#pragma DATA_SEG CALIBRATION_CONST
const volatile unsigned char SWITCH_TEST = 1;
#pragma DATA_SEG DEFAULT

sample prm-file:

...

SECTIONS
    /* internal RAM */
    CAL_RAM = READ_WRITE 0x3C00 TO 0x3CFF;
    ...
    /* unbanked FLASH ROM */
    ROM_4000 = READ_ONLY 0x4000 TO 0x7FFF;
    ROM_C000 = READ_ONLY 0xC040 TO 0xEF6F;

...

END

PLACEMENT
    _PRESTART, STARTUP,
    ROM_VAR, STRINGS,
    VIRTUAL_TABLE_SEGMENT,
    NON_BANKED, COPY             INTO ROM_C000, ROM_4000;
    DEFAULT_RAM                        INTO RAM;
    CALIBRATION_CONST            INTO CAL_RAM;
END

STACKSIZE 0x300

Thanks for your help!

Re: 2 Sections/Segments (one in RAM, one in ROM) containing the same data (CW 5.5.1272, 9S12DP256B)

CrasyCat — Tue, 16 Dec 2008 20:50:58 GMT

Hello

In CodeWarrior for HC12 V4.7, there is an option -OnCopyDown, which tells the compiler to generate copy down information for variables initialized with 0 as well.

CrasyCat

Re: 2 Sections/Segments (one in RAM, one in ROM) containing the same data (CW 5.5.1272, 9S12DP256B)

m_wohlwender — Tue, 16 Dec 2008 21:32:40 GMT

Hi CrasyCat,

thanks for your help, I just tried the -OnCopyDown option of the Compiler, this had no influence on the mapping. I have found another option for the Linker -OCopyoff (ELF/DWARF: Do not optimise copy down), this one had the effect that all Variables/Parameters initalized to 0 are now in the .copy section.

But the main problem still is that I can not be sure that the mapping within the copy section is the same as in my RAM section because the .copy section contains more data than my CALIBRATION_CONST segment which is located to a RAM-Section. Another problem is that I cannot know where the data for my CALIBRATION_CONST section starts within the .copy section...

Do you know another posibility to create a "mirror" section? Its no problem if I have to copy the content of the ROM-Section to the RAM-Section by myself, I do not have to use the startup Code for this.

Mario

Re: 2 Sections/Segments (one in RAM, one in ROM) containing the same data (CW 5.5.1272, 9S12DP256B)

CompilerGuru — Wed, 17 Dec 2008 04:11:05 GMT

To me it sounds as if the clean solution would be to have two objects, one constant for the flash content and one of the same type allocated in RAM, possibly in a NO_INIT segment. The type could be a struct, if the data consists in mutiple parts.
The copying has to be done manually as for the linker there is nothing which combines the two objects (for structs of identical type, C supports struct assignment).

If there is one object with two addresses, then I wonder how a reference to it should resolved? I guess it should resolve to the RAM address, but I basically don't see the advantage of having the constant and the RAM incarnation bound together in the tools compared with having two objects and handling the binding in the source code.

Well, if I understand the initial request right, then have a look at the RELOCATE_TO linker directive. Usually it is used for code which has to be executed in RAM but stored in ROM/FLASH, but there is no reason why the same thing could not be used for variable/constants too. (But I think having the initialization values in a distinct objects is better, its simpler).

Daniel

Re: 2 Sections/Segments (one in RAM, one in ROM) containing the same data (CW 5.5.1272, 9S12DP256B)

m_wohlwender — Wed, 17 Dec 2008 16:58:31 GMT

Hi CompilerGuru,

I haven`t found the RELOCATE_TO directive within my linker documentation:-(

I think I will try to solve the problem within code:

1. Locate the parameters to RAM within a user segment.

2. Reserve the same space within ROM.

3. Locate space for a (CRC)-Checksum behind the ROM-area

4. The RAM-Section is initialised a system Startup with the values of the .copy section

5. If the Checksum of the ROM-area is ok then overwrite the RAM with the ROM values. If there is a CRC-Error then flash the RAM-Content (init-Values from .copy section) to the ROM-area.

With this I should have always have correct (and the latest) values for my parameters when the system is running.

The only disadvantage is that I do not have the parameter-values within the ROM-area inside of the .s19 coming from build process (calibration tools like ETAS INCA, Vector CANape... use this to be able to change parameters offline and writing them back to the .s19) but perhaps I find a possibility to get rid of this disadvantage by patching the .s19 after the build process.

Thanks for your help!

Mario