Startup code — vector table, reset handler, stack initialization: Worked examples

Everything here builds on the parent topic. When we touch how the linker hands us addresses, that's Linker scripts and memory sections (.text .data .bss); when we touch how the CPU stacks registers, that's the ARM Cortex-M exception and interrupt model.

Before we start: the three symbols every example uses

We keep meeting three families of names. Let's pin them to a picture so no symbol is ever a mystery.

Figure — Startup code — vector table, reset handler, stack initialization

The scenario matrix

Every case class this topic can throw at you, and which worked example covers it:

#	Case class	Concrete stimulus	Example
A	Normal load — both sections non-empty	`.data` has 2 words, `.bss` has 1 word	Ex 1
B	Empty `.data` (degenerate copy)	no initialized globals → `_sdata == _edata`	Ex 2
C	Empty `.bss` (degenerate zero)	every global is initialized → `_sbss == _ebss`	Ex 2
D	Stack boundary / first push	trace MSP after entry and first `push`	Ex 3
E	Sign / direction of growth	full-descending SP, does it overflow up or down?	Ex 3
F	Collision limit — stack vs heap	how much can the stack grow before it hits `.bss`?	Ex 4
G	Relocated table (VTOR ≠ 0) — bootloader case	app's table at `0x0800_4000`, what does hardware read?	Ex 5
H	Real-world word problem	a sensor buffer as a global — where does its data come from?	Ex 6
I	Exam twist — the `.bss`-not-cleared heisenbug	predict the bug's symptom	Ex 7
J	Exam twist — misaligned `_estack`	`_estack` odd/not word-aligned, what faults?	Ex 8

We now hit every cell.

Worked example Ex 1 — Case A: the normal load, byte by byte

Setup. RAM starts at 0x2000_0000. The linker reports: _sidata = 0x0800_2000, _sdata = 0x2000_0000, _edata = 0x2000_0008, _sbss = 0x2000_0008, _ebss = 0x2000_000C. Flash at _sidata holds the two words 0x0000_002A (=42) then 0xDEAD_BEEF. After the reset handler runs, what is in RAM at 0x2000_0000 … 0x2000_000B?

Forecast: guess before reading — how many words get copied, how many get zeroed?

Count the .data words. $(_e d a t a -_s d a t a) /4 = (0 x 08) /4 = 2$ words. Why this step? The copy loop while (dst < &_edata) runs exactly until it reaches _edata; the count tells us it iterates twice.
Copy word 0. RAM[0x2000_0000] = Flash[_sidata + 0] = 0x0000_002A. Why? The n-th RAM word comes from the n-th Flash word; here $i -_s d a t a = 0$ .
Copy word 1. RAM[0x2000_0004] = Flash[_sidata + 4] = 0xDEAD_BEEF. Why? Offset into RAM $= 4$ , so offset into Flash $= 4$ from _sidata.
Count the .bss words. $(_e b ss -_s b ss) /4 = (0 x 04) /4 = 1$ word. Why? Same counting logic, now for the zeroing loop.
Zero it. RAM[0x2000_0008] = 0x0000_0000. Why? C guarantees uninitialized globals read as 0.

Verify: total bytes touched $= 2 \times 4 + 1 \times 4 = 12$ bytes $= 0 x 0 C$ , exactly _ebss - _sdata. RAM now reads 2A 00 00 00 | EF BE AD DE | 00 00 00 00 (little-endian). No gap, no overlap. ✓

Worked example Ex 2 — Cases B & C: the degenerate empty sections

Setup. A tiny program: one global const int FLAG = 1; (goes to Flash .rodata, not RAM) and no RAM globals at all. The linker collapses the sections: _sdata == _edata == _sbss == _ebss == 0x2000_0000. How many times does each loop body run?

Forecast: zero? one? crash?

.data copy loop. Condition dst < &_edata is 0x2000_0000 < 0x2000_0000 = false on entry. Why this step? A while tests before the body, so a zero-length range runs the body 0 times — no crash, no wild write.
.bss zero loop. Same: _sbss == _ebss, body runs 0 times. Why? Identical structure; empty range is safely skipped.
Consequence. MSP was still loaded by hardware, so main() is called with a working stack even though no copying happened. Why this matters? This proves the loops are self-guarding: you never need an if (count > 0) around them.

Verify: words copied $= (0) /4 = 0$ ; words zeroed $= (0) /4 = 0$ . A for-style loop with the same bounds would also run 0 times. The program is still correct. ✓

Worked example Ex 3 — Cases D & E: MSP and the first push

Setup. 20 KB RAM: 0x2000_0000 … 0x2000_4FFF, so _estack = 0x2000_5000. The CPU is full-descending (SP points at the last item used; a push first decrements by 4, then writes). Where does the first pushed word land?

Forecast: at 0x2000_5000? at 0x2000_4FFC? somewhere else?

Hardware loads MSP. Word @ 0x0000_0000 = 0x2000_5000 → MSP. Why this step? On Cortex-M the very first thing hardware does is set the stack pointer, before any code runs (see figure).
First push happens. SP $\leftarrow$ SP $- 4 = 0 x 200 0_{5} 000 - 4 = 0 x 200 0_{4} F F C$ , then the word is written there. Why decrement first? "Full-descending" means SP always points at valid data; to add new data we must first make room below by subtracting.
Direction check. Each further push subtracts 4 → addresses go down toward 0x2000_0000. Why down? So the stack and a heap growing up from the low end move toward each other, giving one predictable collision point.

Verify: the highest byte a full-descending stack ever writes is _estack - 1 = 0x2000_4FFF — the last real RAM byte, never 0x2000_5000 (which is outside RAM). Off-by-one is correct: initial value is end+1 precisely so the first subtract lands on the last valid word. ✓

Worked example Ex 4 — Case F: how far can the stack grow before collision?

Setup. Same 20 KB RAM. .data + .bss together occupy 0x2000_0000 … 0x2000_07FF (2 KB). The heap starts right after at 0x2000_0800 and (for this snapshot) is empty. _estack = 0x2000_5000. What is the maximum stack depth in bytes before it corrupts .bss/heap?

Forecast: 18 KB? 20 KB? less?

Identify the two frontiers. Stack top-of-growth reaches down from 0x2000_5000; the region below it that must stay safe ends at the top of used low memory 0x2000_0800. Why this step? A collision is exactly when the descending SP crosses into occupied low memory.
Compute the gap. $0 x 2000_5000 - 0 x 2000_0800 = 0 x 4800 = 18432$ bytes $= 18$ KB. Why subtract? The free window between "stack start" and "first occupied byte below" is the maximum descent.
Convert to entries. $18432/4 = 4608$ words of 32-bit pushes. Why /4? Each push moves SP by one word = 4 bytes.

Verify: $18 KB + 2 KB$ (data/bss/heap) $= 20$ KB $=$ total RAM. Accounts for every byte. If the linker's _Min_Stack_Size guard were set to 18 KB, this would just fit; 18 KB + 1 byte would fail the link — a clean compile-time catch instead of a silent overflow. ✓

Worked example Ex 5 — Case G: the bootloader / VTOR relocation

Setup. A bootloader lives at 0x0800_0000. It jumps to an application whose vector table is at 0x0800_4000. The app's table word 0 = 0x2000_5000, word 1 = 0x0800_4101 (Reset_Handler, LSB set for Thumb). The bootloader sets VTOR = 0x0800_4000, then triggers the app's reset path. After VTOR is set, which stack pointer and which entry point does the app use?

Forecast: does the CPU still read 0x0000_0000, or the new table?

VTOR is the table's base. VTOR (Vector Table Offset Register) tells the CPU where entry 0 lives. After VTOR = 0x0800_4000, "word 0" means [0x0800_4000]. Why this step? Without VTOR the table is fixed at 0x0000_0000; VTOR lets two independent tables (boot + app) coexist.
Load the app's SP. The bootloader manually does MSP = *(uint32_t*)0x0800_4000 = 0x2000_5000. Why manually? A software jump doesn't re-trigger the hardware reset sequence, so the bootloader must copy word 0 into MSP itself.
Jump to the app's reset handler. PC = *(uint32_t*)0x0800_4004 = 0x0800_4101; the CPU masks the LSB to get the real address 0x0800_4100 and stays in Thumb state. Why mask? On Cortex-M the low bit is the Thumb flag, not part of the address; the real entry is 0x0800_4100.

Verify: entry address = 0x0800_4101 & ~1 = 0x0800_4100; the app's SP = 0x2000_5000 matches Ex 3's _estack. The +0x4000 offset shifts entry 1's file location but the SP value is data, unchanged. ✓

Worked example Ex 6 — Case H: real-world word problem (sensor calibration table)

Setup. A firmware has a global calibration array: static const float k[3] = {1.0f, 0.5f, 0.25f}; used read-only, and a working buffer static float acc[3]; accumulated at runtime. Which array is copied by the reset handler, which is zeroed, and what does acc[0] read in the first line of main?

Forecast: name each array's section first.

Classify k. It's const and initialized → .rodata in Flash. It is not copied to RAM (it's read directly from Flash). Why? Const data never changes, so keeping it in Flash saves RAM; the reset handler doesn't touch .rodata.
Classify acc. Uninitialized (no = {...}) → .bss. Why? No initial values means storing zeros in Flash would be wasteful; .bss is the zero-cleared region.
Predict acc[0] in main. The .bss loop wrote 0x0000_0000 to all of acc → acc[0] == 0.0f. Why? The bit pattern 0x00000000 is exactly IEEE-754 +0.0, so a zeroed float reads as 0.0.

Verify: k stays in Flash (0 RAM copies for it); acc occupies $3 \times 4 = 12$ bytes of .bss, all set to 0; acc[0] == 0.0f. Had acc been .data with initializer {9,9,9}, it'd instead be copied from _sidata. ✓

Worked example Ex 7 — Case I (exam twist): predict the heisenbug's symptom

Setup. Startup code copies .data correctly but the .bss loop is missing. A global static int errors; (in .bss) is used as if (errors > 0) reboot();. On the author's board it never reboots; on a colleague's identical board it reboots at random. Explain and predict.

Forecast: which line "randomly" triggers?

errors starts as garbage. With no zeroing, errors holds whatever the RAM cell contained at power-up — undefined. Why this step? SRAM power-up state is not guaranteed 0; it depends on the silicon and the last power state.
Author's luck. That cell happened to be 0 on their board, so errors > 0 is false → no reboot. Why? Undefined ≠ random-every-time; a given chip may reliably power up as 0, hiding the bug.
Colleague's failure. A different die powers up with errors = 0x0000_0004 (say) → errors > 0 true → spurious reboot. Why? Same source code, different physical garbage → the classic non-reproducible heisenbug.

Verify: with the fix, .bss zeroing forces errors = 0 on every board → errors > 0 deterministically false at start. The symptom vanishes because "undefined" became the C-guaranteed 0. ✓

Worked example Ex 8 — Case J (exam twist): a misaligned

_estack Setup. A student edits the linker script and sets _estack = 0x2000_4FFE (not divisible by 4). RAM ends at 0x2000_4FFF. On the first exception, what happens?

Forecast: works? HardFault? silent?

State the alignment rule. Cortex-M requires SP to be 8-byte aligned at an exception boundary (and word-aligned always); 0x2000_4FFE is not even word-aligned ( $0 x 4 F F E mod 4 = 2$ ). Why this step? The hardware auto-stacks registers using SP; a misaligned SP means unaligned 32-bit writes.
Predict the fault. The first push/auto-stack to an unaligned address raises a UsageFault (or escalates to HardFault if UsageFault is disabled). Why? The exception model treats an unaligned stack as an error, not a wraparound.
The fix. Round _estack down to a word boundary: 0x2000_5000 (or the nearest $\equiv 0 (mod 8)$ ). Why? $0 x 2000_5000 mod 8 = 0$ , satisfying both the word and the 8-byte rule.

Verify: $0 x 4 F F E mod 4 = 2 \neq = 0$ → misaligned, faults. $0 x 5000 mod 8 = 0$ → aligned, safe. The corrected value is exactly the "end+1 rounded to 8" convention. ✓

Recall Did every matrix cell get hit?

Normal load (A) ::: Ex 1 Empty .data / empty .bss (B, C) ::: Ex 2 First push & growth direction (D, E) ::: Ex 3 Stack↔heap collision limit (F) ::: Ex 4 Relocated table via VTOR (G) ::: Ex 5 Real-world const-vs-bss (H) ::: Ex 6 .bss heisenbug symptom (I) ::: Ex 7 Misaligned _estack fault (J) ::: Ex 8

Connections used here

Linker scripts and memory sections (.text .data .bss) — source of every _s…/_e… symbol.
ARM Cortex-M exception and interrupt model — the auto-stacking and alignment rules in Ex 3 & Ex 8.
Stack vs Heap memory layout — the collision geometry in Ex 4.
Bootloaders and VTOR relocation — the relocated table in Ex 5.
Volatile, memory-mapped registers and hardware init — how VTOR itself is written.
The C runtime and crt0 — the bigger picture the reset handler slots into.