The interrupt vector table (IVT) is a key component in ARM Cortex microcontrollers and processors. It provides the mapping between interrupt sources and their corresponding interrupt service routines (ISRs). Understanding where the IVT is stored in memory is important for effective and efficient interrupt handling.
What is the Interrupt Vector Table?
The interrupt vector table contains an array of function pointers, one for each peripheral that can generate an interrupt. For example, there may be separate interrupt vectors for timers, GPIO pins, UARTs, ADCs, and more. Each vector contains the memory address of the ISR that should execute when an interrupt occurs on that peripheral.
When an interrupt occurs, the processor looks up the corresponding ISR address in the IVT and jumps to that location to run the handler code. This provides a structured, organized way to dispatch different interrupts to different functions.
IVT Storage in Cortex-M Microcontrollers
In Cortex-M microcontrollers, such as those based on ARMv7-M architecture, the IVT is located at the very beginning of flash or ROM memory. Specifically, it starts at address 0x0000 0000. This region is sometimes referred to as the “vector table base address”.
The IVT occupies the first 1KB of memory. Each vector is 4 bytes, so there are 256 interrupt vectors available. Not all of these are necessarily used, but they provide flexibility for complex peripherals and future expansion.
Storing the IVT at the bottom of the memory map provides quick access. The processor can immediately fetch the ISR address as soon as an interrupt occurs. It also keeps the IVT out of the way of normal application code or data storage in higher regions of memory.
Vector Table Structure
Here is a simplified example IVT layout for a Cortex-M microcontroller: Address Contents 0x0000 Reset Vector 0x0004 NMI Vector 0x0008 HardFault Vector … 0x00FC ADC Interrupt Vector 0x0100 Application Code/Data Starts
The first several vectors are fixed system exceptions defined by the architecture. Then device-specific peripheral vectors follow. After the IVT, application code and data can be located starting at address 0x0100 and beyond.
Relocating the Vector Table
While the IVT typically starts at address 0x0000, some Cortex-M devices allow it to be relocated to a higher memory region. This is configured using the Vector Table Offset Register (VTOR).
Relocation can be useful to place application code or data at the very bottom of the memory map, or to have multiple IVTs for different execution contexts.
IVT Storage in Cortex-A Processors
Cortex-A application processors have greater flexibility in IVT placement compared to Cortex-M microcontrollers. There are two options:
1. Fixed Address
Same as Cortex-M, the IVT can be placed at address 0x0000. This allows quick interrupt response time.
2. Variable Address
The IVT can be located at a higher address set by the Vector Base Address Register (VBAR). The VBAR is configured by software during application startup.
A variable IVT location enables more customized system design. For example, the IVT could be placed in SRAM for faster access speed. Or multiple IVTs can be maintained at different addresses.
Booting and the Interrupt Vector Table
During booting and reset, the ARM processor jumps to the address defined in the first entry of the IVT, which is the reset vector. This memory location should contain the address for the reset handler routine.
The reset handler must perform initializations such as:
- Setting up stack pointer
- Initializing variables and hardware
- Configuring clock speeds
- Enabling interrupts
Once complete, the reset handler can jump to the main application entry point to start software execution. Interrupts will be handled through the IVT once enabled.
External Interrupt Controllers
In complex ARM-based systems, an external interrupt controller may be used to manage a high number of peripheral interrupt sources. For example, the ARM Generic Interrupt Controller (GIC).
In these cases, the IVT entries contain vectors for the peripheral interrupts supported directly by the ARM CPU. Any external peripheral interrupts are managed by the interrupt controller and do not need IVT entries.
Software Initialization of the IVT
While the interrupt vector table isinitialized by the startup code at device boot, the application software needs to configure a few key aspects:
- Set the address for the reset handler routine
- Populate each IVT entry with the correct ISR address for the corresponding interrupt source
- Write interrupt handler functions for each peripheral ISR
- Optionally relocate the IVT by programming the VTOR or VBAR register
This IVT configuration is typically done by startup code and hardware abstraction layers provided by the device vendor and underlying software frameworks.
Read-Only IVT in Flash Memory
Since unpredictable writes to the IVT could make the system unstable, it is often placed in read-only memory like flash. This prevents bugs or errant code from accidentally modifying the IVT contents.
However, it also means the IVT cannot be modified dynamically at runtime. A writable IVT can be useful in certain advanced cases, but requires it to be in SRAM or a flash region with write access enabled.
Caching and the Interrupt Vector Table
One potential issue with an IVT located in flash memory is cache coherency. If the processor caches the IVT contents, interrupts could fetch stale, incorrect vector addresses from the cache rather than memory.
There are a few techniques to handle this:
- Disable caching for the IVT memory region
- Invalidate cache entries on IVT updates
- Use lockable memory regions to control caching
Properly maintaining coherency between cached and non-cached views of the IVT memory is important for robust interrupt handling.
IVT in TrustZone-Enabled Systems
ARM TrustZone security extensions provide isolation between secure and non-secure states. This enables use cases like secure boot, authentication, and cryptographic acceleration.
In TrustZone systems, there are separate IVTs defined for both secure and non-secure states. The processor refers to the appropriate table based on its current state.
This prevents non-secure code from tampering with the secure IVT, and provides additional control over interrupt handling.
Virtualization and Hyp Mode IVTs
Cortex-A processors with virtualization extensions have an added hypervisor (hyp) mode and associated banked register sets. Hyp mode has its own dedicated IVT for exception handling.
This hyp mode IVT can be positioned independently from the other normal and secure IVTs. The processor switches between these based on its current mode – normal, hyp, or secure.
Summary
In summary, the interrupt vector table is a key component for Cortex processor interrupt handling:
- Stored at base address 0x0000 for Cortex-M microcontrollers
- Configurable base address in Cortex-A applications processors
- Contains function pointers to ISR handlers for each interrupt source
- Read-only location in flash memory for stability
- May require cache management for coherency
- Customized implementations in TrustZone and virtualized systems
Understanding the IVT layout is important for building responsive, robust embedded and real-time systems using ARM processors.
