How Does the Memory Map Work in an Embedded Microcontroller?

Detailed Explanation

A 32-bit microcontroller has a 32-bit address bus, giving it a theoretical address space of 4 GB (0x00000000 to 0xFFFFFFFF). Almost none of that space corresponds to physical memory — most of the addresses are reserved or unmapped. The memory map defines which address ranges correspond to which physical resources: flash, RAM, peripheral hardware, and debug infrastructure.

Understanding the memory map is essential for three things: writing correct volatile pointer code for hardware registers, configuring linker scripts with the right ORIGIN and LENGTH values, and using a debugger to inspect live register and memory state.

The Standard Cortex-M Address Map

ARM defines a standard address map that all Cortex-M processors follow (per the ARM Cortex-M Architecture Reference Manual):

Chip vendors place their specific flash, RAM, and peripherals within these ARM-defined ranges. The exact addresses vary by manufacturer and MCU family.

STM32F4 Memory Map Example

For the STM32F405/407 family (from ST RM0090):

Flash lives in the Code region (0x08000000), not at 0x00000000. The reason is the boot alias mechanism — see the FAQ below for why the Cortex-M boots from 0x00000000 but flash is physically at 0x08000000.

Memory-Mapped Peripheral Registers

Every hardware peripheral on a microcontroller — UART, SPI, I2C, ADC, DMA, GPIO — is controlled through a set of registers that appear at fixed addresses in the peripheral address space. From C's perspective, they are just addresses where reads and writes have hardware side effects.

The STM32 HAL and CMSIS device headers define these as C structures:

/* CMSIS-style definition for STM32 GPIOA */
typedef struct {
    volatile uint32_t MODER;    /* offset 0x00 — pin mode register */
    volatile uint32_t OTYPER;   /* offset 0x04 — output type */
    volatile uint32_t OSPEEDR;  /* offset 0x08 — output speed */
    volatile uint32_t PUPDR;    /* offset 0x0C — pull-up/pull-down */
    volatile uint32_t IDR;      /* offset 0x10 — input data register */
    volatile uint32_t ODR;      /* offset 0x14 — output data register */
    /* ... more registers ... */
} GPIO_TypeDef;

/* GPIOA starts at 0x40020000 in the AHB1 peripheral bus */
#define GPIOA ((GPIO_TypeDef *) 0x40020000UL)

A write to GPIOA->ODR = 0x0001; compiles to a single store instruction at address 0x40020014 — the hardware GPIO peripheral sees this store and changes the pin output state.

Why volatile Is Non-Negotiable for Hardware Registers

The C compiler is allowed to assume that memory is stable — if you read the same address twice with no intervening write in your code, it is allowed to use the value from the first read and skip the second. For normal variables in RAM, this optimisation is correct. For hardware registers, it is catastrophically wrong.

Consider polling a UART receive register:

/* Wrong — without volatile, the compiler may only read USART2->SR once */
while (!(USART2->SR & USART_SR_RXNE));
uint8_t byte = USART2->DR;

/* Correct — volatile forces a re-read of SR on every loop iteration */
while (!(USART2->SR & USART_SR_RXNE));  /* SR is declared volatile */
uint8_t byte = USART2->DR;

The RXNE bit in SR changes from 0 to 1 when a byte is received — this change is caused by hardware, not by software. Without volatile, a sufficiently aggressive optimiser reads SR once, sees RXNE as 0, and either loops forever with a cached 0 or eliminates the loop entirely. The CMSIS device headers declare all peripheral registers as volatile uint32_t, which is why HAL-generated code works correctly — but hand-written register access code must apply volatile explicitly.

The Vector Table at the Start of Flash

The first bytes of the code region (wherever flash is mapped at boot) are not executable instructions — they are the interrupt vector table: an array of 32-bit addresses. On Cortex-M the first entry is the initial stack pointer value; the second is the address of the Reset Handler (the first code executed after reset); subsequent entries are the addresses of interrupt service routines.

The linker script's KEEP(*(.isr_vector)) ensures the vector table is placed at the very start of the flash binary, at the flash ORIGIN address. On STM32, this is 0x08000000. The reset handler address stored in the second vector table entry is the first code the processor executes — it loads the stack pointer, calls SystemInit(), copies .data to RAM, and zeros .bss before calling main().

After a bootloader hands control to an application, the application writes its own vector table address to SCB->VTOR (the Vector Table Offset Register at 0xE000ED08, in the Private Peripheral Bus region). This tells the NVIC where to find the interrupt service routine addresses for the running application rather than the bootloader.

How the Linker Script Maps to the Memory Map

The MEMORY block in the linker script directly encodes the physical memory map. For STM32F405:

MEMORY
{
  FLASH (rx)  : ORIGIN = 0x08000000, LENGTH = 1024K
  RAM   (rwx) : ORIGIN = 0x20000000, LENGTH = 128K
}

These values come from the reference manual's memory map table — not from the Cortex-M architecture specification (which only defines the broad region boundaries). Every STM32 variant in the same package family has the same base addresses but different LENGTH values; always confirm against the specific device's datasheet. For products with over-the-air firmware updates, the available flash space is divided into primary and secondary application slots — understanding the flash address layout is a prerequisite before configuring the partition table.

Inspecting the Memory Map in a Debugger

A JTAG/SWD debugger allows direct inspection of the memory map at runtime. In STM32CubeIDE or VS Code with Cortex-Debug, the "Memory" view lets you read any address — navigate to 0x40020000 to read raw GPIO register values, 0xE000ED04 to read the NVIC pending interrupt status, or 0x08000000 to inspect the vector table entries and confirm the reset handler address. This is invaluable when a peripheral is not behaving as expected and the question is whether the register contains what the firmware intended to write.

For firmware projects requiring correct peripheral register configuration, linker setup, or hardware-bring-up, Zeus Design's embedded firmware team handles the full hardware-software interface from linker script to driver layer.

Design Considerations

• Align DMA buffers to their region's requirements. On STM32F4, DMA cannot access CCM RAM (0x10000000) — place all DMA transmit/receive buffers in SRAM1/SRAM2. The linker script can enforce this by putting DMA buffers in a named section assigned to the correct RAM region.
• Reserve CCM RAM for time-critical data. CCM RAM has zero-wait-state access from the Cortex-M4 data bus but is inaccessible to DMA. It is ideal for RTOS task stacks, interrupt handler data, and lookup tables that are read frequently by the CPU. Check your specific device's reference manual — not all STM32 families have CCM.
• Unaligned accesses in the peripheral region may fault. Peripheral registers are almost always 32-bit aligned; accessing them as 8-bit or 16-bit pointers may produce a hardware fault on strictly-aligned Cortex-M3/M4 implementations. Read and write full 32-bit words and use bit-masking in C rather than byte-width pointer casts.

Common Mistakes

• Using addresses from the wrong reference. The Cortex-M architecture defines broad region boundaries (SRAM starts somewhere in 0x20000000–0x3FFFFFFF); vendor chips place flash and RAM at specific addresses within those regions. Always use the specific device's reference manual, not the architecture overview.
• Reading peripheral registers without volatile. Without volatile, the optimiser may cache register values in CPU registers. Symptoms: polling loops that spin forever, status flags that appear never to change, or data registers that always read the same value. Always declare peripheral register structures with volatile.
• Forgetting the CCM RAM DMA restriction. A working firmware that is ported to use CCM RAM for its buffers (to free up SRAM1) will silently break any DMA transfers using those buffers — the DMA controller will read and write unrelated memory locations. The firmware compiles without errors.
• Hardcoding addresses instead of using CMSIS headers. Writing *(uint32_t *)0x40020014 = 1; instead of GPIOA->ODR = 1; is error-prone and non-portable. CMSIS device headers are generated from vendor SVD files and are the authoritative source for peripheral register addresses — use them.