Debugging Reentrancy Issues in Interrupt Handlers

In this lesson, you will learn how to use instruction trace data to pinpoint exactly when a nested interrupt interrupts a shared memory access, causing system state corruption.

The Reentrancy Trap

Reentrancy issues occur when an interrupt service routine (ISR) is interrupted by a higher-priority task that attempts to modify the same global data structures. In complex systems, these "interrupted-interrupts" can leave variables in a partially updated, inconsistent state. Because these events are timing-dependent, traditional breakpoints often "hide" the bug by altering the system's execution flow.

Identifying the Conflict via Trace

When you capture an instruction trace using an Embedded Trace Macrocell (ETM), you are looking for a specific pattern: the program counter (PC) jumping to an ISR vector while a previous instance of the same (or a related) ISR is in the middle of a non-atomic read-modify-write operation.

Consider this shared buffer update:

// Shared variable
uint32_t shared_counter = 0;

void ISR_Handler(void) {
    uint32_t temp = shared_counter; // Load
    temp++;                         // Modify
    shared_counter = temp;          // Store
}

If a higher-priority interrupt triggers exactly between the Load and the Store, the trace buffer will show:

1. LDR instruction from ISR_Handler (Instance A).
2. [EXCEPTION_ENTRY] jump to ISR_Handler (Instance B).
3. LDR, ADD, STR instructions from Instance B.
4. [EXCEPTION_EXIT] back to Instance A.
5. STR instruction from Instance A.

By analyzing the trace, you will see that Instance B’s update to shared_counter is completely overwritten by Instance A’s STR. The trace data provides the "smoking gun" by showing the interleaved instruction stream, confirming that the CPU resumed Instance A with a stale local copy of the counter.

Debugging Strategy

When reviewing the trace, filter for ISR entry/exit markers. Look for overlapping ranges of execution where memory addresses (monitored via Data Watchpoint and Trace) are accessed by multiple ISR context IDs. If you spot a STR instruction from a lower-priority context occurring after a STR from a higher-priority context, you have confirmed a data race.

Key Takeaway: Use hardware trace logs to visualize instruction interleaving, allowing you to identify the precise moment an interrupt preempts a shared memory operation, thereby proving the cause of intermittent state corruption.