Why does STM32CubeIDE add 96 bytes at address 0x20000000 to the firmware file when I compile?

[arnold_w]

I'm working with the STM32L4 Nucleo-64 Development Board and compiling with STM32CubeIDE 1.6.1. I have created a project using STM32CubeMX that I then imported into STM32CubeIDE. Hence, my linker script file was generated by STM32CubeIDE. Whenever I compile, my resulting (hex or binary) firmware file contains 96 bytes starting at address 0x20000000. Where do those bytes come from and what's the purpose of them?

[Bob S]

0x20000000 is RAM. Your hex file shouldn't have anything there, only code starting at 0x08000000. Nor should your binary, but how do you know this in the binary since there is no address info in the BIN file?

Look at the map file and see what is there.

Are you perhaps targeting the program to run from RAM?

[arnold_w]

I assume the first byte in the .bin-file starts at address 0x08000000 and since my .bin-file becomes 402653280 (!) bytes large (about 384 MBytes), I assume the last 96 bytes reside on address 0x20000000 and onwards. This is also consistent with what I see in STM32 ST-LINK Utility if I choose File -> Open and browse for the .hex-file.

How can I tell if I target the program to run from RAM? I want to target to run in a regular way.

[Tesla DeLorean]

Check .MAP file, and how Scatter File or Linker Script is directing content.

Typically memory is allocated in RAM, ie the statics, and stored into Flash via an "AT FLASH" type directive, and subsequently code in startup.s copies this initial data into RAM, and clears other larger areas. For Keil __main calls a scatterload function that does this initialization from a table. Arduino's GNU/GCC implementation often uses a table too, but ST's implementation is far more crude, with lots of individual symbols and duplicative code.

In some CM0(+) implementation a block at the beginning of RAM is carved out to allow a copy of the Vector Table to be moved there, and then the RAM mapped into the Zero address space.

[arnold_w]

So, I think that it's related to me "hack-creating" (through an automated script) an array at address 0x20000000 with pin assignment information:

/* Memories definition */
MEMORY
{
 RAM_BLUE_BUTTON_PIN (xrw) : ORIGIN = 0x20000000, LENGTH = 8
 RAM_USART_Tx (xrw) : ORIGIN = 0x20000008, LENGTH = 8
 RAM_USART_Rx (xrw) : ORIGIN = 0x20000010, LENGTH = 8
 .
 .
 
 
/* Sections */
SECTIONS
{
 .blue_button_pin : ALIGN(4)
 {
 KEEP(*(.blue_button_pin))
 *(.blue_button_pin .blue_button_pin.*)
 } >RAM_BLUE_BUTTON_PIN
 
 .usart_tx : ALIGN(4)
 {
 KEEP(*(.usart_tx))
 *(.usart_tx .usart_tx.*)
 } >RAM_USART_Tx
 
 .usart_rx : ALIGN(4)
 {
 KEEP(*(.usart_rx))
 *(.usart_rx .usart_rx.*)
 } >RAM_USART_Rx
 .
 .
 
 
typedef struct {
 GPIO_TypeDef * port;
 uint16_t pin;
 uint8_t pinPosition;
} pinSpec_t;
 
typedef enum {
 BLUE_BUTTON_PIN_ = 0,
 USART_Tx_ = 1,
 USART_Rx_ = 2,
 NUM_TOTAL_PINS = 3
} allPins_e;
 
__attribute__ ((__section__(".blue_button_pin"),used)) pinSpec_t BLUE_BUTTON_PIN;
__attribute__ ((__section__(".usart_tx"),used)) pinSpec_t USART_Tx;
__attribute__ ((__section__(".usart_rx"),used)) pinSpec_t USART_Rx;
 
void initializeCommonPins(void) {
 const defaultPinConfig_s DEFAULT_PIN_CONFIG[] = {
 {BLUE_BUTTON_PIN_, GPIOC_, 13, GPIO_MODE_INPUT, GPIO_NOPULL, GPIO_SPEED_LOW, 0 , INITIALLY_UNDEFINED_PIN_STATE}, // PC13
 {USART_Tx_ , GPIOA_, 9 , GPIO_MODE_AF_PP, GPIO_NOPULL, GPIO_SPEED_LOW, GPIO_AF7_USART1, INITIALLY_LOW }, // PA9
 {USART_Rx_ , GPIOA_, 10, GPIO_MODE_AF_PP, GPIO_NOPULL, GPIO_SPEED_LOW, GPIO_AF7_USART1, INITIALLY_LOW }, // PA10
 };
 
 initializePins(DEFAULT_PIN_CONFIG, (uint16_t) sizeof(DEFAULT_PIN_CONFIG)/sizeof(DEFAULT_PIN_CONFIG[0]));
 
 PC_APP_UART = USART1;
}

Does it make sense that this would end in the firmware files (.hex and .bin files)? And this leads to a follow-up question, am I creating a conflict in the beginning of RAM by doing this?

[Javier1]

You could share with us your compiled .bin file

[arnold_w]

But it's 384 MBytes...

[Javier1]

jeeeeesus

[Pavel A.]

> So, I think that it's related to me "hack-creating"

Yes. Many woes are self-inflicted.

[arnold_w]

Can I somehow edit the code below so that 8 bytes is still reserved in RAM, but it's not included in the .hex/.bin-file?

.blue_button_pin : ALIGN(4)
 {
 KEEP(*(.blue_button_pin))
 *(.blue_button_pin .blue_button_pin.*)
 } >RAM_BLUE_BUTTON_PIN

I tried to remove the KEEP keyword, but that didn't help.

[Pavel A.]

Add NOLOAD.

blue_button_pin (NOLOAD) : ALIGN(4)