Data Integrity Issue with Custom .rawdata Section in Linker Script on ARM Cortex-M4

[teosssss]

I'm working on an embedded project using an **ARM Cortex-M4** processor (specifically, an `STM32F4` microcontroller) and I've encountered a peculiar issue related to memory sections defined in my linker script. I'm using the `arm-none-eabi-gcc` toolchain for compilation.

I have a binary file that I want to include in my firmware. I've created a custom section (`.rawdata`) in my assembly file to include this binary file, and I've modified my `linker script` to place this section in the `Flash` memory. However, I'm facing an issue with the integrity of the data in the .rawdata section during runtime.

When I place the `.rawdata` section within the `.data` section or in the `.text` section in my `linker script`, everything works as expected: the data is correctly allocated in memory, and the actual data is stored correctly. I can access and print the data during runtime without any issues.

However, when I try to create a standalone `.rawdata` section (outside of `.data`) or place it within the `.text` section, the data seems to be allocated, but the content is not what I expect. During runtime, when I print the content of the `.rawdata` section, I get incorrect values (not matching the original `.bin` content).
Interestingly, when I inspect the `.elf` file using `arm-none-eabi-objdump`, the `.rawdata` section appears to contain the correct data. This discrepancy only occurs during runtime.

Linker Script Snippet:

ld
.rawdata :
{
. = ALIGN(4);
_mstart = .;
KEEP(*(.rawdata))
. = ALIGN(4);
_mend = .;
} >FLASH

Why does placing the `.rawdata` section inside the `.data` section work correctly, but creating it as a standalone section leads to incorrect runtime data?
Is there a specific consideration or configuration I'm missing for custom sections in the linker script for **ARM Cortex-M4** processors?

How can I ensure that the `.rawdata` section's data remains intact during runtime when it's defined outside the .data section?

Any insights or suggestions on how to resolve this issue would be greatly appreciated. Thank you in advance for your help!

[Tesla DeLorean]

The .LD is also order dependent, needs to be up-front, not after the .BSS sections, and not before vectors

[teosssss]

Im aware of the order dependency of the linker script, and I have tried to put .rawdata after .text in flash and still it does have different values from the values that should be in the .rawdata only at runtime

[Tesla DeLorean]

If the .ELF file is correctly constructed and the content correct there, then the issue is either with your programming tool, or the way you're reading/inspecting the memory.

You could use objcopy to make a .BIN or .HEX and inspect that. You could view the memory written in STM32 Cube Programmer.

[teosssss]

if I check using:

arm-none-eabi-objdump -h -j .rawdata blink.elf
arm-none-eabi-objdump -s -j .rawdata blink.elf


blink.elf: file format elf32-littlearm

Sections:
Idx Name Size VMA LMA File off Algn
1 .rawdata 0000003c 080001c8 080001c8 000071dc 2**0
CONTENTS, READONLY

blink.elf: file format elf32-littlearm

Contents of section .rawdata:
80001c8 cdcccc3d cdcc4c3e 9a99993e cdcccc3e ...=..L>...>...>
80001d8 0000003f 9a99193f 3333333f cdcc4c3f ...?...?333?..L?
80001e8 6666663f 0000803f cdcc8c3f 9a99993f fff?...?...?...?
80001f8 6666a63f 3333b33f 0000c03f ff.?33.?...?

which is the correct data that should be loaded.

But if during runtime I check printing the content inside that memory area with USART I get:

data size: 60 bytes
Start address: 0x80001c8
End address: 0x8000204
00000000
00000000
3f501eb4
bfe008ee
3d600962
416277e1
c6ffe8d3
3c201ffe
40c1e8d1
41428902
c6004342
4161df76
c2000560
4161a8f3
c2000560

in which the address is the same as above but the content in memory is different.

Instead,
if I place the `.rawdata` inside `.text` or `.data` sections I get the same memory contents as it should.

[Pavel A.]

The only sure thing is that there's no miracles at all. So look for a bug in your code, such as corruption of local variables or stack.