Performance
Introduction
Click Play ► to listen to the commentary.
In this lesson, we will define what interrupt latency means and why it is important for system performance.
We’ll review both interrupt latency—the time it takes for the CPU to respond to an interrupt—and interrupt return latency, which is the time required to resume normal program execution after servicing an interrupt.
Understanding these concepts is key to optimizing responsiveness and reliability in embedded systems.
Interrupt Latency
Click Play ► to listen to the commentary.

Interrupt latency is defined as the time between when the system clock detects a pending interrupt and when the CPU fetches the first instruction of the Interrupt Service Routine (ISR).
Click Play ► to listen to the commentary.
In the ideal condition, where CPU is set to be the highest priority RAM bus main, these are the primary interrupt latency components in this latency flow:
Arbitration and interrupt priority resolution take two cycles.
Instruction execution during exception processing takes one to two cycles, depending on the current instruction.
Vector memory access, or IVT read, takes four to seven cycles (only two cycles if the Interrupt Vector Table (IVT) is in RAM).
Program memory access takes one to seven cycles.
Total latency is the sum of the arbitration, instruction, vector memory access, and program memory access times.

Click Play ► to listen to the commentary.
The dsPIC33A CPU takes about nine to 18 cycles to start executing the first instruction in the ISR after an interrupt is recognized. Stimulus recognition-arbitration time is about three to four cycles, as shown.
At a dsPIC33A CPU clock of 200 MHz, this translates to 45 ns to 90 ns, in which to start executing the first instruction.
If the CPU is set to be the highest priority RAM bus main (BMX register BMXINITPR[31:0] =0x00000000), interrupt response time depends only on the instructions being completed at the time of the interrupt, including any stalls.
If the CPU is not the highest priority bus master, interrupt latency can also be affected by other bus activity, and exception processing may be delayed to allow other masters access to the bus.
Vector fetches are not cached, so access time is consistent.
IVT can be relocated to Flash (4-cycle access) or RAM (2-cycle access).
Interrupt Return Latency
Click Play ► to listen to the commentary.
RETFIE instruction returns the CPU from an ISR. It restores the program counter and status register from the stack. RETFIE switches hardware context based on the interrupt priority level. After RETFIE, the CPU resumes normal execution at the restored address. This process usually takes seven to 10 clock cycles.
- RETFIE Instruction = return from ISR
- RETFIE execution:
- Stacked PC (PC[23:0]) is popped from TOS and restored
- Stack is popped again, and the Status Register (SR) is restored
- RETFIE instruction manages hardware context switching (IPL-based)
- New context is available at the next instruction’s start
- Fetch instruction addressed by restored PC
- RETFIE execution is four cycles