Blog

Misunderstanding this behavior can cause missing pulse counts, incorrect measurements, communication failures and bugs that are difficult to reproduce. To understand why, we need to follow an interrupt request through the hardware.

We will use RaayanMini (STM32F401RBT6), an Arm Cortex-M4 platform, as our reference. The central lesson applies more broadly to Cortex-M firmware; the EXTI and timer register details below describe this STM32 device.

1. Understanding the NVIC pending state

The Nested Vectored Interrupt Controller (NVIC) manages interrupt requests, their priorities and their eligibility for exception handling. Each external interrupt number has a pending state.

When a request becomes pending, the processor knows that the interrupt needs servicing. However, pending state is not a counter that records every occurrence of an event. Repeated requests of an interrupt that is already pending do not create a separate queued entry for every occurrence.

For a GPIO interrupt on the STM32F401, the path also includes an important peripheral before the NVIC:

The STM32 EXTI peripheral detects a configured edge and sets that line’s pending bit in EXTI_PR. EXTI can request service from the NVIC, which has its own pending state for the corresponding IRQ. Several peripheral sources can also share one IRQ; a handler must identify which source requires attention.

Consider a sequence in which all three valid rising edges reach one EXTI line before the handler can run:

1. The first edge sets the peripheral’s pending indication and requests service.
2. The second edge arrives while the same indication is already set.
3. The third edge also arrives before the source is serviced.
4. Interrupts become eligible for execution.

The CPU may execute the ISR only once for those three edges. The pending indications tell software that at least one request occurred; they cannot reconstruct the original number of edges.

2. Pending, active and masked: what is the difference?

These concepts are related, but they describe different things:

On Cortex-M4, setting PRIMASK prevents activation of configurable-priority exceptions; NMI and HardFault are not blocked by this mask. A request can still become pending and be serviced later. Masking does not create storage for each repeated request.

Masking with PRIMASK is different from disabling an individual IRQ through its NVIC enable bit. An NVIC-disabled interrupt can still become pending. Disabling the peripheral’s own request generation is yet another operation, whose effect depends on that peripheral.

Read the interrupt configuration at both layers: the peripheral controls whether and how it generates requests; the NVIC and processor masks control whether the CPU can take them.

3. A practical example: why did the pulse counter undercount?

Suppose you are developing a motor-speed measurement system. A sensor produces pulses, and your firmware increments a variable whenever it services the sensor interrupt.

volatile uint32_t pulse_count = 0;

// Illustrative pseudocode: helper names need real peripheral handling.
void SENSOR_IRQHandler(void)
{
    if (sensor_interrupt_pending()) {
        acknowledge_sensor_interrupt();
        pulse_count++;
    }
}

The intent looks straightforward: each serviced notification increments the counter. But if several edges arrive while the interrupt is masked or its source remains pending, some edges may never be represented by separate handler executions.

These numbers illustrate a possible failure mode. They are not measured RaayanMini results, and they do not imply that every masking interval loses three pulses. If exactly three edges collapse into one increment, that particular group contributes two missing increments.

The real outcome depends on the hardware and timing. A hardware counter, capture register, FIFO or other storage may preserve some or all of the needed information. A single latched status flag only preserves an indication that something occurred.

On STM32F401 EXTI, the acknowledgement must clear the appropriate EXTI_PR bit by writing 1. The pseudocode above is not a complete board driver. Leaving the peripheral source asserted can make the ISR run again, even without another physical edge.

This explains why a debugger can show correct interrupt configuration while the application still reports an incorrect measurement: correct notification does not prove complete event recording.

4. Why the ISR alone cannot guarantee accurate event counting

An ISR is software executed in response to a request. It may process stored data, but the handler is not automatically the hardware mechanism that records each physical event.

A slowly operated button can make a simple interrupt-driven application appear reliable. A high-speed encoder, motor sensor or pulse generator can expose the limits much sooner. If events arrive before the CPU or peripheral can preserve and process them, application information can be lost.

Common contributors include:

• Interrupts are masked for too long.
• Higher-priority interrupts delay the handler.
• The CPU spends too much time in an ISR.
• The source provides only one latched status indication.
• Several events occur before software services or clears the peripheral status.
• The application assumes every physical edge produces a separate ISR entry.

Interrupt latency and event-storage capacity are different design concerns. Reducing latency can shorten the time before service. It cannot turn a one-bit flag into a queue, and it cannot recover events that were never recorded individually.

5. What if another event arrives while the ISR is running?

An interrupt can be active and pending: its handler has not completed, and another request of the same IRQ is pending. If the request remains pending and becomes eligible after the current handler finishes, the processor can enter that handler again.

Several additional requests arriving while it is already pending still do not create a separate NVIC queue entry for each event. Keep these two cases distinct:

• Several events occur before the first ISR entry while the interrupt is pending.
• New events occur while the ISR is active and may cause another pending request.

The peripheral matters in both cases. A new edge after an EXTI flag has been cleared can set it again. Edges arriving while it remains set do not add a count to that bit. Clearing flags without understanding their semantics can also discard an indication that software has not processed.

The NVIC automatically removes the pending state when it takes an interrupt, but that does not automatically acknowledge the peripheral source. A level-sensitive request that remains asserted can cause another ISR entry. Consult the peripheral’s interrupt-generation logic, status registers and acknowledgement rules.

6. How can you capture events reliably?

Choose a mechanism that preserves the information your application needs, then verify its limits against the real signal.

7. Event notification and event recording

An interrupt requests the processor’s attention. A separate mechanism may preserve the event count, timestamp or data until the processor can deal with it.

Ask these questions before choosing an interrupt-driven design:

1. What tells the processor that an event needs attention? Identify the peripheral request, flags and NVIC IRQ.
2. What preserves every required event or its data until it can be handled? Identify the counter, capture register or buffer and its capacity.

Test the shortest expected event interval against the longest processing delay. Use a scope or logic analyzer to check the physical signal, and compare it with hardware counts, capture data and overrun flags. ISR entry counts alone do not demonstrate complete event capture.

Design for the events your application must preserve

Three pulses arriving while a Cortex-M interrupt is masked do not guarantee three ISR entries. The NVIC tracks pending state, while the peripheral determines what event information is retained.

For a simple notification, an interrupt may be sufficient. For accurate pulse counting, timestamping or continuous acquisition, use the timer, capture and buffering facilities that match the measurement. Verify their capacities and timing on the actual hardware.