Nested interrupts in Embedded C - Step-by-Step Execution

Concept Flow - Nested interrupts

Main program running

↓

Interrupt 1 occurs

↓

Interrupt 1 handler starts

↓

Interrupt 2 occurs (higher priority)

↓

Interrupt 2 handler starts

↓

Interrupt 2 handler ends

↓

Resume Interrupt 1 handler

↓

Interrupt 1 handler ends

↓

Resume main program

The main program runs until an interrupt occurs. If a higher priority interrupt happens during an interrupt handler, it interrupts that handler. After the higher priority handler finishes, the previous handler resumes, then the main program continues.

Execution Sample

Embedded C

volatile int flag1 = 0;
volatile int flag2 = 0;

void ISR1() {
  flag1 = 1;
  // Higher priority interrupt can occur here
  flag1 = 2;
}

void ISR2() {
  flag2 = 1;
}

This code shows two interrupt service routines (ISR1 and ISR2). ISR2 has higher priority and can interrupt ISR1.

Execution Table

Step	Event	Current Context	Action	Variable Changes
1	Main program running	Main	Running main code	flag1=0, flag2=0
2	Interrupt 1 occurs	Main	Enter ISR1	flag1=0, flag2=0
3	ISR1 sets flag1=1	ISR1	flag1=1	flag1=1, flag2=0
4	Interrupt 2 occurs (higher priority)	ISR1	Preempt ISR1, enter ISR2	flag1=1, flag2=0
5	ISR2 sets flag2=1	ISR2	flag2=1	flag1=1, flag2=1
6	ISR2 ends	ISR2	Return to ISR1	flag1=1, flag2=1
7	ISR1 resumes, sets flag1=2	ISR1	flag1=2	flag1=2, flag2=1
8	ISR1 ends	ISR1	Return to main	flag1=2, flag2=1
9	Main program resumes	Main	Continue main code	flag1=2, flag2=1

💡 All interrupts handled, main program resumes normal execution

Variable Tracker

Variable	Start	After Step 3	After Step 5	After Step 7	Final
flag1	0	1	1	2	2
flag2	0	0	1	1	1

Key Moments - 3 Insights

Why does ISR2 interrupt ISR1 even though ISR1 is already running?

Because ISR2 has higher priority, it can preempt ISR1 as shown at step 4 in the execution_table.

What happens to the variables when ISR2 interrupts ISR1?

Variables keep their values during the interrupt. flag1 remains 1 when ISR2 starts (step 4), and flag2 changes only in ISR2 (step 5).

How does the program know to resume ISR1 after ISR2 finishes?

The processor saves ISR1's state when ISR2 interrupts, then restores it after ISR2 ends, as seen between steps 6 and 7.

Visual Quiz - 3 Questions

Look at the execution_table, what is the value of flag1 right after ISR2 starts (step 4)?

A 2

B 0

C 1

D Undefined

💡 Hint

Check the 'Variable Changes' column at step 4 in the execution_table.

At which step does the main program resume after handling interrupts?

A Step 9

B Step 8

C Step 6

D Step 7

💡 Hint

Look for 'Main program resumes' in the 'Event' column of the execution_table.

If ISR2 had lower priority than ISR1, what would happen at step 4?

A ISR2 would preempt ISR1 anyway

B ISR2 would wait until ISR1 finishes

C ISR1 would stop and never resume

D Both ISRs run simultaneously

💡 Hint

Refer to the concept_flow where higher priority interrupts preempt lower priority ones.

Concept Snapshot

Nested interrupts allow higher priority interrupts to interrupt lower priority ones.
The processor saves the current interrupt state before handling the higher priority one.
After the higher priority ISR finishes, the previous ISR resumes.
This ensures urgent tasks get immediate attention without losing progress on others.
Variables keep their values during nested interrupts.
Proper priority configuration is essential to avoid conflicts.

Full Transcript

Nested interrupts happen when a higher priority interrupt occurs while a lower priority interrupt is running. The processor pauses the current interrupt handler and runs the higher priority one. After finishing, it resumes the paused handler. This example shows two flags changed by two ISRs. The main program runs until interrupted. ISR1 starts and sets flag1 to 1. Then ISR2 interrupts ISR1 and sets flag2 to 1. After ISR2 ends, ISR1 resumes and sets flag1 to 2. Finally, the main program continues with updated flags. This process ensures urgent interrupts get immediate attention without losing the previous interrupt's progress.