Locate Constant Data in Flash at Fixed Address

For comparison, here is what I am doing in Keil (I build in both for now).

uint32_t const Version __attribute__((at(0X08003000UL))) = 0x12345678UL; // Compiler v5
uint32_t const Features __attribute__((at(0X08003004UL))) = 0xDEADC0DEUL; // Compiler v5

And that's all I've had to do (surprisingly).

The GCC Linker, which is used by STM32CubeIDE, has no way of doing this in a similar fashion to Keil.

The vector table length won't change unless you change chips. Seems like a fine place. It won't grow by a lot, in any case, so having a bit of buffer for the vector table and placing your structure right after that seems like a fine solution.

Another solution is to place things like this in unused spaces within the vector table. Technically not allowed, but it works. Would also be chip dependent.

>There is no way to have the linker mix this into the .text area? I would like to have control over where the AppInfo goes, so any suggestions? Should I just pick the next boundary after the ISR Vectors and hope that table never grows? (seems like not a brilliant idea!)

The data is for the boot code to interrogate. You could put it anywhere. But you want the boot to find it at some fixed start address and you want it to be simple.

Placing it in the middle of the .text section is not sensible because of its unnecessary impacts.

You could make it the first input section of the .text section, if you want to. But placing it immediately following the vector table is more sensible as it is better to read and to administer.

Putting it in the vector table is sensible too, so long as it is after any vectors you'd use.

Its length may change with no trouble. Whether that's because it is variable length and the boot code would know how to parse it, or that's because you may need to add details in some backwards compatible fashion in future, the linking takes care of that.

Your C definition

const char myData[] __attribute__ ((section ("MY_SECTION"))) = "the data";

Your linker command file:

<snip>
 
SECTIONS
{
 .isr_vector :
 {
 KEEP(*(.isr_vector))
 } >APP_VECTOR
 
 MY_SECTION :
 {
 KEEP(*(MY_SECTION))
 } >APP_ROM
 
 .text : ALIGN(4)
 {
 *(.text*)
 
 <snip>
 
 } >APP_ROM
 
<snip>

https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attributes.html#index-section-variable-attribute

https://sourceware.org/binutils/docs/ld/MEMORY.html#MEMORY

https://sourceware.org/binutils/docs/ld/SECTIONS.html#SECTIONS

Thanks gang! As mentioned I need to establish the address for all time, so I will place it after the vectors as recommended. I will also allow (waste) a bit of space between the vectors and my section in case the vector table size changes due to a micro part change. It may be that F103 is not suitable (I'm only using it due to the wealth of educational materials available). I may switch to F4 or newer G0 or L0 part or other.

If I end up using the Keil tools, then this question is moot.

You can combine both methods. Put your constant data immediately after the vector table and put an address to that location in an unused slot of vector table. There are 5 unused slots between the first 16, which will be the same for almost all Cortex-M CPUs. Linker script can do all of it automatically.