ARM Cortex-M4 Interrupt Vector Table Misalignment and Default Handler Execution
When working with ARM Cortex-M microcontrollers, one of the most critical components of the system initialization process is the correct configuration of the interrupt vector table. The vector table is a memory region that contains the addresses of exception handlers, including interrupt service routines (ISRs). If the vector table is misconfigured, the processor may fail to locate the correct exception handler and instead execute the default handler, leading to unexpected behavior such as bus faults or infinite loops.
In the context of the Tiva C Launchpad (TM4C123GH6PM) microcontroller, the vector table is typically located at the start of the flash memory (address 0x00000000). Each entry in the vector table corresponds to a specific exception or interrupt, and the processor uses this table to determine the address of the handler to execute when an exception or interrupt occurs. If the vector table is not correctly populated or if the processor cannot locate the correct handler, it will default to executing the __default_handler, which is often a catch-all function that may trigger a bus fault or other error condition.
The root cause of this issue often lies in one or more of the following areas: incorrect vector table placement, misaligned vector table entries, incorrect interrupt vector numbers, or issues with the linker script. Each of these potential causes must be carefully examined to ensure that the processor can correctly locate and execute the intended interrupt handler.
Misconfigured Vector Table Entries and Incorrect Interrupt Vector Numbers
One of the most common causes of the processor jumping to the default handler is an incorrect or misconfigured vector table entry. Each interrupt or exception has a specific vector number, which corresponds to its position in the vector table. For example, the SysTick timer interrupt typically occupies vector number 15, while peripheral interrupts such as GPIO port interrupts occupy higher vector numbers.
In the case of the Tiva C Launchpad, the GPIO Port J interrupt is assigned vector number 67. If the vector table entry for this interrupt is incorrectly populated or if the vector number is misaligned, the processor will not be able to locate the correct handler and will instead execute the default handler. This issue can arise if the vector table is manually modified without ensuring that the correct vector numbers are used or if the vector table is not properly aligned in memory.
Additionally, the vector table must be correctly referenced in the linker script. The linker script defines the memory layout of the application, including the location of the vector table. If the vector table is not correctly referenced in the linker script, the processor may not be able to locate it, leading to the execution of the default handler.
Debugging and Correcting Vector Table Misconfigurations
To diagnose and correct issues related to the vector table, a systematic approach is required. The first step is to verify the contents of the vector table using tools such as arm-none-eabi-objdump or the IAR Embedded Workbench’s ielfdump utility. These tools allow you to inspect the binary output of your application and confirm that the vector table is correctly populated with the addresses of your interrupt handlers.
For example, using arm-none-eabi-objdump, you can disassemble the binary and inspect the vector table to ensure that each entry corresponds to the correct handler. The output will typically show the initial stack pointer, the reset handler, and the addresses of other exception handlers. If any of these entries are incorrect or point to the default handler, it indicates a misconfiguration in the vector table.
Next, you should verify the vector numbers for your interrupts. This can be done by consulting the microcontroller’s reference manual or datasheet, which will provide a list of vector numbers for each interrupt. Ensure that the vector numbers in your vector table match those specified in the documentation.
Finally, you should inspect the linker script to confirm that the vector table is correctly referenced. The linker script should define the memory regions for your application, including the location of the vector table. If the vector table is not correctly referenced, you may need to modify the linker script to ensure that the vector table is placed at the correct address.
By following these steps, you can identify and correct issues related to the vector table, ensuring that the processor can correctly locate and execute your interrupt handlers.
Implementing Correct Vector Table Configuration and Debugging Techniques
To implement a correct vector table configuration, you must first ensure that the vector table is correctly defined in your startup file. The startup file is typically written in assembly and contains the initial vector table, which is populated with the addresses of the exception handlers. Each entry in the vector table should correspond to a specific exception or interrupt, and the addresses of the handlers should be correctly specified.
For example, in the IAR Embedded Workbench, the startup file may look like this:
MODULE ?vector_table
AAPCS INTERWORK, VFP_COMPATIBLE, RWPI_COMPATIBLE
PRESERVE8
CFI Names cfiNames0
CFI StackFrame CFA R13 DATA
CFI Resource R0:32, R1:32, R2:32, R3:32, R4:32, R5:32, R6:32, R7:32
CFI Resource R8:32, R9:32, R10:32, R11:32, R12:32, R13:32, R14:32
CFI EndNames cfiNames0
CFI Common cfiCommon0 Using cfiNames0
CFI CodeAlign 2
CFI DataAlign 4
CFI ReturnAddress R14 CODE
CFI CFA R13+0
CFI R0 Undefined
CFI R1 Undefined
CFI R2 Undefined
CFI R3 Undefined
CFI R4 SameValue
CFI R5 SameValue
CFI R6 SameValue
CFI R7 SameValue
CFI R8 SameValue
CFI R9 SameValue
CFI R10 SameValue
CFI R11 SameValue
CFI R12 Undefined
CFI R14 SameValue
CFI EndCommon cfiCommon0
SECTION CSTACK:DATA:NOROOT(3)
SECTION .intvec:CODE:NOROOT(2)
EXTERN __iar_program_start
PUBLIC __vector_table
DATA
__vector_table
DCD sfe(CSTACK)
DCD __iar_program_start
DCD NMI_Handler
DCD HardFault_Handler
DCD MemManage_Handler
DCD BusFault_Handler
DCD UsageFault_Handler
DCD 0
DCD 0
DCD 0
DCD 0
DCD SVC_Handler
DCD DebugMon_Handler
DCD 0
DCD PendSV_Handler
DCD SysTick_Handler
DCD GPIOPortA_IRQHandler
DCD GPIOPortB_IRQHandler
DCD GPIOPortC_IRQHandler
DCD GPIOPortD_IRQHandler
DCD GPIOPortE_IRQHandler
DCD UART0_IRQHandler
DCD UART1_IRQHandler
DCD SSI0_IRQHandler
DCD I2C0_IRQHandler
DCD PWMFault_IRQHandler
DCD PWMGen0_IRQHandler
DCD PWMGen1_IRQHandler
DCD PWMGen2_IRQHandler
DCD QEI0_IRQHandler
DCD ADCSeq0_IRQHandler
DCD ADCSeq1_IRQHandler
DCD ADCSeq2_IRQHandler
DCD ADCSeq3_IRQHandler
DCD Watchdog_IRQHandler
DCD Timer0A_IRQHandler
DCD Timer0B_IRQHandler
DCD Timer1A_IRQHandler
DCD Timer1B_IRQHandler
DCD Timer2A_IRQHandler
DCD Timer2B_IRQHandler
DCD Comp0_IRQHandler
DCD Comp1_IRQHandler
DCD Comp2_IRQHandler
DCD SysCtrl_IRQHandler
DCD FlashCtrl_IRQHandler
DCD GPIOPortF_IRQHandler
DCD GPIOPortG_IRQHandler
DCD GPIOPortH_IRQHandler
DCD USART2_IRQHandler
DCD SSI1_IRQHandler
DCD Timer3A_IRQHandler
DCD Timer3B_IRQHandler
DCD I2C1_IRQHandler
DCD QEI1_IRQHandler
DCD CAN0_IRQHandler
DCD CAN1_IRQHandler
DCD CAN2_IRQHandler
DCD Ethernet_IRQHandler
DCD Hibernate_IRQHandler
DCD USB0_IRQHandler
DCD PWMGen3_IRQHandler
DCD uDMAST_IRQHandler
DCD uDMAError_IRQHandler
DCD ADC1Seq0_IRQHandler
DCD ADC1Seq1_IRQHandler
DCD ADC1Seq2_IRQHandler
DCD ADC1Seq3_IRQHandler
DCD I2S0_IRQHandler
DCD EBI0_IRQHandler
DCD GPIOPortJ_IRQHandler
In this example, the vector table is defined with the correct addresses for each handler. The DCD directive is used to define each entry in the vector table, and the addresses of the handlers are specified. If any of these entries are incorrect or missing, the processor will not be able to locate the correct handler and will instead execute the default handler.
Once the vector table is correctly defined, you should verify its contents using a disassembly tool. For example, using arm-none-eabi-objdump, you can inspect the binary output to confirm that the vector table is correctly populated:
arm-none-eabi-objdump -D myfile.elf
The output will show the contents of the vector table, including the addresses of the exception handlers. If any of these addresses are incorrect or point to the default handler, it indicates a misconfiguration in the vector table.
Finally, you should ensure that the vector table is correctly referenced in the linker script. The linker script should define the memory regions for your application, including the location of the vector table. For example, the linker script may include the following lines to define the vector table:
MEMORY
{
FLASH (rx) : ORIGIN = 0x00000000, LENGTH = 256K
RAM (rwx) : ORIGIN = 0x20000000, LENGTH = 32K
}
SECTIONS
{
.vector_table :
{
KEEP(*(.vector_table))
} > FLASH
}
In this example, the vector table is placed at the start of the flash memory (address 0x00000000). If the vector table is not correctly referenced in the linker script, the processor may not be able to locate it, leading to the execution of the default handler.
By following these steps, you can ensure that the vector table is correctly configured and that the processor can correctly locate and execute your interrupt handlers. This will prevent the processor from jumping to the default handler and ensure that your application behaves as expected.
