Interrupt vector table in Embedded C - Deep Dive

Overview - Interrupt vector table

What is it?

An interrupt vector table is a special list in a microcontroller or processor that tells it where to find the code to run when an interrupt happens. Each entry in this table points to a function called an interrupt service routine (ISR), which handles a specific interrupt. When an interrupt occurs, the processor looks up the address in this table and jumps to the corresponding ISR. This helps the processor respond quickly to important events like timers, input signals, or errors.

Why it matters

Without an interrupt vector table, the processor wouldn't know which code to run when an interrupt occurs, causing delays or missed events. This would make devices slow or unreliable, especially in real-time systems like medical devices, cars, or home appliances. The interrupt vector table ensures fast, organized, and predictable responses to hardware events, making embedded systems efficient and safe.

Where it fits

Before learning about interrupt vector tables, you should understand basic microcontroller architecture and how interrupts work. After this, you can learn about writing interrupt service routines, configuring interrupts, and advanced topics like nested interrupts or interrupt priorities.

Mental Model

Core Idea

The interrupt vector table is a map that directs the processor to the right handler code instantly when an interrupt happens.

Think of it like...

Imagine a receptionist with a list of phone numbers for different departments. When a call (interrupt) comes in, the receptionist quickly looks up the right department's number (ISR address) and connects the call immediately.

┌───────────────────────────────┐
│ Interrupt Vector Table         │
├─────────────┬─────────────────┤
│ Interrupt # │ ISR Address     │
├─────────────┼─────────────────┤
│ 0           │ 0x00001000      │
│ 1           │ 0x00001020      │
│ 2           │ 0x00001040      │
│ ...         │ ...             │
└─────────────┴─────────────────┘

Processor uses interrupt number to jump to ISR address.

Build-Up - 7 Steps

1

Foundation

What is an Interrupt?

Concept: Introduce the basic idea of interrupts as signals that pause normal code to handle urgent tasks.

An interrupt is like a signal sent to the processor to stop what it's doing and pay attention to something important. For example, when you press a button, the processor needs to react quickly. Instead of checking the button all the time, the processor waits for an interrupt signal. When it gets one, it pauses the current work and runs special code to handle the event.

Result

You understand that interrupts let the processor respond quickly to events without wasting time checking constantly.

Knowing what interrupts are helps you see why a system needs a fast way to find the right code to handle them.

2

Foundation

Interrupt Service Routine (ISR) Basics

Concept: Explain what an ISR is and how it relates to interrupts.

An Interrupt Service Routine (ISR) is a small piece of code that runs when an interrupt happens. It tells the processor what to do for that specific event, like reading a sensor or clearing a flag. ISRs must be fast and efficient because they pause the main program.

Result

You know that ISRs are special functions triggered by interrupts to handle events.

Understanding ISRs clarifies why the processor needs a way to find and run them quickly.

3

Intermediate

Structure of the Interrupt Vector Table

Concept: Show how the interrupt vector table organizes ISR addresses for quick lookup.

The interrupt vector table is a fixed list stored in memory, usually at a known address. Each entry corresponds to an interrupt number and holds the address of its ISR. When an interrupt occurs, the processor uses the interrupt number as an index to find the ISR address in this table and jumps there.

Result

You see how the processor uses the table to quickly find the right ISR without searching.

Knowing the table's structure explains how interrupt handling is fast and organized.

4

Intermediate

How the Processor Uses the Vector Table

🤔Before reading on: do you think the processor copies the ISR code or jumps to it directly? Commit to your answer.

Concept: Explain the processor's action when an interrupt occurs, focusing on jumping to the ISR address from the table.

When an interrupt happens, the processor stops the current program and looks up the ISR address in the interrupt vector table using the interrupt number. It then jumps directly to that address to run the ISR. After the ISR finishes, the processor returns to where it left off.

Result

You understand the processor jumps to the ISR address from the table, not copying code.

Knowing the jump mechanism helps you understand how interrupts cause minimal delay.

5

Intermediate

Common Vector Table Layouts

Concept: Introduce variations in vector table layouts across different processors.

Different microcontrollers store the interrupt vector table differently. Some use a table of addresses (pointers), others use direct jump instructions. Some tables start at address zero, others at a fixed high address. Knowing your processor's layout is important for correct ISR setup.

Result

You can identify how your processor organizes its vector table and why it matters.

Recognizing layout differences prevents errors when configuring interrupts on various hardware.

6

Advanced

Relocating the Interrupt Vector Table

🤔Before reading on: do you think the vector table can be moved during runtime or is it fixed? Commit to your answer.

Concept: Explain how some systems allow moving the vector table to different memory locations.

Some processors let you relocate the interrupt vector table to RAM or other memory areas. This allows dynamic changes to ISR addresses, useful for bootloaders or operating systems. To relocate, you change a special register pointing to the new table location.

Result

You learn that vector tables can be moved to support flexible interrupt handling.

Understanding relocation reveals how advanced systems manage interrupts dynamically.

7

Expert

Vector Table and Nested Interrupts Handling

🤔Before reading on: do you think the vector table changes during nested interrupts? Commit to your answer.

Concept: Explore how the vector table works with nested interrupts and priorities.

When interrupts can interrupt other interrupts (nested), the vector table remains the same, but the processor uses priority rules to decide which ISR runs first. The vector table provides ISR addresses, but the processor's interrupt controller manages priorities and masking. This separation allows complex interrupt handling without changing the vector table.

Result

You understand that the vector table is static while interrupt controllers handle nesting and priorities.

Knowing this separation helps avoid confusion about vector table role in complex interrupt scenarios.

Under the Hood

The interrupt vector table is stored at a fixed memory location known to the processor. When an interrupt occurs, the processor hardware uses the interrupt number as an index to fetch the ISR address from this table. It then saves the current program counter and processor state, jumps to the ISR address, and executes the ISR. After the ISR completes, the processor restores the saved state and resumes the interrupted program. This process is handled by the processor's interrupt controller and hardware logic, ensuring minimal delay.

Why designed this way?

The vector table design provides a fast, direct way to find ISR addresses without searching or complex logic. Early microcontrollers had limited memory and processing power, so a simple fixed table was efficient and reliable. Alternatives like dynamic ISR lookup would slow down interrupt response. The fixed table also simplifies hardware design and software development, making interrupt handling predictable and fast.

┌───────────────────────────────┐
│ Interrupt Occurs              │
├───────────────┬───────────────┤
│ Interrupt #   │ 3             │
├───────────────┴───────────────┤
│ Processor uses # as index      │
│ to vector table address       │
├───────────────────────────────┤
│ Vector Table Entry #3          │
│ ┌───────────────────────────┐ │
│ │ ISR Address: 0x00001060    │ │
│ └───────────────────────────┘ │
├───────────────────────────────┤
│ Processor saves state          │
│ Jumps to ISR address           │
│ Executes ISR                   │
│ Restores state                │
│ Resumes main program          │
└───────────────────────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does the interrupt vector table contain the actual ISR code? Commit yes or no.

Common Belief: The vector table holds the actual code of the interrupt service routines.

Reality: The vector table only holds addresses (pointers) to the ISR code, not the code itself.

Why it matters: Thinking the table contains code can lead to confusion about memory layout and cause errors when trying to modify ISRs.

Quick: Can you change the vector table entries at any time during program execution? Commit yes or no.

Common Belief: The interrupt vector table is fixed and cannot be changed after program start.

Reality: Some processors allow relocating or modifying the vector table at runtime, especially when placed in RAM.

Why it matters: Believing the table is fixed limits advanced uses like bootloaders or dynamic ISR assignment.

Quick: Does the processor search through the vector table sequentially to find the ISR? Commit yes or no.

Common Belief: The processor searches the vector table from start to end to find the correct ISR address.

Reality: The processor uses the interrupt number as an index to directly access the ISR address without searching.

Why it matters: Misunderstanding this can lead to wrong assumptions about interrupt latency and performance.

Quick: Does the vector table handle interrupt priorities and nesting? Commit yes or no.

Common Belief: The vector table manages interrupt priorities and nested interrupts.

Reality: The vector table only holds ISR addresses; interrupt priorities and nesting are managed by separate hardware controllers.

Why it matters: Confusing these roles can cause mistakes in designing interrupt handling and debugging complex interrupt behavior.

Expert Zone

1

Some processors use a vector table with jump instructions instead of raw addresses, which affects how ISRs are linked and relocated.

2

In systems with multiple cores, each core may have its own vector table, requiring careful synchronization and configuration.

3

Cache and memory protection units can affect vector table access speed and security, important in safety-critical systems.

When NOT to use

In very simple microcontrollers without interrupts, or in systems using polling instead of interrupts, an interrupt vector table is unnecessary. Also, in some advanced real-time operating systems, interrupt handling may be abstracted away, reducing direct interaction with the vector table.

Production Patterns

In production embedded systems, vector tables are often placed in flash memory at startup, with critical ISRs in fast memory. Bootloaders may relocate the vector table to RAM for firmware updates. Developers carefully align vector table entries with hardware documentation and use linker scripts to control placement.

Connections

Function Pointer Arrays

The interrupt vector table is a specialized form of an array of function pointers used in programming.

Understanding function pointer arrays in software helps grasp how the vector table stores ISR addresses for quick function calls.

Event-Driven Programming

Interrupt handling via vector tables is a hardware-level example of event-driven programming where code reacts to events.

Knowing event-driven programming concepts clarifies why interrupts and vector tables enable responsive systems.

Telephone Switchboard Systems

Like a telephone switchboard routing calls to departments, the vector table routes interrupts to handlers.

This cross-domain connection shows how routing mechanisms solve similar problems in communication and computing.

Common Pitfalls

#1 Writing ISRs without matching vector table entries causes the processor to jump to wrong or empty addresses.

Wrong approach:

void ISR_Timer() { /* code */ }
// No entry in vector table for Timer interrupt

Correct approach:

Place ISR_Timer address correctly in the vector table so processor finds it on Timer interrupt.

Root cause:

Not linking ISR functions properly to vector table entries leads to undefined behavior on interrupts.

#2 Modifying the vector table in flash memory at runtime without relocation support causes system crashes.

Wrong approach:

Attempting to write new ISR addresses directly to flash vector table during program execution.

Correct approach:

Relocate vector table to RAM first, then modify ISR addresses safely at runtime.

Root cause:

Flash memory is usually read-only during execution; writing without relocation causes faults.

#3 Ignoring interrupt priorities and assuming vector table order controls ISR execution order.

Wrong approach:

Assuming ISR at lower vector table index always runs before others when multiple interrupts occur.

Correct approach:

Configure interrupt controller priorities explicitly; vector table only maps ISRs.

Root cause:

Confusing vector table indexing with hardware interrupt priority leads to unexpected ISR execution order.

Key Takeaways

The interrupt vector table is a fixed list of addresses pointing to interrupt service routines, enabling fast processor response to events.

It acts as a direct map, letting the processor jump immediately to the correct ISR without searching or delay.

Understanding the vector table's structure and role is essential for writing reliable interrupt-driven embedded software.

Advanced systems may relocate or modify the vector table at runtime to support flexible interrupt handling.

Separating the vector table from interrupt priority management clarifies complex interrupt behavior and system design.