Locate Constant Data in Flash at Fixed Address

[Grant Bt]

Yet another question on locating data, this time fixed in flash. I want to place some main application attributes at a fixed flash location so that my bootloader can learn about the installed app. I have had partial success. (For now this is for an STM32F103, but I'm just learning so that's not for sure.)

With STM32CubeIde I have this in my main.c application code:

uint32_t const Version __attribute__((section(".AppInfo"))) = 0x12345678UL;
uint32_t const Features __attribute__((section(".AppInfo"))) = 0xDEADC0DEUL;

And in the .ld file I have added this (between .isr_vector (0x08002000) and .text:

.AppInfo 0X08003000 : 
 {
 . = ALIGN(4);
 KEEP(*(.AppInfo))
 . = ALIGN(4);
 } >FLASH

Now, while this works (I checked the .map file), I get a giant hole in my Flash usage between the vectors and where my AppInfo goes. Then of course the .text begins after.

  

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!)

[Grant Bt]

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).

[Tesla DeLorean]

I'd make it a structure to commit the ordering, content, and __attribute__ it into the carved out AppInfo section.

[TDK]

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.

[alister]

>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

[Grant Bt]

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.

[Piranha]

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.

[Grant Bt]

This is a very interesting idea! I assume you mean the "Reserved" ones from the table below (found in startup_stm32f103xb.s for example)? I would prefer it said "Unused" rather than "Reserved" though. :smiling_face_with_smiling_eyes: Alternatively one could choose a vector in the silicon vendor section after, but I'm not experienced enough to know how stable those are from variant to variant.

; Vector Table Mapped to Address 0 at Reset
 AREA RESET, DATA, READONLY
 EXPORT __Vectors
 EXPORT __Vectors_End
 EXPORT __Vectors_Size
 
__Vectors DCD __initial_sp ; Top of Stack
 DCD Reset_Handler ; Reset Handler
 DCD NMI_Handler ; NMI Handler
 DCD HardFault_Handler ; Hard Fault Handler
 DCD MemManage_Handler ; MPU Fault Handler
 DCD BusFault_Handler ; Bus Fault Handler
 DCD UsageFault_Handler ; Usage Fault Handler
 DCD 0 ; Reserved
 DCD 0 ; Reserved
 DCD 0 ; Reserved
 DCD 0 ; Reserved
 DCD SVC_Handler ; SVCall Handler
 DCD DebugMon_Handler ; Debug Monitor Handler
 DCD 0 ; Reserved
 DCD PendSV_Handler ; PendSV Handler
 DCD SysTick_Handler ; SysTick Handler
 
 ; External Interrupts
 DCD WWDG_IRQHandler ; Window Watchdog
 DCD PVD_IRQHandler ; PVD through EXTI Line detect
 DCD TAMPER_IRQHandler ; Tamper
 DCD RTC_IRQHandler ; RTC
 DCD FLASH_IRQHandler ; Flash
 DCD RCC_IRQHandler ; RCC
 DCD EXTI0_IRQHandler ; EXTI Line 0