1 Processor response to exceptions
When an exception occurs, the processor takes the following actions:
1. Copy the CPSR into the corresponding SPSR. This saves the current mode, interrupt mask, and condition flags.
2. Switch to ARM state.
3. Change the appropriate CPSR mode bits so that:
- Change to the appropriate mode and map in the corresponding marshaled registers for that mode.
- Disable interrupts. When any exception occurs, IRQ is disabled. When FIQ occurs at reset, FIQ is disabled.
4. Set the corresponding LR to the return address.
5. Set the PC to the vector address of the exception.
2 Return from exception handler
The method for returning from an exception depends on whether the exception handler uses stack manipulation. Regardless, to return to the point where the exception occurred, the exception handler must:
- Restore the CPSR from the corresponding SPSR
- Restore the PC using the return address in the corresponding LR.
For a simple return that does not require restoring the target mode register from the stack, the exception handler can accomplish this by executing a data processing instruction with the following settings:
- Set the S flag
- PC is used as the destination register.
The required return instruction depends on the type of exception.
Note that it is not necessary to return from the reset handler, since the reset handler directly executes the main code.
When handling an exception, if the exception handler entry code uses the stack to store registers that must be preserved, it can return by using the load multiple instruction with the ^ qualifier. The exception handler can return with a single instruction, for example using:
LDMFD sp!,{R0-R12,pc}^
To do this, the exception handler must save the following to the stack:
- All working registers used when the handler is called
- The link register is modified to produce the same effect as a data processing instruction.
The ^ qualifier specifies that the CPSR is to be restored from the SPSR.
Note: You cannot use any 16-bit Thumb instructions to return from an exception because these instructions do not restore the CPSR.
3 Return address and return instruction
The actual location pointed to by the program counter when the exception occurs depends on the type of exception. The return address may not necessarily be the next instruction pointed to by the program counter. If the exception occurs in ARM state, the processor stores (PC+4) in lr_ mode.
The following instructions describe in more detail how to properly return from your handling code for each exception type.
3.1 Returning from SWI and Undefined Instruction Handlers
SWI and undefined instruction exceptions are caused by the instruction itself, so when handling the exception, the program counter remains unchanged (prefetch fails). The processor stores (PC+4) in lr_mode. Thus lr_mode points to the next instruction to be executed. To restore the program counter from lr, use:
MOVS pc, lr
Returns control from the handler.
The handler entry and exit code that pushes the return address into the heap and pops it on return is:
STMFD sp!,{reglist,lr}
;...
LDMFD sp!,{reglist,pc}^
3.2 Returning from FIQ and IRQ Handlers
After executing each instruction, the processor checks whether the interrupt pin is LOW (level) and whether the CPSR interrupt disable bit is clear. As a result, an IRQ or FIQ exception occurs only after the program counter is updated. The processor stores (PC+4) in lr_mode. Make lr_mode point to the instruction after the instruction that was not executed when the exception occurred. After the handler is completed, it must continue from the instruction that lr_mode pointed to when the exception occurred. The continuation execution address is one word (four bytes) less than the address in lr_mode, so its return instruction is:
SUBS pc, lr, #4
The handler entry and exit code that pushes the return address into the heap and pops it on return is:
SUB lr,lr,#4
STMFD sp!,{reglist,lr}
;...
LDMFD sp!,{reglist,pc}^
3.3 Return from Prefetch Interrupt Handler
If the processor attempts to fetch an instruction at an illegal address, the instruction is marked as invalid. Execution of instructions already in the pipeline continues until the invalid instruction is encountered, which generates the "prefetch interrupt". If there is an instruction that maps the virtual memory location to that physical memory, the exception handler loads the unmapped instruction into physical memory and uses the MMU. The handler must then return and run the instruction that generated the exception again. The instruction is now loaded and executed.
Because the program counter has not been updated when the prefetch interrupt is issued, lr_abt points to the next instruction that caused the exception. The handler must return to the instruction at lr_ABT-4, using the following instruction:
SUBS pc,lr, #4
The handler entry and exit code that pushes the return address into the heap and pops it on return is:
SUB lr,lr,#4
STMFD sp!,{reglist,lr}
;...
LDMFD sp!,{reglist,pc}^
3.4 Returning from Data Interrupt Handler
When a load or store instruction attempts to access memory, the program counter is updated. The stored value of (PC+4) points to the instruction immediately following the address where the exception occurred. The MMU (if any) maps the address to physical memory, and the handler must return to the instruction that originally interrupted the program for a second execution attempt. Therefore, the return address is two words (eight bytes) less than in lr_abt, and the following return instruction is used:
SUBS pc, lr, #8
The handler entry and exit code that pushes the return address into the heap and pops it on return is:
SUB lr,lr,#8
STMFD sp!,{reglist,lr}
;...
LDMFD sp!,{reglist,pc}^
Previous article:ARM9 interrupts and PC
Next article:Understanding of ARM load domain and run domain
- Popular Resources
- Popular amplifiers
- Learn ARM development(16)
- Learn ARM development(17)
- Learn ARM development(18)
- Embedded system debugging simulation tool
- A small question that has been bothering me recently has finally been solved~~
- Learn ARM development (1)
- Learn ARM development (2)
- Learn ARM development (4)
- Learn ARM development (6)
Professor at Beihang University, dedicated to promoting microcontrollers and embedded systems for over 20 years.
- LED chemical incompatibility test to see which chemicals LEDs can be used with
- Application of ARM9 hardware coprocessor on WinCE embedded motherboard
- What are the key points for selecting rotor flowmeter?
- LM317 high power charger circuit
- A brief analysis of Embest's application and development of embedded medical devices
- Single-phase RC protection circuit
- stm32 PVD programmable voltage monitor
- Introduction and measurement of edge trigger and level trigger of 51 single chip microcomputer
- Improved design of Linux system software shell protection technology
- What to do if the ABB robot protection device stops
- Detailed explanation of intelligent car body perception system
- How to solve the problem that the servo drive is not enabled
- Why does the servo drive not power on?
- What point should I connect to when the servo is turned on?
- How to turn on the internal enable of Panasonic servo drive?
- What is the rigidity setting of Panasonic servo drive?
- How to change the inertia ratio of Panasonic servo drive
- What is the inertia ratio of the servo motor?
- Is it better for the motor to have a large or small moment of inertia?
- What is the difference between low inertia and high inertia of servo motors?
- 【Development Kit for nRF52840】+ Review 5-thread trial
- How to determine whether the EN enable pin of the chip needs a series resistor?
- 【Qinheng Trial】Implementation of USB HID
- matlab
- Driving external RF front end via BlueNRG-LP
- Live broadcast at 10 am today [How to reduce power supply noise with ADI low-noise Buck regulator]
- [Mil MYS-8MMX] Mil MYS-8MMQ6-8E2D-180-C Application 1 - Calculate pi
- How to add external C modules in MicroPython
- A Detailed Explanation of the Basics of C Language (1)
- Can someone help me with this differential amplifier circuit? The op amp is overheating