Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob

XMC1000 Vector table remap – KBA235654

XMC1000 Vector table remap – KBA235654

IFX_Publisher1
Community Manager
Community Manager
Community Manager
250 sign-ins First comment on KBA 250 replies posted

Community Translation: XMC1000 ベクタ テーブルの再マップ – KBA235654

Version: **

The Arm® Cortex® Core takes care of the interrupts and core exceptions with the help of Nested vector interrrupt controller (NVIC). NVIC uses a look-up table, called a vector table, to determine which code to execute. In a few Cortex® architecutres, the Vector Table Offset Register (VTOR) register is used if the program wants to modify the vector table. This can be useful in the following cases:

  • When the user has a bootloader in their application, and the bootloader and application have their own vector tables.
  • If the user wants a RAM-based vector table to dynamically use different handlers
  • If the user is using an external RAM

However, the Cortex® M0 core of the XMC1000 device family does not support this feature. The Dave startup code solves this problem for the XMC1000 devices.

For more information on the XMC1000  device startup, see the application note AP32326.

Vector table remapping:

The vector table is remapped to locations in SRAM, with each vector allocated to a size of 4 bytes. The allocated size is not sufficient for an exception or interrupt. Therefore, a branch instruction is needed to jump to the actual handler at another location. This is achieved through the veneers. Basically, a veneer acts as an intermediate target for the instruction and then sets the PC to the actual location. The following is an example of a veneer code:

.section “.XmcVeneerCode”,”ax”,%progbits

.align 1

.globl HardFault_Veneer

HardFault_Veneer:

LDR R0, =HardFault_Handler

MOV PC, R0

In the startup code you can see this being done by using the following Macro

.macro Insert_InterruptVeener Interrupt

.globl \Interrupt()_Veener

\Interrupt()_Veener:

LDR R0, =\Interrupt()_Handler

BX R0

.endm

 

They are mapped to the default handler using the following macro in the code:

.macro Insert_InterruptHandler Interrupt

.weak \Interrupt()_Handler

#if defined(ENABLE_OWN_HANDLER)

.thumb_func

.type \Interrupt()_Handler, %function

\Interrupt()_Handler:

b .

.size \Interrupt()_Handler, . - \Interrupt()_Handler

#else

.thumb_set \Interrupt()_Handler, Default_Handler

#endif

.endm

 

Users can define their own custom handler to override this. In addition, they can check the linker file to see the veneer being mapped to the initial SRAM location.

/* DSRAM layout (Lowest to highest)*/

/* Veneer <> Stack <> DATA <> BSS <> HEAP */

.VENEER_Code ABSOLUTE(0x2000000C):

{ . = ALIGN(4); /* section size must be multiply of 4. See startup.S file */ VeneerStart = .; KEEP(*(.XmcVeneerCode)); . = ALIGN(4); /* section size must be multiply of 4. See startup.S file */ VeneerEnd = .; }

> SRAM AT > FLASH

eROData = LOADADDR (.VENEER_Code);

VeneerSize = ABSOLUTE(VeneerEnd) - ABSOLUTE(VeneerStart);

0 Likes
361 Views