Exercises — Linker scripts — memory regions, sections (.text, .data, .bss)

• (a) .data — initialized to a non-zero value, so the value $42$ must be stored (in Flash) and copied to RAM.
• (b) .bss — a global with no initializer is implicitly zero, so it goes to .bss (only its size is recorded).
• (c) .rodata — const data is read-only, kept in Flash.
• (d) .text — machine code always lives in Flash and executes there.
• (e) .bss — this is the trap. It's initialized to 0, and zero-initialized data is .bss, not .data (storing zeros in Flash would be wasteful). See mistake below.

• ADDR(.data) → the VMA (run address, in RAM).
• LOADADDR(.data) → the LMA (load address, in Flash, where the init values physically sit).
• SIZEOF(.data) → the number of bytes in .data.

Memory hook from the parent: Data Doubles — two addresses. On Figure 1 these are the two amber blocks.

(a) Flash image. The image must physically contain everything that survives power-off: code, read-only constants, and the initial values of .data (its LMA copy — the amber Flash block in Figure 1). .bss contributes nothing to Flash. $\text{Flash}=12000+2048+500=14548\text{ bytes}$ (b) RAM. Static RAM holds .data (once copied) plus .bss: $\text{RAM}=500+4096=4596\text{ bytes}$ Note .data is counted in both budgets — it has two homes, exactly the LMA/VMA idea.

Recall the location counter . (defined at the top): it is the cursor that starts at a region's ORIGIN and advances by each section's size. In Flash it starts at $O_{FLASH}=\text{0x08000000}$. (a) After .text (0x2FEC bytes) is placed, the cursor has advanced by 0x2FEC, so .data loads there: $\text{LOADADDR(.data)}=\text{0x08000000}+\text{0x2FEC}=\text{0x08002FEC}$ (b) After .data (0x200 bytes) the cursor advances again: $\text{0x08002FEC}+\text{0x200}=\text{0x080031EC}$

The pointers are uint32_t*, so q++ advances by 4 bytes each iteration (one word per arrow in Figure 2). (a) Byte span in RAM $=\text{0x20000010}-\text{0x20000000}=\text{0x10}=16$ bytes. Words: $16/4=4\text{ words}$ (b) The Flash pointer p starts at 0x08002FEC and also steps by 4: $\text{0x08002FEC},\text{0x08002FF0},\text{0x08002FF4},\text{0x08002FF8}$ (four reads, matching four writes to 0x20000000, 04, 08, 0C — the four arrows in Figure 2).

1. Garbage collection deletes any section not referenced by a symbol to save Flash.
2. The .isr_vector section (the vector table) is never called by name in C — the CPU reads it by hardware convention from the base of Flash. The linker sees no reference.
3. So GC drops .isr_vector. Now the first bytes of Flash are whatever section landed there instead (or padding).
4. On reset the CPU loads the initial stack pointer and Reset_Handler address from the (now missing) vector table → garbage addresses → immediate hard fault. KEEP() tells the linker "pretend this is referenced; never collect it."

To honour "vector table, then .text, then .rodata" as distinct, ordered sections, we give each its own output section rather than folding .rodata into .text. Their order in the file is the order they are placed in Flash.

MEMORY
{
  FLASH (rx)  : ORIGIN = 0x08000000, LENGTH = 256K
  RAM   (rwx) : ORIGIN = 0x20000000, LENGTH = 64K
}
 
SECTIONS
{
  .isr_vector : {
    . = ALIGN(4);
    KEEP(*(.isr_vector))   /* vector table FIRST; KEEP survives GC */
    . = ALIGN(4);
  } > FLASH
 
  .text : {
    . = ALIGN(4);
    *(.text*)              /* machine code */
    . = ALIGN(4);
  } > FLASH
 
  .rodata : {
    . = ALIGN(4);
    *(.rodata*)            /* read-only constants, kept separate */
    . = ALIGN(4);
  } > FLASH
 
  _sidata = LOADADDR(.data);   /* Flash source of init values (LMA) */
  .data : {
    . = ALIGN(4);
    _sdata = .;                /* RAM run start (VMA) */
    *(.data*)
    . = ALIGN(4);
    _edata = .;                /* RAM run end */
  } > RAM AT> FLASH            /* VMA in RAM, LMA in Flash */
 
  .bss : {
    . = ALIGN(4);
    _sbss = .;
    *(.bss*)
    *(COMMON)
    . = ALIGN(4);
    _ebss = .;
  } > RAM                      /* no AT>: nothing to load, just zeroed */
}

Every choice justified: .isr_vector, .text, .rodata are three separate output sections in the requested order (matching the prompt exactly); KEEP protects the table (Ex 3.2); ALIGN(4) keeps every boundary word-aligned so the copy loop is legal; AT> FLASH gives .data two addresses (Ex 2.2); .bss has no AT> because it's zeroed at boot, not copied.

(a)

• _sidata = LOADADDR(.data) = the Flash cursor after the three code sections = $O_{FLASH}+\text{0x3000}=\text{0x08003000}$.
• _sdata = ADDR(.data) = the RAM cursor at the start of .data. .data is first in RAM, so it equals $O_{RAM}=\text{0x20000000}$.
• _edata: why _edata = _sdata + 0x40? In the script _sdata is stamped from . before *(.data*) and _edata is stamped after, so _edata - _sdata is exactly the bytes the cursor advanced — that is SIZEOF(.data) = 0x40. Hence: $\text{\_edata}=\text{\_sdata}+\text{SIZEOF(.data)}=\text{0x20000000}+\text{0x40}=\text{0x20000040}$

(b) Flash image $=\text{0x3000}+\text{0x40}=\text{0x3040}=12352$ bytes. Region size $=256\times 1024=262144$ bytes. Since $12352\le 262144$, it fits comfortably.

(a) Total RAM demand: $8\text{K}+20\text{K}+8\text{K}+16\text{K}+4\text{K}=56\text{K}$ $56\text{K}\le 64\text{K}$, so it fits. (b) Leftover: $64-56=8\text{K}=8192\text{ bytes}$ (c) Doubling the heap adds $16\text{K}$, giving $56+16=72\text{K}>64\text{K}$ → overflow by 8K. The linker would emit a "region RAM overflowed" error. Cheapest fixes that keep functionality:

• Move truly constant data out of RAM into .rodata (Flash) if any was mistakenly in RAM — frees RAM at no cost.
• Or, if the 32K heap is genuinely required, no software trick creates RAM: you must pick a chip with more RAM. But the cheapest software-only move is to reclaim the 8K slack + shrink an over-provisioned stack/DMA buffer if measurements allow. There is no free lunch — RAM is a hard physical limit ($L_{RAM}$).

Why the invariant holds. .data occupies one contiguous block. In RAM it spans _sdata … _edata, so its size is $\text{\_edata}-\text{\_sdata}$. In Flash the same bytes are mirrored starting at _sidata (the left–right amber twins in Figure 1, the mirror in Figure 2). Since the copy is byte-for-byte, the Flash mirror must span an identical number of bytes, i.e. from _sidata to _sidata + (\_edata - \_sdata). If these two sizes disagreed, either some init values would never be copied or the loop would read past the mirror. The linker guarantees equality because both are computed from the same SIZEOF(.data).

Word count. With uint32_t (4-byte) pointers: $N_{words}=\frac{\text{\_edata}-\text{\_sdata}}{4}$ assuming .data is 4-byte aligned and a multiple of 4 in size (guaranteed by the ALIGN(4) directives in Ex 4.1). For the numbers of Ex 4.2, $\text{0x40}/4=16$ words.

Flash image counts .text + .rodata + .data; RAM counts .data + .bss + stack + heap. .data appears in both because it has two addresses (LMA in Flash, VMA in RAM).