What is the vector table and where does it live?

The vector table is an array of 32-bit function pointers stored at the base of Flash memory (starting at address 0x00000000 on most Cortex-M devices, though this can be aliased or remapped). Each entry is the address of a handler function for a specific exception or interrupt. The first entry is special — it is not a function pointer but the initial value for the Main Stack Pointer (MSP). The second entry is the address of the Reset_Handler. Entries 3 through 15 are the ARM-defined system exceptions: NMI, HardFault, MemManage, BusFault, UsageFault, SVCall, PendSV, and SysTick. From entry 16 onward, the table contains vendor-specific peripheral interrupt handlers (WWDG, EXTI, USART, TIM, DMA, etc.), and the total number depends on the specific MCU — an STM32F407 has 82 IRQ entries, while a simpler Cortex-M0 may have only 32.

The vector table is defined in the startup assembly file and placed in a dedicated linker section (typically .isr_vector) that the linker script maps to the very beginning of Flash. Each unused handler is typically aliased to a Default_Handler — an infinite loop — so that an unexpected interrupt traps visibly rather than running wild through memory. The KEEP() directive in the linker script prevents the linker's garbage collector from discarding the vector table even though nothing in the code explicitly references it (the hardware references it, not the software).

A critical detail for bootloader designs: the vector table location can be changed at runtime using the VTOR register (Vector Table Offset Register). When a bootloader jumps to an application, it must set VTOR to point to the application's vector table in a different Flash region. Forgetting this step means the application's interrupts will still dispatch to the bootloader's handlers, causing crashes or silent misbehavior. On Cortex-M0 (which lacks VTOR), the vector table can be copied to RAM at the base address, and the memory map remapped — a more complex and error-prone process.