The Cortex-M3 vector table contains the reset value and exceptions handlers that are executed when specific events occur. By default, the vector table is located at the start of the flash memory in Cortex-M3 devices. However, it is possible to relocate the vector table to a different location in the flash memory or SRAM. This allows flexibility in placing boot code and gives more space for the application. Relocating the vector table requires configuring the Vector Table Offset Register (VTOR) and updating scatter loading file.
Contents
- Introduction
- Reasons for Relocating the Vector Table
- Steps to Relocate the Vector Table
- Implementing Boot Code
- Linker Script Modifications
- Debugging with Relocated Vector Table
- Conclusion
Introduction
The Cortex-M3 vector table resides at the start of the flash memory and contains the initial stack pointer value and exceptions handler functions. The processor resets to the address 0x00000000 which points to the start of the vector table. This table must be present at a fixed location for the processor to boot correctly.
However, in some cases it is desirable to relocate the vector table from its original flash memory location. Some reasons for doing so include:
- Having boot code that runs before the main application
- Increasing space for the application binary image
- Placing the vector table in SRAM for faster exception handling
Relocating the vector table requires configuring the Cortex-M3 Vector Table Offset Register (VTOR) to point to the new location. It also requires updating the scatter loading file used by the linker to place code and data sections correctly.
Reasons for Relocating the Vector Table
Here are some common reasons why relocating the vector table may be necessary in Cortex-M3 designs:
1. Bootloader Code
Many embedded systems have bootloader code that runs before the main application firmware. This handles tasks like:
- Initializing hardware
- Checking for firmware updates
- Validating firmware image
- Copying application code from external flash to internal RAM
Placing this bootloader code in flash memory requires relocating the vector table elsewhere to make space.
2. Larger Application Binary
Relocating the vector table also allows the application binary image to occupy flash memory from address 0x00000000. This provides more space for the firmware code and constants.
3. Faster Exception Handling
The vector table can be relocated to internal SRAM for lower latency exception handling. Retrieving exception handlers from flash has latency of a few wait states. SRAM provides single cycle access for faster exception processing.
4. External Memory Booting
For systems booting from external flash or RAM chips, the vector table can be relocated to internal memory for faster booting.
Steps to Relocate the Vector Table
Relocating the Cortex-M3 vector table involves two main steps:
- Configuring the VTOR register to point to the new vector table location
- Updating the scatter loading file to place code and data sections correctly
1. Configuring the VTOR Register
The VTOR register is used to relocate the vector table anywhere within the processor’s memory map. This 32-bit register needs to be set to the new start address of the vector table during boot up.
For example, to place the vector table at address 0x2000 0000 in flash: MOVW r0, #0x2000 MOVT r0, #0x0000 LDR r1, =0xE000ED08 //Address of VTOR STR r0, [r1]
VTOR supports alignment of up to 128 bytes, so the lowest 7 bits are ignored. The vector table should be located on a 128 byte boundary for optimal performance.
2. Updating the Scatter Loading File
The scatter loading file defines the placement of code and data sections in target memory. It needs to be updated to place sections correctly after relocating the vector table.
For example, with default vector table: LR_IROM1 0x00000000 0x00080000 { ; load region size_region ER_IROM1 0x00000000 0x00080000 { ; load address = execution address *.o (RESET, +First) *(InRoot$$Sections) .ANY (+RO) } ;…rest of file }
With vector table relocated to 0x2000 0000: LR_IROM1 0x00000000 0x00080000 { ER_IROM1 0x2000 0000 0x00080000 { *.o (RESET, +First) *(InRoot$$Sections) .ANY (+RO) } ;…rest of file }
This places the vector table and code sections at the new relocated address.
Implementing Boot Code
After relocating the vector table, boot code must be implemented to perform critical early initialization tasks.
Copying Vector Table to SRAM
If relocating the vector table to SRAM, the boot code must copy it from flash to SRAM. For example: LDR r0, =__isr_vector //Start of vector table LDR r1, =__Vectors //SRAM location MOV r2, #0x100 //Size of vector table BL memcpy //Copy vector table
Initializing Stack Pointer
The Stack Pointer (SP) must be initialized before any stack access is made in the application. This can be done by reading the value from the relocated vector table: LDR r0, =__Vectors //Start of relocated vector table LDR r1, [r0] //Load SP value MSR msp, r1 //Set SP
Linker Script Modifications
The linker script may need to be updated along with the scatter file when relocating the vector table. Typically, the __Vectors symbol needs to be redefined to match the new vector table location: __Vectors 0x20000000; //New start of vector table
Also, the stack and heap may need to be relocated to avoid collisions with the new vector table address range.
Debugging with Relocated Vector Table
Debugging with a relocated vector table requires configuring the debugger or IDE with the new address.Usually this involves:
- Setting VTOR value in debugger to match application address
- Configuring debugger flash and SRAM regions for correct addresses
- Loading debugger symbols from application elf file
With these steps, breakpoints and tracing will work correctly with the relocated vector table.
Conclusion
Relocating the Cortex-M3 vector table provides flexibility in placing boot code, increasing application space, or faster exception handling. The VTOR register and scatter loading file need to be configured correctly along with implementing boot initialization code. With some debug configuration, development and debugging can be seamless with a relocated vector table.
This covers the major steps involved in relocating the vector table in Cortex-M3 designs. This provides a useful technique to customize boot sequence, optimize exception latency, and maximize memory usage for the application.
