The vector table and reset handler are the most important parts of the boot and interrupt system in ARM Cortex-M microcontrollers. These parts work at the lowest level of execution. They take control right after the power is turned on or the reset button is pressed, and they decide how the processor will respond to events.
Many developers work mostly with higher-level application code, but knowing how these systems work is important for debugging, optimisation, and advanced embedded development.
The vector table tells the processor what to do when it gets an interrupt, and the reset handler gets the system ready to run the app. They work together to connect hardware initialisation and the running of user code.
What Is the Vector Table?
The vector table is a structured list of memory addresses that the processor uses to determine how to handle exceptions and interrupts. It is located at a fixed position in memory, typically at the beginning of the flash region, and is one of the first things the processor accesses during startup.
Each entry in the vector table corresponds to a specific exception or interrupt source. Instead of containing executable code, the table stores pointers to handler functions. When an event occurs, such as a timer interrupt or an external signal, the processor looks up the corresponding entry in the vector table and jumps to the address stored there.
The first two entries in the vector table are special. The very first entry holds the initial value of the stack pointer, which defines where the stack begins in memory.
The second entry contains the address of the reset handler, which is the first piece of executable code that runs after a reset. This structure ensures that the processor has immediate access to both a valid stack and a starting point for execution.
Structure and Organization of the Vector Table
The vector table follows a strict order defined by the ARM architecture. After the initial stack pointer and reset handler, the table includes entries for core system exceptions such as the non-maskable interrupt, hard fault, memory management fault, bus fault, and usage fault. These exceptions handle critical error conditions and system-level events.
Following the core exceptions, the table includes entries for peripheral interrupts. These correspond to hardware components such as timers, communication interfaces, and input/output pins.
The exact number and type of these entries depend on the specific microcontroller, but their placement within the table is fixed.
Because the vector table is simply an array of addresses, it is highly efficient. The processor can quickly determine the correct handler without additional computation, which is essential for real-time responsiveness.
What Is the Reset Handler?
The reset handler is the function that executes immediately after the processor resets. Its address is stored in the second entry of the vector table, making it the first executable code the processor runs. The purpose of the reset handler is to initialize the system and prepare it for running the main application.
When the reset handler begins execution, the system is in a minimal and uninitialized state. Memory has not been prepared, variables are not initialized, and hardware peripherals are not configured. The reset handler performs all the necessary steps to transition the system into a fully operational state.
This function is typically implemented in the startup file and is closely tied to the overall boot process. It acts as the entry point for all embedded applications on Cortex-M devices.
Responsibilities of the Reset Handler
The reset handler carries out several critical initialization tasks before transferring control to the main application. One of its primary responsibilities is memory initialization. It copies initialized data from flash memory to RAM and clears uninitialized data sections, ensuring that variables start with the correct values.
Another important task is setting up the runtime environment. This includes configuring the stack, initializing system clocks, and preparing essential hardware components. Without these steps, the application would not function correctly.
After completing initialization, the reset handler calls the main() function, which marks the beginning of the user application.
From this point onward, the system operates under the control of the application code, but the groundwork laid by the reset handler remains essential for stability and correctness.
How Interrupt Handling Works
The vector table plays a central role in interrupt handling. When an interrupt occurs, the processor automatically pauses the current execution and saves its state on the stack. It then uses the interrupt number to locate the corresponding entry in the vector table and jumps to the associated handler function.
Once the handler finishes executing, the processor restores the saved state and resumes normal execution. This process happens very quickly and is designed to minimize latency, which is critical in real-time systems.
Developers can define custom interrupt handlers by implementing functions with specific names that match the entries in the vector table. If no custom handler is provided, a default handler is used, which typically results in an infinite loop. This behavior helps identify unhandled interrupts during development.
Relocating the Vector Table
Although the vector table is usually located at the beginning of flash memory, it can be relocated in some systems. This is done by updating a special register that tells the processor where to find the table.
Relocation is useful in scenarios such as bootloaders, where different firmware images may require different vector tables.
By placing the vector table in RAM or another memory region, developers can modify interrupt handlers dynamically or switch between different configurations.
This flexibility is particularly valuable in advanced applications and firmware update mechanisms.
Common Issues and Debugging
It can be hard to figure out what’s wrong with the vector table and reset handler because they happen at the very beginning of execution. If the stack pointer or reset handler address is wrong, the system might not start up or work in a way that is hard to predict.
If memory is not set up correctly, variables may have values that are not what you expect. If interrupt handlers are missing or not set up correctly, the system may go into fault conditions.
Debugging these problems often means looking at the startup file, checking the linker settings, and using debugging tools to follow the execution from the reset vector.
It’s easier to find and fix these kinds of problems when you know how these parts work, especially in complicated embedded systems.
Why This Matters
For a lot of developers, the vector table and reset handler are still hidden behind development tools and libraries. But learning more about these parts is very helpful. It makes debugging easier, lets you change the boot process, and makes the whole system more reliable.
This knowledge is even more important in applications where speed and accuracy are very important, like safety-critical devices or real-time control systems. It lets developers tweak how the system works and make sure that interrupts and initialisation are done right.
