Understanding ARM Exception and Interrupt Handling

1.1 Interrupts in Daily Life

Suppose there is a large room with small rooms inside, a baby is sleeping, and his mother is reading outside. Question: How can the mother know when the child wakes up?

1. Open the door once in a while to check if the baby is awake, then continue reading.

2. Wait until the baby makes a sound before going to check, during which she continues reading.

The first method is called Polling:

• Advantages: Simple

• Disadvantages: Exhausting

How to write the program?

while(1){  1 read book  2 open door    if(baby is still sleeping)     return(continue reading)     else     take care of baby  }

The second method is called Interrupt:

• Advantages: Not exhausting

• Disadvantages: Complex

How to write the program:

while(1){  read book} interrupt service routine() // Core issue: how to be called?{  handle taking care of baby}

1.2 How the Mother Handles Interrupts

Let’s see how the mother takes care of the baby when interrupted by the baby’s crying?

The mother’s handling process:

• Usually reading a book

• Various sounds occur, how to handle these sounds

° There is a cat meowing in the distance (ignore it)

° Doorbell rings for a delivery (open the door to receive the delivery)

° Baby cries (open the door and take care of the baby)

• The mother only handles the doorbell and the baby’s crying

‣ First, put a bookmark in the book and close it (save the scene)

‣ Go to handle (call the corresponding interrupt service routine)

‣ Continue reading (restore the scene)

Different situations, different handling

• For the doorbell: open the door to pick up the package

• For the crying: take care of the baby

1.3 Exception and Interrupt Handling Process in ARM Systems

We will abstract the mother’s handling process:

• The mother’s brain is equivalent to the CPU

° The ears hear sounds and send signals to the brain

° There are many sources of sound

‣ There is a cat meowing in the distance, the doorbell ringing, the baby crying

° These sounds enter the ears and are transmitted to the brain

° Besides these sounds that can interrupt the mother’s reading, there are other situations, such as:

‣ Feeling unwell

‣ A spider falling down

‣ Special situations that cannot be avoided must be handled immediately

For the ARM system, the hardware block diagram of exceptions and interrupts is as follows:

All interrupt sources (buttons, timers, etc.) send interrupts to the interrupt controller, which then sends signals to the CPU, informing it of the urgent situations that have occurred.

Besides these interrupts, what else can interrupt the CPU’s operation?

• Incorrect instructions

• Data access issues

• Reset signals

• And so on, these can interrupt the CPU, these are called exceptions

• Interrupts belong to a type of exception

How does the ARM system handle exceptions and interrupts? The focus is on saving the scene and restoring the scene, the handling process is as follows:

• Save the scene (various registers)

• Handle the exception (interrupts are a type of exception)

• Restore the scene

Let’s refine how to use exceptions (interrupts) in the ARM system:

• Initialization

° Set the interrupt source to allow it to generate interrupts

° Set the interrupt controller (can mask a certain interrupt, priority)

° Set the CPU’s master switch to enable interrupts

• Execute other programs: normal programs

• Generate an interrupt, for example: press a button —> interrupt controller —> CPU

• The CPU checks for any interrupts/exceptions after executing each instruction

• If an interrupt/exception is found, it starts processing:

° Save the scene

° Distinguish between exceptions/interrupts, call the corresponding exception/interrupt handling function

° Restore the scene

Different chips, different architectures, there are slight differences in this aspect:

• Save/restore the scene: Cortex M3/M4 is hardware implemented, Cortex A7 is software implemented

• The CPU halts the current execution and jumps to execute the exception handling code: there are also differences

° Cortex M3/M4 places function addresses in the vector table

° Cortex A7 places jump instructions in the vector table

2.1 Handling Process

• After executing each instruction, it checks for any interrupts/exceptions

• If an interrupt/exception is found, it starts processing:

° Save the scene

° Distinguish between exceptions/interrupts, call the corresponding exception/interrupt handling function

° Restore the scene

Different chips, different architectures, there are slight differences in this aspect:

• The CPU halts the current execution and jumps to execute the exception handling code: there are also differences

° Cortex M3/M4 places function addresses in the vector table

° Cortex A7 places jump instructions in the vector table

• Save/restore the scene: Cortex M3/M4 is hardware implemented, Cortex A7 is software implemented

2.2 Cortex M3/M4

References: DDI0403E_B_armv7m_arm.pdf 、 ARM Cortex-M3 and Cortex-M4 Authority Guide.pdf 、PM0056.pdf

To understand this handling process, we need to start with the vector table. In mathematics, a vector is defined as a quantity with direction, in programming, a vector can be thought of as an array containing multiple items. In the ARM architecture, the entry points for exceptions/interrupts are neatly arranged together.

2.2.1 Vector Table of M3/M4

In the M3/M4 vector table, the addresses of specific exception/interrupt handling functions are placed. For example, when a Reset exception occurs, the CPU will find the first item in the vector table, get the address of the Reset_Handler function, and jump to execute it. For example, when an EXTI Line 0 interrupt occurs, the CPU will find the 22nd item in the vector table, get the address of the EXTI0_IRQHandler function, and jump to execute it.

• Before jumping, the hardware will save the scene (the register values are saved in the SP stack)

• After the function execution is completed, it will return and restore the scene

; Vector Table Mapped to Address 0 at Reset                AREA    RESET, DATA, READONLY                EXPORT  __Vectors                EXPORT  __Vectors_End                EXPORT  __Vectors_Size                __Vectors       DCD     __initial_sp               ; Top of Stack                DCD     Reset_Handler              ; Reset Handler                DCD     NMI_Handler                ; NMI Handler                DCD     HardFault_Handler          ; Hard Fault Handler                DCD     MemManage_Handler          ; MPU Fault Handler                DCD     BusFault_Handler           ; Bus Fault Handler                DCD     UsageFault_Handler         ; Usage Fault Handler                DCD     0                          ; Reserved                DCD     0                          ; Reserved                DCD     0                          ; Reserved                DCD     0                          ; Reserved                DCD     SVC_Handler                ; SVCall Handler                DCD     DebugMon_Handler           ; Debug Monitor Handler                DCD     0                          ; Reserved                DCD     PendSV_Handler             ; PendSV Handler                DCD     SysTick_Handler            ; SysTick Handler                ; External Interrupts                DCD     WWDG_IRQHandler            ; Window Watchdog                DCD     PVD_IRQHandler             ; PVD through EXTI Line detect                DCD     TAMPER_IRQHandler          ; Tamper                DCD     RTC_IRQHandler             ; RTC                DCD     FLASH_IRQHandler           ; Flash                DCD     RCC_IRQHandler             ; RCC                DCD     EXTI0_IRQHandler           ; EXTI Line 0                DCD     EXTI1_IRQHandler           ; EXTI Line 1                DCD     EXTI2_IRQHandler           ; EXTI Line 2                DCD     EXTI3_IRQHandler           ; EXTI Line 3                DCD     EXTI4_IRQHandler           ; EXTI Line 4                DCD     DMA1_Channel1_IRQHandler   ; DMA1 Channel 1                DCD     DMA1_Channel2_IRQHandler   ; DMA1 Channel 2                DCD     DMA1_Channel3_IRQHandler   ; DMA1 Channel 3                DCD     DMA1_Channel4_IRQHandler   ; DMA1 Channel 4                DCD     DMA1_Channel5_IRQHandler   ; DMA1 Channel 5                DCD     DMA1_Channel6_IRQHandler   ; DMA1 Channel 6                DCD     DMA1_Channel7_IRQHandler   ; DMA1 Channel 7                DCD     ADC1_2_IRQHandler          ; ADC1 & ADC2                DCD     USB_HP_CAN1_TX_IRQHandler  ; USB High Priority or CAN1 TX                DCD     USB_LP_CAN1_RX0_IRQHandler ; USB Low  Priority or CAN1 RX0                DCD     CAN1_RX1_IRQHandler        ; CAN1 RX1                DCD     CAN1_SCE_IRQHandler        ; CAN1 SCE                DCD     EXTI9_5_IRQHandler         ; EXTI Line 9..5                DCD     TIM1_BRK_IRQHandler        ; TIM1 Break                DCD     TIM1_UP_IRQHandler         ; TIM1 Update                DCD     TIM1_TRG_COM_IRQHandler    ; TIM1 Trigger and Commutation                DCD     TIM1_CC_IRQHandler         ; TIM1 Capture Compare                DCD     TIM2_IRQHandler            ; TIM2                DCD     TIM3_IRQHandler            ; TIM3                DCD     TIM4_IRQHandler            ; TIM4                DCD     I2C1_EV_IRQHandler         ; I2C1 Event                DCD     I2C1_ER_IRQHandler         ; I2C1 Error                DCD     I2C2_EV_IRQHandler         ; I2C2 Event                DCD     I2C2_ER_IRQHandler         ; I2C2 Error                DCD     SPI1_IRQHandler            ; SPI1                DCD     SPI2_IRQHandler            ; SPI2                DCD     USART1_IRQHandler          ; USART1                DCD     USART2_IRQHandler          ; USART2                DCD     USART3_IRQHandler          ; USART3                DCD     EXTI15_10_IRQHandler       ; EXTI Line 15..10                DCD     RTCAlarm_IRQHandler        ; RTC Alarm through EXTI Line                DCD     USBWakeUp_IRQHandler       ; USB Wakeup from suspend                DCD     TIM8_BRK_IRQHandler        ; TIM8 Break                DCD     TIM8_UP_IRQHandler         ; TIM8 Update                DCD     TIM8_TRG_COM_IRQHandler    ; TIM8 Trigger and Commutation                DCD     TIM8_CC_IRQHandler         ; TIM8 Capture Compare                DCD     ADC3_IRQHandler            ; ADC3                DCD     FSMC_IRQHandler            ; FSMC                DCD     SDIO_IRQHandler            ; SDIO                DCD     TIM5_IRQHandler            ; TIM5                DCD     SPI3_IRQHandler            ; SPI3                DCD     UART4_IRQHandler           ; UART4                DCD     UART5_IRQHandler           ; UART5                DCD     TIM6_IRQHandler            ; TIM6                DCD     TIM7_IRQHandler            ; TIM7                DCD     DMA2_Channel1_IRQHandler   ; DMA2 Channel1                DCD     DMA2_Channel2_IRQHandler   ; DMA2 Channel2                DCD     DMA2_Channel3_IRQHandler   ; DMA2 Channel3                DCD     DMA2_Channel4_5_IRQHandler ; DMA2 Channel4 & Channel5                __Vectors_End

2.2.2 Exception/Interrupt Handling Process of M3/M4

When an exception/interrupt occurs, the hardware implements the following:

• Save the scene: save the register values at the moment of interruption into the stack

• Obtain the function address from the vector table based on the exception/interrupt number and jump to execute it

• After the function execution is completed, restore the scene from the stack

Saving the scene, distinguishing between exceptions/interrupts, and jumping to execute are all hardware implementations. We only need to fill in the addresses of the handling functions in the vector table.

The hardware takes care of most of the work.

The M3/M4 vector table stores function addresses.

2.3 Cortex A7

References: ARM Architecture Reference Manual ARMv7-A and ARMv7-R edition.pdf

In fact, the previous S3C2440 belonged to the ARM9 processor, and its exception/interrupt handling process is the same as that of the Cortex A7.

2.3.1 Vector Table of A7

The A7 vector table contains jump instructions for certain types of exceptions. For example, when a Reset exception occurs, the CPU will find the first item in the vector table, get the b reset instruction, and execute it to jump to the reset function. For any interrupt, the CPU will find the 6th item in the vector table, get the ldrpc, _irq instruction, and execute it to jump to the _irq function.

• Before jumping, the hardware will only save the CPSR register

• After jumping, the software must save the scene

• Before returning from the function, the software must restore the scene

_start:     b  reset  ldr  pc, _undefined_instruction  ldr  pc, _software_interrupt  ldr  pc, _prefetch_abort  ldr  pc, _data_abort  ldr  pc, _not_used  ldr  pc, _irq  ldr  pc, _fiq

2.3.2 Exception/Interrupt Handling Process of A7

When an exception/interrupt occurs, the hardware implements the following:

• The CPU switches to the corresponding exception mode, such as IRQ mode, undefined mode, SVC mode

• Save the CPSR at the moment of interruption to SPSR

° CPSR: current program status register

° SPSR: saved program status register

• Jump to the entry address of this exception and execute the instruction, which is usually a jump instruction

The software has a lot to do:

• Save the scene

• Distinguish between exceptions/interrupts

• Call the corresponding handling function

• Restore the scene

The A7 vector table stores jump instructions.

3.1 Review of the Handling Process

After executing each instruction, the CPU checks for any interrupts/exceptions, and if an interrupt/exception is found, it starts processing:

• Save the scene

• Distinguish between exceptions/interrupts, call the corresponding exception/interrupt handling function

• Restore the scene

For different processors, the specific handling work varies:

• Save the scene: in Cortex M3/M4 it is completed by hardware, in Cortex A7 and others it is software implemented

• Distinguish between exceptions/interrupts: in Cortex M3/M4 it is completed by hardware, in Cortex A7 and others it is software implemented

• Call the handling function: in Cortex M3/M4 it is called by hardware, in Cortex A7 and others it is called by software

• Restore the scene: in Cortex M3/M4 it is software triggered and hardware implemented, in Cortex A7 and others it is software implemented

No matter whether it is hardware or software implementation, the first step is to save the scene.

2.2 Why Save the Scene

Any program will eventually be converted to machine code, the above C code can be converted into the assembly instructions on the right. For these four instructions, they may be interrupted at any time by an exception, how to ensure that after the exception handling is completed, the interrupted program can still run correctly?

• These four instructions involve the R0 and R1 registers, and the values of R0 and R1 must remain unchanged during the interruption and when resuming execution

• When the third instruction is executed, the comparison result is stored in the program status register, and it must remain unchanged during the interruption and when resuming execution

• These four instructions read memory a and b, and the memory a and b must remain unchanged during the interruption and when resuming execution

Keeping the memory unchanged is easy to achieve, as long as the program does not go out of bounds. Therefore, the key is that R0, R1, and the program status register must remain unchanged (of course, not just these registers):

• Before handling the exception, save these registers in the stack, this is called saving the scene

• After handling the exception, restore these registers from the stack, this is called restoring the scene

2.3 Saving the Scene

There are these registers in the ARM processor:

In ARM, there is an ATPCS rule (ARM-THUMB procedure call standard). It stipulates the usage of registers R0-R15:

• R0-R3

Parameters between the caller and the callee

• R4-R11

Functions may use these, so save them at the function’s entry and restore them at the function’s exit.

There is also a program status register, which is called XPSR in M3/M4 and CPSR in A7, we refer to it as PSR. R0-R15 and PSR are collectively referred to as the scene. After an exception/interrupt occurs, before handling the exception/interrupt, do we need to save all these registers? No need!

In a C function, if it modifies R0-R3, R12, R14 (LR) and PSR, it must save them to the stack and restore them from the stack before the function ends. These registers are divided into two parts: caller-saved registers (R0-R3, R12, LR, PSR) and callee-saved registers (R4-R11). For example, if function A calls function B, function A should know:

• R0-R3 are used to pass parameters to function B

• Function B can freely modify R0-R3

• Function A should not expect function B to save R0-R3

• Saving R0-R3 is the responsibility of function A

• The same reasoning applies to LR and PSR, saving them is the responsibility of function A

For function B:

• If I use any of R4-R11, I will save them at the function’s entry and restore them before returning

• This ensures that R4-R11 remains unchanged as seen by function A before and after the call to function B

Assuming function B is the exception/interrupt handling function, if function B can guarantee that R4-R11 remain unchanged, then when saving the scene, it only needs to save:

• Caller-saved registers (R0-R3, R12, LR, PSR)

• PC

2.4 For M3/M4

References: DDI0403E_B_armv7m_arm.pdf、ARM Cortex-M3 and Cortex-M4 Authority Guide.pdf、PM0056.pdf

2.4.1 Hardware Scene Saving

2.4.2 Calling C Functions

After the C function executes, it returns to the location indicated by LR. Is it enough to set LR to the address of the interrupted program? If it only returns to the location indicated by LR, how will the hardware restore the registers saved in the stack? Before calling the exception handling function, M3/M4 sets LR to a special value, this special value is called EXC_RETURN.

When the value of the PC register equals EXC_RETURN, it triggers the exception return mechanism. In simple terms: it will restore registers such as R0-R3, R12, LR, PC, PSR from the stack. For the value of EXC_RETURN, please refer to ARM Cortex-M3 and Cortex-M4 Authority Guide.pdf, the screenshot is as follows:

When we call a C function, we set LR to the return address. If we set it like this, it can indeed return to the original location after executing that function, but it cannot restore the registers saved in the stack. At this time, for M3/M4, an operation is performed: it sets LR to a special value, and calls the exception/interrupt handling function as usual. After the function execution is completed, it attempts to return to the location indicated by LR. The CPU will find that LR is a special value, thus triggering the restore scene process, which will restore the values from the stack to the registers, such as restoring the return address to the PC register.

Two additional knowledge points:

• Operating modes: M3/M4 have two operating modes

° Handler mode: when executing interrupt service programs and other exception handling, it is in handler mode

° Thread mode: when executing normal application code, it is in thread mode

• M3/M4 have two SP registers: SP_process, SP_main

° Some RTOS use SP_process when running user programs, while SP_main is used by default.

2.5 For A7

The registers are as follows:

The processor has 9 modes: User, Sys, FIQ, IRQ, ABT, SVC, UND, MON, HYP. The dark-colored registers in the above image indicate the “Banked” registers for that mode, for example, the SPSR register has its own, separate register in many modes. For example, when accessing SPSR in IRQ mode, it accesses SPSR_irq, which cannot be accessed in other modes.

It is worth noting the FIQ mode, named “Fast Interrupt,” which has many “Banked” registers: R8-R12, SP, LR. In FIQ mode, since it can use its own R8-R12, SP, LR, there is no need to save the “R8-R12, SP, LR” of the interrupted program. This saves time in saving these registers, making interrupt handling much faster, hence the name “FIQ”.

From the above image, we can also see that almost every mode has its own SP register, indicating that these modes have their own stack.

When an exception occurs, taking IRQ as an example:

• The CPU automatically switches to the corresponding mode, such as entering IRQ mode

• And it saves the CPSR of the interrupted state to SPSR_irq

Therefore, when saving the scene during an exception/interrupt, we only need to save:

• Caller-saved registers (R0-R3, R12, LR)

• PC

For the software part, the following tasks need to be done:

1. Save the scene. As shown in the previous diagram, for A7, it needs to save registers R0-R3, R12, LR, and store these registers in SP_IRQ. The PSR register is also shown in the diagram, but it has already been saved by hardware;

2. Distinguish and handle exceptions/interrupts;

3. Restore the scene.

For more content, click “Read More” to visit the GuYueJu official website.