Linker scripts and sections

The file that decides where .text, .rodata, .data and .bss go in Flash and RAM. How to read it together with the map file.

Sections

Where the pieces of a program go. The initial values of .data sit in Flash and are copied to RAM at start-up.

Section	Contents	Location
.isr_vector	Vector table	Very start of Flash
.text	Code	Flash
.rodata	const data, strings	Flash
.data	Globals with an initial value	RAM (initial values in Flash)
.bss	Globals without an initial value	RAM
Stack, heap		RAM

Linker script (.ld)

MEMORY {
  FLASH (rx)  : ORIGIN = 0x08000000, LENGTH = 512K
  RAM   (rwx) : ORIGIN = 0x20000000, LENGTH = 128K
}
SECTIONS {
  .text : { *(.isr_vector) *(.text*) *(.rodata*) } > FLASH
  .data : { *(.data*) } > RAM AT > FLASH
  .bss  : { *(.bss*) } > RAM
}

> RAM AT > FLASH means ".data lives in RAM at run time, but its initial values are stored in Flash".

RoadmapSee where this note sits in Machine Code & Assembly→

When you edit it

Moving the application's FLASH ORIGIN when splitting bootloader and application
Placing fast functions in RAM or CCM: __attribute__((section(".ramfunc")))
Keeping a Flash sector for stored settings out of the code area

Map file

The .map file from the build shows the address and size of every function and variable. When Flash runs short, look for the largest items in the map file. Floating-point support in printf commonly takes tens of KB.