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.

Practice

1.

What is the main purpose of enabling nested interrupts in embedded C?

easy

A. Allow higher priority interrupts to interrupt lower priority ISRs

B. Disable all interrupts during ISR execution

C. Prevent any interrupt from occurring

D. Increase the execution time of all ISRs

Solution

1. Step 1: Understand interrupt priority

   Interrupts have priorities; higher priority interrupts can preempt lower priority ones if nesting is enabled.

2. Step 2: Role of nested interrupts

   Nested interrupts allow a higher priority interrupt to interrupt an ISR of a lower priority interrupt, improving responsiveness.

3. Final Answer:

   Allow higher priority interrupts to interrupt lower priority ISRs -> Option A

4. Quick Check:

   Nested interrupts = higher priority preempts lower priority [OK]

Hint: Nested interrupts let urgent tasks interrupt less urgent ones [OK]

Common Mistakes:

• Thinking nested interrupts disable all interrupts
• Assuming nested interrupts increase ISR execution time
• Believing nested interrupts prevent interrupts

2.

Which of the following code snippets correctly enables nested interrupts inside an ISR in embedded C?

void ISR_Handler(void) {
    // Enable global interrupts
    __enable_irq();
    // ISR code
}

easy

A. __disable_irq(); // disables global interrupts inside ISR

B. sei(); // disables interrupts globally

C. cli(); // disables interrupts globally

D. __enable_irq(); // enables global interrupts inside ISR

Solution

1. Step 1: Identify function to enable interrupts

   In embedded C, __enable_irq() enables global interrupts, allowing nesting.

2. Step 2: Confirm correct usage inside ISR

   Calling __enable_irq() inside ISR allows higher priority interrupts to nest.

3. Final Answer:

   __enable_irq(); // enables global interrupts inside ISR -> Option D

4. Quick Check:

   __enable_irq() enables interrupts inside ISR [OK]

Hint: Use __enable_irq() inside ISR to allow nesting [OK]

Common Mistakes:

• Using __disable_irq() which disables interrupts
• Confusing cli() and sei() functions
• Not enabling interrupts inside ISR

3.

Consider the following code snippet in embedded C where nested interrupts are enabled:

volatile int count = 0;

void ISR_LowPriority(void) {
    __enable_irq();
    for(int i = 0; i < 5; i++) {
        count++;
    }
}

void ISR_HighPriority(void) {
    count += 10;
}

int main() {
    // Assume interrupts are configured and enabled
    while(1) {}
}

If ISR_HighPriority interrupts ISR_LowPriority exactly once during the loop, what is the final value of count after ISR_LowPriority finishes?

medium

A. 10

B. 5

C. 15

D. 20

Solution

1. Step 1: Analyze ISR_LowPriority increments

   ISR_LowPriority increments count 5 times, so count increases by 5.

2. Step 2: Account for ISR_HighPriority interrupt

   ISR_HighPriority adds 10 to count during ISR_LowPriority execution.

3. Step 3: Calculate final count

   Count = 5 (from low priority) + 10 (from high priority) = 15.

4. Final Answer:

   15 -> Option C

5. Quick Check:

   5 + 10 = 15 [OK]

Hint: Add increments from both ISRs considering nesting [OK]

Common Mistakes:

• Ignoring the interrupt during the loop
• Counting only one ISR's increments
• Assuming interrupts don't nest

4.

Given the following ISR code, identify the error that prevents nested interrupts from working correctly:

void ISR_Handler(void) {
    // ISR code
    __disable_irq();
    // Critical section
    __enable_irq();
}

medium

A. __disable_irq() disables interrupts inside ISR, preventing nesting

B. Missing __enable_irq() call to enable interrupts inside ISR

C. ISR_Handler should not contain any interrupt control calls

D. __enable_irq() disables interrupts instead of enabling

Solution

1. Step 1: Understand effect of __disable_irq()

   Calling __disable_irq() inside ISR disables global interrupts, blocking nesting.

2. Step 2: Check interrupt enabling

   Although __enable_irq() is called later, interrupts remain disabled during critical section, so nesting is blocked.

3. Final Answer:

   __disable_irq() disables interrupts inside ISR, preventing nesting -> Option A

4. Quick Check:

   Disabling interrupts inside ISR blocks nesting [OK]

Hint: Avoid disabling interrupts inside ISR to allow nesting [OK]

Common Mistakes:

• Thinking __disable_irq() enables interrupts
• Assuming __enable_irq() disables interrupts
• Believing ISR should never control interrupts

5.

You have two interrupts: ISR_A with priority 1 and ISR_B with priority 2 (2 is higher). You want ISR_B to interrupt ISR_A when it occurs. Which of the following is the correct approach to implement nested interrupts in embedded C?

void ISR_A(void) {
    // Enable nested interrupts
    __enable_irq();
    // ISR_A code
}

void ISR_B(void) {
    // ISR_B code
}

hard

A. Set ISR_A priority higher than ISR_B to allow nesting

B. Enable global interrupts inside ISR_A using __enable_irq() to allow ISR_B nesting

C. Call ISR_B manually inside ISR_A to simulate nesting

D. Disable global interrupts inside ISR_A to prevent ISR_B nesting

Solution

1. Step 1: Understand priority and nesting

   Higher priority ISR_B (priority 2) should interrupt lower priority ISR_A (priority 1).

2. Step 2: Enable nested interrupts inside ISR_A

   Calling __enable_irq() inside ISR_A allows ISR_B to interrupt ISR_A.

3. Step 3: Avoid disabling interrupts or wrong priority settings

   Disabling interrupts or reversing priorities prevents correct nesting.

4. Final Answer:

   Enable global interrupts inside ISR_A using __enable_irq() to allow ISR_B nesting -> Option B

5. Quick Check:

   Enable interrupts inside lower priority ISR for nesting [OK]

Hint: Enable interrupts inside lower priority ISR to allow higher priority nesting [OK]

Common Mistakes:

• Disabling interrupts inside ISR_A
• Manually calling ISR_B instead of nesting
• Setting wrong priority order