A vector table is a region of memory containing a list of addresses (vectors) that the processor jumps to when handling exceptions or interrupts. Each entry corresponds to a specific exception type or interrupt source; when an event fires, hardware uses the entry's index to fetch the target address and transfer control to the appropriate handler.
In practice
On ARM Cortex-M cores, the vector table is an array of 32-bit word-aligned addresses located by default at address 0x00000000, which may be aliased from internal flash, ROM, or another memory region depending on the chip's boot configuration. The first entry holds the initial stack pointer value, and subsequent entries hold handler addresses in a fixed order: Reset, NMI, HardFault, and so on through the processor's fault handlers, followed by vendor-specific peripheral interrupt vectors. Where supported, the VTOR (Vector Table Offset Register) in the SCB allows the table to be relocated to SRAM or another flash region at runtime, which is commonly used in bootloaders that need to hand off to an application with its own vector table. Note that the original Cortex-M0 does not implement VTOR, and some low-end MCUs provide vendor-specific remap mechanisms instead.
On many 8-bit and 16-bit architectures the mechanism is similar in concept but differs significantly in detail across families. AVR MCUs store a jump-instruction table at the start of flash, each slot occupying two or four words (in the AVR instruction sense) depending on the part and its flash size. PIC16/PIC18 devices use fixed interrupt entry points rather than a flexible address table. MSP430 stores 16-bit interrupt vectors in a dedicated segment at the top of flash (e.g., 0xFFE0-0xFFFF on many devices). The layout is architecture-specific and is documented in the device reference manual, architecture reference manual, or datasheet; for some details, startup files or device headers may be the most practical reference.
A common pitfall is a mismatch between the handler name used in application code and the weak symbol defined in the startup file. On Cortex-M projects using CMSIS-style startup files (common in STM32, LPC, nRF52, SAM, and Kinetis ecosystems), each slot is pre-populated with a weak alias pointing to a default infinite-loop handler. If the developer misspells an IRQ handler name, the linker silently links in the weak default rather than the intended function, and the processor loops forever on that interrupt instead of executing real handler code.
On Cortex-M, relocating the vector table to SRAM is a common approach when code needs to patch individual vectors at runtime, for example when a component-based firmware architecture wants to register handlers dynamically. Some platforms provide other mechanisms or allow indirect dispatch without moving the hardware vector table. After copying the table to SRAM and updating VTOR, writes to the SRAM entries take effect immediately. Care is needed to ensure the SRAM region is correctly aligned: the required alignment depends on the specific Cortex-M core and the number of vectors, with the table base address needing to be aligned to the next power of two greater than or equal to the table's byte size (consult the core's Technical Reference Manual for the exact rule and minimum alignment for your target).
Frequently asked
Where is the vector table located by default, and can it be moved?
On ARM Cortex-M cores, the reset default places the vector table at 0x00000000, which may be aliased from internal
flash, ROM, or another memory region depending on the chip and boot configuration. The VTOR register (available on Cortex-M0+, M3, M4, M7, and later, but not on the original Cortex-M0) lets firmware relocate the table to any sufficiently aligned address in flash or
SRAM. On most 8/16-bit architectures the location is fixed by hardware and cannot be relocated.
What happens if an interrupt fires but no handler is installed?
The behavior depends on the architecture and startup code. On Cortex-M devices using CMSIS-style startup files, unimplemented handlers are weak-aliased to a default handler that typically sits in an infinite loop. The CPU does not crash immediately, but the system stalls in that loop. On architectures without weak-symbol defaults, an uninitialized slot may contain 0x00000000 or unprogrammed
flash (0xFFFFFFFF), causing a jump to an invalid address and a fault.
Why does the first entry of a Cortex-M vector table hold a stack pointer value instead of a handler address?
The Cortex-M reset sequence is defined to load the initial Main
Stack Pointer (MSP) directly from word 0 of the vector table before fetching the Reset handler address from word 1. This removes the need for a separate stack-initialization instruction at the very start of execution. No other architecture-defined slot is used this way; all remaining entries are handler addresses.
What alignment does the vector table require when relocated to SRAM on Cortex-M?
The table base address written to VTOR must be aligned to the next power of two that is greater than or equal to the table's total byte size, though the exact minimum and the details of this rule vary by Cortex-M core generation and number of vectors. For example, a Cortex-M4 device with 100
interrupt lines needs a table of (16 + 100) x 4 = 464 bytes, so the base address must be aligned to 512 bytes. Always consult the core's Technical Reference Manual for the precise requirement. Misalignment causes the wrong vector to be fetched and is a difficult bug to diagnose.
How do bootloaders typically hand control to an application's vector table?
A common pattern on Cortex-M is: (1) copy or confirm the application's vector table is present at its expected
flash address, (2) update VTOR to point to the application's table, (3) load the application's initial
stack pointer from the table's first word, then (4) branch to the Reset handler address stored in the second word. The
bootloader must also ensure
interrupts are disabled and peripherals are in a clean state before the jump, since the application will reinitialize its own hardware.
Differentiators vs similar concepts
The vector table is sometimes confused with a software dispatch table or function-pointer array used in application code. A software dispatch table is an ordinary array of function pointers managed entirely by the application (for example, a table of command handlers). The
interrupt vector table is a hardware-defined structure whose base address and slot ordering are fixed by the processor architecture; the CPU fetches from it directly in hardware when an exception occurs, with no software indirection involved. The two concepts are structurally similar but operate at completely different levels.
