I am using CubiIDE with an STM32 and trying to put constant data in an own section at the end of the flash memory. But it does not work. The value is stored somewhere after the vectortable and at 0x8003000 as well.

[Nickelgrass]

So in my linker filer I put

MEMORY
{
  RAM    (xrw)    	: ORIGIN = 0x20000000					, LENGTH = 4K
  ROM    (rx)    	: ORIGIN = 0x8000000					, LENGTH = 12K
  DAT	 (r)		: ORIGIN = 0x8000000+12K				, LENGTH = 4K
}
 
/* Sections */
SECTIONS
{
  /* The startup code into "ROM" Rom type memory */
  .isr_vector :
  {
    . = ALIGN(4);
    KEEP(*(.isr_vector)) /* Startup code */
    . = ALIGN(4);
  } >ROM
 
  /* The program code and other data into "ROM" Rom type memory */
  .text :
  {
    . = ALIGN(4);
    *(.text)           /* .text sections (code) */
    *(.text*)          /* .text* sections (code) */
    *(.glue_7)         /* glue arm to thumb code */
    *(.glue_7t)        /* glue thumb to arm code */
    *(.eh_frame)
 
    KEEP (*(.init))
    KEEP (*(.fini))
 
    . = ALIGN(4);
    _etext = .;        /* define a global symbols at end of code */
  } >ROM
 
	.udata :
	{
		. = ALIGN(4);
		_udata = .;
		*(.udata)
		*(.udata*)
		. = ALIGN(4);
		KEEP (*(.udata))
	} >DAT
}

And then in the code const uint32_t data __attribute__ ((section(".udata"))) = 0x1234;

So how can I get the variable to be stored only in 0x8003000?

[S.Ma]

I think in C there is a coding way to hardcode the memory placement. In IAR the linker config file enablre creation of segments named and #pragma in the source code for the linker to place data where you unusually need them to be.

[gbm]

What you observe might actually be a correct behavior. First, check if the value appears in an init section or somewhere within the code. If it appears in the code - the compiler may optimize access to a constant by using its value instead of referring to it as data. In such a case, maybe using volatile specifier for it would remove the optimization.

[Nickelgrass]

Thanks for the replies. It works now, although I dont 100% know why. I think it did have to do with compiler optimization. I tried so much that I lost track of what it was in the end. :dizzy_face:

[Tesla DeLorean]

Perhaps look at what startup.s is doing with regard to the initialization, and the .MAP file as to where the linker places things. Might want to contrast behaviour there with/without optimization.