SoC
  • Home
  • Arm
  • Arm Cortex M0/M0+
  • Arm Cortex M4
  • Arm Cortex M3
  • Contact
Reading: Relocating the Vector Table in Cortex-M3 Boot Code
SUBSCRIBE
SoCSoC
Font ResizerAa
  • Home
  • Arm
  • Arm Cortex M0/M0+
  • Arm Cortex M4
Search
  • Home
  • Arm
  • Arm Cortex M0/M0+
  • Arm Cortex M4
Have an existing account? Sign In
Follow US
  • Looking for Something?
  • Privacy Policy
  • About Us
  • Sitemap
  • Contact Us
© S-O-C.ORG, All Rights Reserved.
Arm Cortex M3

Relocating the Vector Table in Cortex-M3 Boot Code

Graham Kruk
Last updated: October 5, 2023 10:08 am
Graham Kruk 8 Min Read
Share
SHARE

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
ContentsIntroductionReasons for Relocating the Vector Table1. Bootloader Code2. Larger Application Binary3. Faster Exception Handling4. External Memory BootingSteps to Relocate the Vector Table1. Configuring the VTOR Register2. Updating the Scatter Loading FileImplementing Boot CodeCopying Vector Table to SRAMInitializing Stack PointerLinker Script ModificationsDebugging with Relocated Vector TableConclusion

Contents

  • Introduction
  • Reasons for Relocating the Vector Table
  • Steps to Relocate the Vector Table
    • Configuring the VTOR Register
    • Updating the Scatter Loading File
  • Implementing Boot Code
    • Copying Vector Table to SRAM
    • Initializing Stack Pointer
  • 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:

  1. Configuring the VTOR register to point to the new vector table location
  2. 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.

Newsletter Form (#3)

More ARM insights right in your inbox

 


Share This Article
Facebook Twitter Email Copy Link Print
Previous Article Using Processor-Only vs. Full Reset in Cortex-M3 Debugging
Next Article Handling Resets and Exceptions During Cortex-M3 Boot Code Execution
Leave a comment Leave a comment

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

2k Followers Like
3k Followers Follow
10.1k Followers Pin
- Sponsored-
Ad image

You Might Also Like

What is the Thread mode in Arm Cortex M3?

The Thread mode in Arm Cortex M3 refers to one…

9 Min Read

Interrupts and Wake-up Features of the Cortex-M3 (Explained)

The Cortex-M3 processor has advanced interrupt handling and wake-up features…

9 Min Read

Cortex-M3 Memory Protection and Isolation (Explained)

The Cortex-M3 processor from ARM offers several features for memory…

10 Min Read

Handling Resets and Exceptions During Cortex-M3 Boot Code Execution

When a Cortex-M3 microcontroller first powers on or resets, it…

7 Min Read
SoCSoC
  • Looking for Something?
  • Privacy Policy
  • About Us
  • Sitemap
  • Contact Us
Welcome Back!

Sign in to your account