STM32 Series #8: Understanding Interrupts — Vector Table, NVIC, Context Saving, and TIM2 Implementation

In Episode 7 we acquired the tool to measure execution time using DWT CYCCNT. We could measure — but the CPU was still passive.

“I want to read a sensor every 1ms” — doing this with polling requires a loop that constantly watches HAL_GetTick(). While that loop runs, the CPU can do nothing else.

Interrupts transform the CPU from passive to proactive.

“Force the CPU to respond when something happens” — understanding this mechanism is the true starting point for an embedded engineer who wants to master time.

In this episode we’ll understand “what an interrupt really is” at the mechanism level, then implement a 1ms periodic event generator using TIM2 timer interrupts.

Table of Contents

1. The Limits of Polling (STM32 perspective)
2. What Is an Interrupt — The Big Picture
3. How the Vector Table Works
4. NVIC — The Priority and Permission Manager
5. Context Saving — What the CPU Does Automatically
6. Implementing TIM2 Interrupts
7. Shared Variables in ISRs (volatile and a Teaser for Next Time)
8. Summary

⏳ The Limits of Polling (STM32 perspective)

The Cost of “Waiting”

HAL_Delay(1) — which we measured in Episode 7 — is a function that “waits at least 1ms.” What is the CPU actually doing during that wait?

/* HAL_Delay internal implementation (simplified) */
void HAL_Delay(uint32_t Delay)
{
    uint32_t tickstart = HAL_GetTick();
    while ((HAL_GetTick() - tickstart) < Delay)
    {
        /* ← CPU spins here doing absolutely nothing */
    }
}

The CPU does nothing but check a counter, spending roughly 84,000 cycles on standby.

This is polling — continuously checking state at regular intervals. It’s simple, but has real drawbacks:

Writing “read sensor every 1ms” with polling

/* ❌ Periodic processing via polling — CPU hammers GetTick() full-time */
uint32_t last_tick = 0;

while (1)
{
    if (HAL_GetTick() - last_tick >= 1)   /* Has 1ms elapsed? */
    {
        last_tick = HAL_GetTick();
        read_sensor();   /* Read sensor */
    }

    /* ↑ The CPU calls GetTick() on every iteration */
    /* Even if there's other work, it must pass through here */
}

Every time you add another task (comms, display, computation), the loop takes longer to complete. The 1ms precision degrades gradually.

Interrupts solve this at the root.

⚡ What Is an Interrupt — The Big Picture

“Answer the phone without forgetting where you were”

In one sentence: an interrupt is “a mechanism by which hardware forces the CPU to ‘handle this right now.’”

Normal execution:
  CPU: running main()...
           ↓
  Timer completes 1ms count!
           ↓
  CPU: suspend main(), save state to stack
           ↓
  CPU: execute TIM2_IRQHandler()
           ↓
  CPU: done, restore state from stack
           ↓
  CPU: resume main() from where it stopped

The analogy: “You’re working, the phone rings, you jot down where you were, answer it, then pick up right where you left off.”

Polling vs Interrupts

Interrupt Sources on STM32

The STM32F401RE has two major categories of interrupt sources:

SysTick is itself a kind of interrupt — the HAL library uses it to update its tick counter every 1ms. In this episode we’ll use the TIM2 timer interrupt.

📋 How the Vector Table Works

“The map of where to jump for each interrupt”

When an interrupt fires, the CPU needs to know where to jump. The answer is the vector table.

The vector table is an array of function pointers placed at the start of Flash (address 0x08000000):

Address       Content                      Meaning
0x08000000   Initial stack pointer value   Sets SP on startup
0x08000004   Address of Reset_Handler      Jump target on power-on
0x08000008   Address of NMI_Handler        Non-Maskable Interrupt
0x0800000C   Address of HardFault_Handler  On HardFault
0x08000010   MemManage_Handler             MPU violation
0x08000014   BusFault_Handler              Bus error
0x08000018   UsageFault_Handler            Illegal instruction
...  (4 bytes each)
0x080000B8   Address of TIM2_IRQHandler    TIM2 overflow/compare
...

When an interrupt fires, the CPU automatically:

1. Saves the current execution state to the stack (context saving)
2. Reads the corresponding function pointer from the vector table
3. Jumps to that address and executes the ISR (Interrupt Service Routine)
4. When the ISR returns, restores the saved state and resumes where it left off

/* Part of the vector table defined in startup_stm32f401retx.s */
/* Auto-generated by CubeIDE when creating a project */

g_pfnVectors:
    .word  _estack              /* Initial stack pointer */
    .word  Reset_Handler        /* Reset */
    .word  NMI_Handler          /* NMI */
    .word  HardFault_Handler    /* HardFault */
    /* ... omitted ... */
    .word  TIM2_IRQHandler      /* TIM2 */

Vector Numbers and IRQ Numbers

The first 16 entries in the Cortex-M vector table are “core exceptions” (Reset, NMI, HardFault, etc.). Everything after is STM32-specific peripheral interrupts (IRQs).

Vector number   IRQ number (NVIC-managed)   Meaning
0–15            — (core exceptions)          Reset, NMI, HardFault, SysTick, etc.
16–             IRQ0–                        Peripheral interrupts (TIM2 = IRQ28)

TIM2 corresponds to vector 44 (= 16 + 28), with IRQ number 28.

🔧 NVIC — The Priority and Permission Manager

What is NVIC?

The NVIC (Nested Vectored Interrupt Controller) is a hardware module built into Cortex-M that handles interrupt priority management, enabling, disabling, and pending-bit clearing.

“Which interrupts are allowed?” “When multiple interrupts arrive simultaneously, which runs first?” — the NVIC decides all of this. The NVIC is also a scheduler that determines which interrupt runs and when.

How Priority Works

The STM32F401RE uses 4 bits (0–15) to set priority. Lower number = higher priority.

Priority 0  ← Strongest (can preempt any other ISR)
Priority 1
...
Priority 15 ← Weakest (preempted by everything)

Remember: “0 is strongest, 15 is weakest.” Many CPUs use the opposite convention (higher number = higher priority), so this is a classic source of configuration bugs on STM32.

What Happens When Multiple Interrupts Overlap

“If a low-priority interrupt arrives while a high-priority ISR is running, does it get cancelled?” — a critical question. The answer is no.

The NVIC records every interrupt arrival as a Pending bit. Even if the interrupt can’t be handled immediately, the “it arrived” fact stays in the flag and will execute as soon as conditions allow.

Case 1: High-priority interrupt arrives during a low-priority ISR (Preemption)

Low-priority ISR (priority 2) running
        ↓
High-priority interrupt (priority 0) fires!
        ↓
Suspend low-priority ISR → save state to stack (context saving)
        ↓
Execute high-priority ISR (priority 0)
        ↓
High-priority ISR returns
        ↓
Resume low-priority ISR (restore state from stack)
        ↓
Low-priority ISR returns → back to main()

This is called preemption — the high-priority interrupt doesn’t wait for the low-priority ISR to finish. Because ISRs nest, stack consumption requires attention.

How the stack builds up during nesting:

Each context save consumes at least 32 bytes (8 registers × 4 bytes). If the ISR also uses R4–R11, it’s more. Deeper nesting = more stack consumed.

What happens when the stack is full (stack overflow):

The STM32F401RE’s stack size is determined by the linker script, defaulting to 0x200 (512 bytes). Too-deep nesting or large ISR local variables causes the stack to overwrite other memory regions (globals, heap).

When a stack overflow occurs:
  → Global variables are silently corrupted (hard to notice)
  → Eventually HardFault or MPU Fault fires and halts execution
  → Debugging becomes very difficult (the crash site and the cause are far apart)

Case 2: Low-priority interrupt arrives during a high-priority ISR (Pending)

High-priority ISR (priority 0) running
        ↓
Low-priority interrupt (priority 2) fires!
        ↓
NVIC sets the Pending bit (just records "it arrived")
High-priority ISR continues uninterrupted
        ↓
High-priority ISR returns
        ↓
NVIC detects Pending bit → executes low-priority ISR
        ↓
Low-priority ISR returns → back to main()

The low-priority interrupt is not cancelled — it stays pending and executes automatically as soon as the high-priority ISR finishes.

Case 3: Same-priority interrupts overlap

Same-priority interrupts cannot preempt each other. The later arrival stays Pending until the running ISR finishes. Which runs first is determined by vector number (lower = higher priority).

NVIC Operations (CMSIS API)

/* NVIC functions provided by CMSIS */

/* ① Set priority */
NVIC_SetPriority(TIM2_IRQn, 1);   /* Set TIM2 to priority 1 */

/* ② Enable interrupt */
NVIC_EnableIRQ(TIM2_IRQn);        /* Allow TIM2 IRQ in NVIC */

/* ③ Disable interrupt */
NVIC_DisableIRQ(TIM2_IRQn);

/* ④ Clear pending interrupt */
NVIC_ClearPendingIRQ(TIM2_IRQn);

HAL_NVIC_SetPriority(TIM2_IRQn, 1, 0);   /* preemption=1, sub=0 */
HAL_NVIC_EnableIRQ(TIM2_IRQn);

Global Interrupt Mask (enable/disable everything)

Separate from per-IRQ NVIC settings, there’s a global mask for all CPU interrupts:

__disable_irq();   /* PRIMASK = 1: disable all interrupts */
/* critical section, measurement, etc. */
__enable_irq();    /* PRIMASK = 0: re-enable interrupts */

🗂️ Context Saving — What the CPU Does Automatically

“Everything needed to pause and resume cleanly”

When an interrupt fires, the CPU suspends the current task and jumps to the ISR. To resume exactly where it left off after the ISR returns, the CPU must completely save its state at the moment of interruption.

This is context saving.

Registers Cortex-M saves automatically

At interrupt time, Cortex-M hardware automatically pushes these 8 registers onto the stack:

Registers pushed to stack on interrupt (hardware-automatic):

Stack (RAM)          Register    Description
+------------------+
| xPSR             |   Program Status Register (flags)
| PC (Return addr) |   Address of suspended instruction (resume point)
| LR               |   Link Register (caller address)
| R12              |   General-purpose register
| R3               |   General-purpose register
| R2               |   General-purpose register
| R1               |   General-purpose register
| R0               |   General-purpose register  ← SP points here
+------------------+
(older contents below)

When the ISR returns, the CPU automatically restores all of these, and the program counter (PC) resumes execution from the saved address.

The Cost of Context Saving

How many cycles does this stack operation take? You can measure it with DWT CYCCNT from Episode 7.

On the STM32F401RE (84 MHz), interrupt entry overhead is typically 12 to tens of cycles (roughly 0.14 to a few µs). Keeping this number in mind helps when reasoning about ISR execution time.

Interrupt entry breakdown:
  ① NVIC detects interrupt               a few cycles
  ② Hardware saves 8 registers to stack  ~8–12 cycles
  ③ Read vector table                    1 to a few cycles
  ④ Jump to ISR                          1 cycle
  Total: at minimum ~12–16 cycles
  * Flash wait states, cache state, bus contention can push this to tens of cycles

Tail-Chaining and Late Arrival (Cortex-M speed optimizations)

Cortex-M has two hardware optimizations that accelerate interrupt handling. Worth knowing so that real measurements make intuitive sense.

Tail-Chaining

If another interrupt is Pending at the moment one ISR finishes, rather than popping the stack and immediately pushing it again, the CPU skips the stack round-trip and jumps directly to the next ISR.

Without tail-chaining:
  ISR-A done → pop stack (8 regs) → ISR-B starts → push stack (8 regs)

With tail-chaining:
  ISR-A done → jump directly to ISR-B (no stack operation)

Back-to-back interrupts switch in as few as 6 cycles — useful when TIM2 at 1ms and UART receive fire consecutively.

Late Arrival

If a higher-priority interrupt arrives while the CPU is still in the middle of saving context (hasn’t entered any ISR yet), it redirects the jump to the higher-priority ISR. No re-saving cost — the higher-priority ISR starts at maximum speed.

These happen automatically; you don’t need to think about them. But when multiple interrupts are queued and processing is faster than you expected, this mechanism is why.

⏰ Implementing TIM2 Interrupts

Overview: Generating a 1ms periodic interrupt with TIM2

The implementation sequence:

① Configure TIM2 (prescaler, counter limit)
② Enable TIM2 interrupt (UEV: Update Event)
③ Register TIM2_IRQn in NVIC, set priority
④ Start TIM2
⑤ Write TIM2_IRQHandler()
⑥ Clear the interrupt flag (critical!)

How TIM2 Works

TIM2 is a 16/32-bit up-counter. It increments by 1 on each clock edge. When it reaches the configured limit (ARR: Auto-Reload Register), a UEV (Update Event) fires and the counter resets to 0.

TIM2 counter behavior:

0 → 1 → 2 → ... → ARR → (UEV fires, interrupt!) → 0 → 1 → ...
                                                    ↑
                                               ISR runs here

Period formula:

• PSC: Prescaler value (divides TIM2 clock)
• ARR: Auto-reload value (count limit)
• f_TIM: Clock frequency supplied to TIM2

Calculating Parameters for 1ms Period

The timer period is determined by:

Substituting the values from CubeMX Parameter Settings:

Exactly 1 ms. The +1 on PSC and ARR is because register values are 0-indexed counters (PSC=0 means divide-by-1, ARR=0 means overflow after 1 count).

Implementation (Direct Register Access)

/* Place in main.c USER CODE BEGIN PD */

/* DWT macros (from Episode 7) */
#define DWT_INIT() do { \
    CoreDebug->DEMCR |= CoreDebug_DEMCR_TRCENA_Msk; \
    DWT->CYCCNT = 0; \
    DWT->CTRL |= DWT_CTRL_CYCCNTENA_Msk; \
} while(0)
#define DWT_START()        (DWT->CYCCNT)
#define DWT_CYCLES(start)  (DWT->CYCCNT - (start))


/* Place in main.c USER CODE BEGIN 0 */

/* Flags shared from ISR to main (volatile required) */
volatile uint32_t g_tim2_tick = 0;       /* incremented every 1ms */
volatile uint32_t g_isr_cycle_count = 0; /* ISR execution cycles (for measurement) */

/* TIM2 interrupt handler */
void TIM2_IRQHandler(void)
{
    uint32_t isr_start = DWT_START();

    /* ① Clear interrupt flag (mandatory! Without this, ISR loops forever) */
    TIM2->SR &= ~TIM_SR_UIF;

    /* ② Increment flag (let main do the heavy lifting) */
    g_tim2_tick++;

    /* ③ Measure ISR execution time (for debugging) */
    g_isr_cycle_count = DWT_CYCLES(isr_start);
}

/* Place in main.c USER CODE BEGIN 2 */

/* Initialize DWT (for measurement) */
DWT_INIT();

/* ─── TIM2 initialization (direct register access) ──────── */

/* ① Supply clock to TIM2 via RCC */
RCC->APB1ENR |= RCC_APB1ENR_TIM2EN;

/* ② Reset TIM2 to a known state */
TIM2->CR1 = 0;

/* ③ Prescaler: divide by 84 → TIM2 clock = 1 MHz */
TIM2->PSC = 84 - 1;   /* PSC = 83 */

/* ④ Auto-reload value: 1000 counts → 1ms period */
TIM2->ARR = 1000 - 1;   /* ARR = 999 */

/* ⑤ Enable UEV (Update Event) interrupt */
TIM2->DIER |= TIM_DIER_UIE;

/* ─── NVIC configuration ─────────────────────────────────── */

/* ⑥ Set TIM2 IRQ priority (0–15, lower = higher priority) */
NVIC_SetPriority(TIM2_IRQn, 1);

/* ⑦ Enable TIM2 IRQ in NVIC */
NVIC_EnableIRQ(TIM2_IRQn);

/* ─── Start TIM2 ──────────────────────────────────────────── */

/* ⑧ Set CEN bit to start TIM2 counting */
TIM2->CR1 |= TIM_CR1_CEN;

/* Place in main.c USER CODE BEGIN WHILE (inside while(1)) */

uint32_t last_tick = 0;

while (1)
{
    /* Wait for g_tim2_tick to change (process on main-loop side) */
    if (g_tim2_tick != last_tick)
    {
        last_tick = g_tim2_tick;

        /* This runs every 1ms */
        HAL_GPIO_TogglePin(GPIOA, GPIO_PIN_5);   /* Toggle LD2 (PA5) */
    }
}

Comparison: HAL Version

Using CubeMX, the same functionality looks like this:

/* HAL version (using CubeMX-generated code) */

/* Code auto-generated in MX_TIM2_Init() */
htim2.Instance = TIM2;
htim2.Init.Prescaler = 84 - 1;
htim2.Init.CounterMode = TIM_COUNTERMODE_UP;
htim2.Init.Period = 1000 - 1;
htim2.Init.ClockDivision = TIM_CLOCKDIVISION_DIV1;
HAL_TIM_Base_Init(&htim2);

/* USER CODE BEGIN 2 */
HAL_TIM_Base_Start_IT(&htim2);   /* Start TIM2 with interrupt */

/* TIM2_IRQHandler in stm32f4xx_it.c (auto-generated) */
void TIM2_IRQHandler(void)
{
    HAL_TIM_IRQHandler(&htim2);   /* Flag clearing handled internally */
}

/* Callback — write this yourself */
void HAL_TIM_PeriodElapsedCallback(TIM_HandleTypeDef *htim)
{
    if (htim->Instance == TIM2)
    {
        g_tim2_tick++;   /* Called every 1ms */
    }
}

Verifying the Result

Watch g_tim2_tick in the debugger and wait 1 second — it should read approximately 1000, confirming near-exact 1ms precision.

Checking g_isr_cycle_count reveals the ISR body’s cycle count (flag clear + counter increment):

g_isr_cycle_count ≈ 8–12 cycles (~0.1–0.15 µs)

Including interrupt entry overhead:
Total interrupt processing ≈ 20–30 cycles (~0.25–0.36 µs)
As a fraction of 1ms = 84,000 cycles: interrupt cost ≈ 0.03%

For a 1ms period (84,000 cycles), an interrupt overhead under 30 cycles is negligible. That said, for high-frequency interrupts (period below tens of µs) or RTOS environments, the overhead becomes non-trivial.

⚠️ Shared Variables in ISRs (volatile and a Teaser for Next Time)

Why is volatile required?

Did you notice the volatile on g_tim2_tick?

volatile uint32_t g_tim2_tick = 0;   /* volatile is mandatory */

Recall the optimization bug from Episode 6. Without volatile, at -O2 optimization:

Inside main()'s while(1) loop:

At -O0:
  Reads g_tim2_tick from RAM every iteration → sees ISR changes ✅

At -O2:
  Compiler sees "no code in this loop modifies g_tim2_tick"
  → reads it once into a register and caches it there forever
  → ISR writes to RAM, but main never re-reads → infinite loop ❌

volatile tells the compiler “this memory can change at any time without my knowledge.” Apply it to any variable written by an ISR, DMA, or hardware peripheral.

Atomicity (teaser for next time)

But volatile alone is sometimes not enough:

/* ❌ A 32-bit variable read/write may not be atomic (multi-byte update concern) */
volatile uint32_t g_sensor_value = 0;

/* Inside ISR */
void TIM2_IRQHandler(void) {
    TIM2->SR &= ~TIM_SR_UIF;
    g_sensor_value = read_sensor();   /* 32-bit write */
}

/* In main */
uint32_t val = g_sensor_value;   /* 32-bit read */
/* ← What if the ISR write and this read overlap? */

The Cortex-M4 is a 32-bit CPU, so reading or writing an aligned uint32_t completes in one instruction (LDR/STR) — one instruction cannot be interrupted midway. That’s the physical meaning of atomic. Think of it the same way as “the weight of one cycle” from Episode 7: “a 32-bit CPU moves 32 bits in one shot.” “Aligned” means the address is a multiple of 4, which compilers guarantee automatically for normal global and local variables.

However, 64-bit variables, structs, or updating multiple variables together cannot be done in a single instruction and are not atomic.

/* ❌ Updating multiple variables "together" — an ISR can slip in between */
volatile uint32_t g_timestamp = 0;
volatile uint32_t g_value = 0;

/* In ISR */
g_timestamp = current_time;   /* ← ISR could be interrupted here */
g_value = new_value;           /* main reads only the new timestamp with old value */

Preventing this requires a critical section (interrupt-disabled region). Episode 9’s anti-pattern collection covers this thoroughly.

Summary

Key takeaways from this episode:

1. Limits of polling → Monopolizes CPU, poor precision, breaks as tasks grow
2. Interrupt fundamentals → Hardware forces CPU to “handle this now”
3. Vector table → An array of ISR addresses at the start of Flash; the CPU reads it on every interrupt
4. NVIC → Hardware controller managing priority, enable, and pending-clear
5. Context saving → CPU automatically pushes 8 registers to stack on interrupt, restores them on return
6. TIM2 implementation → Set period with PSC/ARR, never forget to clear the UIF flag
7. volatile requirement → Any variable shared with an ISR must be volatile

Next up: “Interrupt Design Anti-Pattern Collection” — doing printf in an ISR, putting heavy processing in an ISR, forgetting volatile. We’ll deliberately trigger these common landmines and watch things break.

What’s Next

FAQ

Q. Should I use interrupts or polling?

Use interrupts when timing precision matters (µs level) or when you need to run tasks in parallel. Polling is fine when timing doesn’t need to be exact and simplicity is a priority. “Avoid interrupts if you can get away without them” is a valid design heuristic.

Q. Can I call printf (UART send) from inside an ISR?

Principally no. UART transmission tends to be blocking, making the ISR take much longer and blocking other interrupts. HAL UART functions also use internal wait loops, which can cause deadlocks inside an ISR. Use LED toggling or DWT-based measurement for debug output instead. Episode 9 covers this in detail.

Q. My interrupt won’t stop (can’t return to main()) — what’s wrong?

Almost always a forgotten flag clear inside the ISR. Check that you have TIM2->SR &= ~TIM_SR_UIF; (or equivalent) at the top of your ISR.

Q. What priority value should I use?

Start with 1 (fairly high). SysTick (used by HAL) defaults to priority 0, so setting TIM2 to 0 risks competing with it. Priority 1 or higher is the safe default.

Q. HAL or direct register access — which should I use?

In production, HAL is safer and more maintainable. But writing the register version by hand at least once gives you an understanding of what HAL is doing internally, which dramatically improves debugging ability when things go wrong.

Related Articles

• Episode 7: The World of Time — Knowing the Weight of a Single Cycle
• Episode 6: The Complete Pointer Accident Handbook
• Full 13-Part Series: The Embedded World Beyond Pointers