An interrupt is a mechanism used by a microcontroller to temporarily change the normal execution flow when an event requires attention. The event might originate from a peripheral, timer, communication controller, external input or software.

Instead of continuously checking every peripheral, the CPU executes normal application code and responds when an interrupt request occurs. The processor saves the required execution context, enters an interrupt service routine, often called an ISR, handles the event and then returns to the interrupted execution flow.

Automotive ECUs process events with different timing requirements. A CAN message arrival, timer event, ADC conversion completion and diagnostic communication event might all require CPU attention.

An Interrupt Service Routine, or ISR, is the software routine executed in response to an interrupt. The ISR performs the immediate work needed to handle the event or records enough information for normal software execution to process the event later.

Automotive ECUs often handle multiple events with different timing requirements. Interrupt priority determines which interrupt receives attention when multiple requests compete for CPU service, subject to the MCU’s interrupt architecture.

In architectures supporting nested interrupts, a higher-priority interrupt might interrupt the execution of a lower-priority ISR. Whether nesting occurs depends on the CPU architecture, interrupt configuration and current masking state.

Interrupt latency is the time between an interrupt event becoming eligible for service and the CPU beginning the relevant interrupt handling sequence. The exact definition used in a project needs to specify the measurement points.

Consider an ECU receiving a CAN frame containing engine speed or another control signal. The CAN controller receives the frame and raises a configured receive event. The CPU then executes the associated interrupt handling path.

An ECU might use an ADC to measure battery voltage, pedal position, temperature or another analog signal. After a configured conversion completes, the ADC peripheral might generate an interrupt.

Timer interrupts are common in ECU software. A periodic timer event might establish a software time base or trigger a scheduled processing function.

Interrupt control mechanisms determine whether the CPU or interrupt controller accepts selected interrupt requests. Engineers use masking carefully around short critical sections where data consistency matters.

A vector table provides architecture-specific information used to map exception or interrupt sources to their handlers. The exact structure differs across CPU families.

Interrupt handlers often share data with the main application or RTOS tasks. This creates concurrency concerns because the ISR and task might access the same variable at different execution points.

A variable accessed by both normal execution and an interrupt context often needs careful declaration and access rules. In C, volatile tells the compiler that accesses to the object have observable effects outside ordinary compiler assumptions.

volatile uint8_t adcReady = 0;

void ADC_ISR(void)
{
    adcReady = 1;
}

void MainTask(void)
{
    if (adcReady)
    {
        adcReady = 0;
        process_adc_data();
    }
}

In an RTOS-based ECU, an ISR usually performs time-sensitive peripheral handling and then wakes, signals or queues work for a task. This keeps long processing outside interrupt context.

In an AUTOSAR ECU, interrupts support hardware drivers, communication stacks, timers, operating-system mechanisms and other basic software functions. The exact interrupt path depends on the MCU, AUTOSAR configuration and vendor implementation.

Interrupt behavior matters in safety-related ECUs because unexpected latency, incorrect priority or excessive ISR execution might affect timing assumptions. Safety analysis therefore considers interrupt behavior as part of the complete software and hardware architecture.

Consider a battery-management ECU measuring pack current through an ADC. The ADC completes a conversion and generates an interrupt. The ISR captures the conversion result. A task then applies filtering and diagnostics before updating the battery-management control logic.

Interrupts are a core part of automotive embedded software. They connect hardware events with software execution and help ECUs respond to communication, sensor, timer and fault events.

Good interrupt design depends on more than writing an ISR. Engineers need to analyze priority, latency, masking, execution time, shared data, interrupt frequency and fault behavior.

A practical ECU design often keeps the ISR short and moves larger processing into an RTOS task or another deferred execution context. Engineers then verify the complete timing path with measurement and fault testing.