The vector table in Cortex-M3 microcontrollers contains the reset value and exceptions handler addresses. Its placement in memory is an important consideration during application development. This article provides a detailed overview of vector table placement options and considerations for Cortex-M3 devices.
Introduction to Vector Table
The vector table contains the initial stack pointer value and the set of exception handler addresses. On reset, the processor loads the initial stack pointer value and starts execution at the reset handler address. When an exception occurs, the processor uses the corresponding exception handler address from the vector table for handling it.
The vector table size and contents depend on the specific Cortex-M3 device. A typical vector table contains the following entries:
- Initial stack pointer value
- Reset handler address
- NMI handler address
- HardFault handler address
- Memory Management Fault handler address
- BusFault handler address
- UsageFault handler address
- Reserved spots for optional system exceptions
- Reserved spots for external interrupts
The memory location of the vector table is device specific. Developers need to configure it correctly for their application software to function as intended.
Vector Table Placement Options
Cortex-M3 devices provide flexibility in locating the vector table in memory. The main options are:
1. Internal Flash Memory
Many Cortex-M3 microcontrollers have internal flash memory for storing code and data. The vector table can be placed in the internal flash memory. This allows faster exception handling due to reduced latency in fetching the exception handler addresses.
The reset handler code can initialize the stack pointer and perform other startup tasks before jumping to the main application. The flash memory offers non-volatile storage for the vector table contents.
2. Internal SRAM
SRAM provides faster access compared to flash memory. Placing the vector table in internal SRAM enables quicker exception handling. The reset handler needs to copy the vector table from flash to SRAM on startup before jumping to main().
SRAM storage is volatile. The vector table contents need to be reinitialized after reset and power cycles. This adds overhead to the startup process. SRAM availability is also limited in most Cortex-M devices.
3. External RAM
Some microcontrollers support external RAM connectivity over a bus interface like FSMC. The vector table can be placed in external RAM for reduced latency exception handling. Similar to SRAM usage, the reset handler needs to copy the vector table on startup.
External RAM offers larger storage capacity compared to internal SRAM. But it also leads to increased memory access latency and power consumption. The additional hardware adds to system cost and complexity.
4. Remapped Flash Address
Some Cortex-M3 devices allow remapping of flash memory address space to a specific region for vector table placement. For example, the first 1 KB of flash can be mapped to address 0x0000_0000. This provides low latency exception handling while retaining non-volatile vector table storage in flash.
No vector table copying is needed at startup. Flash memory wear due to repeated writes can also be avoided. But additional configuration needs to be done for address remapping.
Key Considerations
The choice of vector table placement location depends on various factors:
Performance
Latency of exception handling is an important consideration. Placing the vector table in SRAM or external RAM reduces latency but increases startup time. Remapped flash offers a good balance with low latency and simple startup.
Memory Size
SRAM and external RAM options require available memory capacity. The vector table size can vary from 128 bytes to 1 KB based on the number of exceptions supported.
Startup Time
SRAM and external RAM options need vector table copying on each reset. This adds to startup time. Internal flash has minimal impact on startup time.
Power Consumption
External RAM increases power consumption due to external memory access. SRAM and internal flash options are better suited for low power applications.
Hardware Complexity
External RAM requires additional address/data buses, memory controllers etc. Remapped flash needs remap hardware support. Internal flash and SRAM minimize hardware complexity.
Flexibility
RAM based options allow modifications to exception handlers at runtime if required. Flash options provide only immutable storage. Remapped flash provides better flexibility than normal flash usage.
Example Device Specific Implementations
Here are some examples of vector table placement in specific Cortex-M3 devices:
STM32F103xx Microcontrollers
STM32F103xx MCUs have internal flash and SRAM. The vector table can be placed in either of these memories.
1. Flash – Located at addresses 0x0800_0000 to 0x0800_03FF in flash memory. This is the default location.
2. SRAM – Located at address 0x2000_0000 to 0x2000_03FF in SRAM. The reset handler copies it here from flash on startup.
LPC17xx Microcontrollers
LPC17xx MCUs have internal flash, SRAM and optional external RAM support.
1. Flash – Default location at 0x0000_0000.
2. SRAM – At address 0x1000_0000.
3. External RAM – At address 0x2000_0000.
A remap register allows remapping flash to 0x0000_0000 for low latency exception handling.
NXP Kinetis KL25Z MCU
The KL25Z Cortex-M0+ device allows flexible positioning of the vector table anywhere in flash memory or SRAM. Flash size is 128 KB and SRAM size is 16 KB.
The Vector Table Offset Register (VTOR) specifies the vector table address. This register can be written at runtime to relocate the vector table.
Summary
In this article, we discussed vector table placement options like internal flash, SRAM, external RAM and remapped flash. Factors like performance, memory size, startup time, power and flexibility determine the ideal location choice. Device specific implementations were also looked at through STM32F103xx, LPC17xx and Kinetis KL25Z examples. With a good understanding of vector table placement considerations, developers can make optimal design decisions for their Cortex-M3 applications.
