Boot Sources and Address Mapping

A Cortex-M0+ reads its initial SP and reset vector from the start of the address space, so the chip must make a valid vector table appear there at every reset. Chips solve this in one of three ways:

1. A fixed boot ROM at 0. The vendor’s ROM always runs first and later points the core at your code. The RP2040 does this: address 0 is always its boot ROM.
2. Aliasing. Boot pins or option bits sampled at reset select which memory appears at address 0 (flash, a system ROM with the vendor’s boot loader, or SRAM). The memory also stays at its own address.
3. Flash directly at 0. The simplest chips just put flash there, with any boot loader stored in a protected corner of it.

Mapped at 0x0000_0000main flashsystem flashSRAM

Reset figure

main flash at 0x0000_0000. Your application’s vector table: the usual boot.

The core always reads its first two words from the bottom of the address space. Many chips decide what appears there with boot pins or option bits sampled at reset, by aliasing one memory at address 0. The three choices shown are offered by the STM32F4 HAL’s remap macros (the SYSCFG MEMRMP register): main flash, system flash holding ST’s boot loader, and embedded SRAM; the F405/F407 can also map an external-memory bank. The memory stays at its own address too. Stack and handler values are illustrative. The RP2040 does not remap: address 0 is always its boot ROM.

The alias is a window, not a copy. On the STM32F4, used here as a labelled example, flash is always at 0x0800_0000 and the HAL’s remap macros can make it, the system flash (ST’s boot loader) or SRAM appear at 0x0000_0000 (on the F405/F407 also an external-memory bank). Because the linker placed your code at 0x0800_0000, every handler address in the table is a 0x0800_… address: the core fetches the table through the alias, but after the first jump it runs from flash’s real address.

Chips whose core has a vector-table offset register (VTOR; optional on the Cortex-M0+) can move the table after reset. That is how a boot ROM or a boot stage hands over: it sets VTOR to the application’s table and loads SP and PC from it, the same two loads the hardware does at reset (but without resetting anything else). On the RP2040 it is boot2 that does this, as the next sections show. Without VTOR, handlers can be changed at run time by aliasing RAM at address 0 (what CMSIS’s NVIC_SetVector assumes) or by handlers in flash that dispatch through a table of function pointers in RAM.

The ROM can read flash only in the slowest, most compatible way, with a basic serial read command, because it cannot know which flash chip the board uses. Executing code from that would be very slow. The 256 bytes it checks are therefore not your application but a second-stage boot loader (boot2), written for a specific flash chip: it configures the flash and the QSPI interface for fast execute-in-place (XIP), then sets VTOR to 0x1000_0100, the application’s vector table right after boot2 in flash, loads SP and PC from it, and branches. From there on the chip behaves like any Cortex-M after reset.

Corrupt byte

none

Bit to flip

0

Choose a corrupt byte first; an unmodified block has no bit to flip.

Reset figure

Unmodified block: computed 0xf8733b12, stored 0xf8733b12. Match: the boot ROM copies the block to SRAM and runs it.

The RP2040 boot ROM reads 256 bytes from the start of flash and accepts them only if a CRC-32 of the first 252 bytes (polynomial 0x04C11DB7, initial value 0xFFFFFFFF) equals the 32-bit value stored little-endian in the last four. The block here is illustrative random data with a correct checksum; flip one bit anywhere and the check fails.

The checksum is a CRC-32 with polynomial 0x04C11DB7, processed most significant bit first, starting from 0xFFFFFFFF, without a final inversion (the variant usually called CRC-32/MPEG-2). The SDK’s build script appends it when it pads boot2. Any single flipped bit changes it, so a half-written or blank flash is rejected rather than executed.