Initialized variable at specific location optimized out?

[RAltm]

Hi,

I need to place a initialized variable at the beginning of RAM. This variable won't be read or modified by the application, it's only read by the ST-Link during programming operation.

So I modified the linker script by adding a section PRJINFO (project info):

 /* Initialized data sections goes into RAM, load LMA copy after code */
 .data : 
 {
 . = ALIGN(4);
 _sdata = .; /* create a global symbol at data start */
 KEEP(*(.PRJINFO*)) /* project information */
 . = 0x20;
 *(.data) /* .data sections */
 *(.data*) /* .data* sections */
 
 . = ALIGN(4);
 _edata = .; /* define a global symbol at data end */
 } >RAM AT> FLASH

This area is 32 byte in size and the linker shouldn't throw away this section. I created a C file which contains a 32-byte array containing some information:

uint8_t ProjectProgramVersion[32] __attribute__((section(".PRJINFO"), used)) = {
		(PRJ_SW_VER >> 20) & 0xFF,
		(PRJ_SW_VER >> 28) & 0x0F,
		(PRJ_SW_VER >> 12) & 0xFF,
		(PRJ_SW_VER >> 8) & 0x0F,
		(PRJ_SW_VER) & 0xFF,
		(PRJ_SW_VER_INDEV) * 0x0E
};

This should place this array in the project info section, optimizing out should be prevented by linker (KEEP keyword) and compiler (attribute used). However, it only works in the debug build. Linking the release build gives garbage when reading out the memory locations.

Any ideas what might go wrong?

Regards

[Ozone]

The usual way to prevent this is to declare such variables as volatile.

Not sure about TrueStudio, though.

[RAltm]

Hi Ozone,

also added volatile keyword, but it doesn't help. According to map file, the space is reserved in both builds. But it seems that in release build, the initialization fails.

Regards

[Ozone]

What does the map file say ?

I don't quite understand the code anyway.

Since it is initialized data, it is kept in the Flash area (constants) anyway, and copied to RAM in the startup code.

Why not leaving it as "const", in the Flash area ?

[RAltm]

Hi Ozone,

this is an excerpt of map file from debug build:

 *(.PRJINFO*)
 .PRJINFO 0x20000000 0x20 Src\ProjectInfo.o
 0x20000000 ProjectProgramVersion
 0x00000020 . = 0x20

The release build shows nearly the same, except of that the path is temp directory of the user and the file name is something cryptic. But that's also true for other sections like .data, .rodata, etc. So I assume it's okay and caused by missing debug information/symbols.

Regarding leaving it as const in flash, it's because I want to use RDP level 1 and therefore only SRAM can be read by ST-Link, but not flash. I forgot the mention that, sorry.

Regards

[Bob S]

I'm not sure how the linker/startup code handles initialized RAM variables that are not in .data sections. Can you show more of the surrounding lines from the MAP file, including the start of the .data section that should also show the "load address".

Or... how about simply changing the start of RAM from 0x20000000 to 0x20000020, then at the start of main(), manually copy the data into 0x20000000?

[S.Ma]

I would not create a new segment in the linker file, I would just reduce the range to exclude the 32 bytes.

Then, I create a pointer which value will be the address of the 32 byte structure.

If you need intial values, just do a mem copy from a const to the pointed value.

That should work with any toolchain and avoid pragmas and macros.

If your pointer points wrongly to a non existant area, you'll get exception anyway... the HW will make sure.

[Bob S]

Like i said :smiling_face_with_smiling_eyes:

[Pavel A.]

Have you tried to actually reference this data from main() ?

-- pa

[waclawek.jan]

> Linking the release build gives garbage when reading out the memory locations.

What sort of garbage? Are you sure it's not compiled correctly, i.e. isn't the problem at the source side? Incorrectly defined macros or whatever is in those initializers?

If in mapfile you see the section allocated then the linker did not discard it. You may also try to have the compiler generated the "intermediate" assembler source and look at that.

JW

[RAltm]

Hi together,

thank you for your suggestions.

Just an update: currently, it seems that the section, etc. is working also in the release build, but a power cycle is needed. After power cycle, I get the expected results. The power cycle is not needed when downloading the debug build.

Since I'm downloading with the CLI of CubeProgrammer, I've the possibility to apply reset, etc. Interestingly, no combination of connection mode (under reset, hot plug, etc.) and reset mode (software/hardware reset) enables me to get rid of the power cycle. I'd expect that a hardware reset by CLI would have the same effect as a power cycle regarding RAM initialization, etc, but it seems that's not the case.

The difference between the debug and release build (apartof optimization level) is that the release build sets RDP level 1. So, with this level it might be that the MCU core can't be started by the ST-Link and therefore the RAM isn't initialized. Still investigating, maybe it's enough to change the order of the CLI calls.

Regards

[Ozone]

> So, with this level it might be that the MCU core can't be started by the ST-Link and therefore the RAM isn't initialized.

RAM is usually initialized in the startup code, somewhere between the reset vector and the call to main.

This startup code is usually a project-specific copy of the toolchain's default startup template code, for easy modification.