Firmware Interrupts, DMA & Shared Data Guide

01 / 06 · The lab system

Start with the hardware event, not the ISR.

Interrupt choices begin with latency, frequency, payload size, and what the product can afford to lose.

Interactive system overview

Five timing problems with five different event contracts

Select a case to highlight its end-to-end path, inspect an illustrated waveform, calculate the relevant timing bound, and see what belongs in hardware, interrupt context, or task context.

Scroll the case selector horizontally to view all five timing problems.

Lab assumption: ControlNode implements at least four NVIC priority bits and assigns them to preemption priority. On real hardware, verify __NVIC_PRIO_BITS and PRIGROUP. Unsupported logical values can alias, and subpriority does not control preemption.

DIRECT HARDWARE ACTION + REPORTING IRQ

Safety trip: firmware is slower than the shutdown deadline

An overcurrent comparator must stop PWM within 200 ns. In this worked lab scenario, assume a measured worst-case event-to-defined-handler-probe response of 1.0 µs. Software alone is therefore five times too slow.

Physical eventOvercurrent comparator trips

Hardware contractPWM kill acts directly

Firmware actionConfigurable priority 0 IRQ reports

Observable resultSafe output plus fault record

Safety trip timingillustrative intervals

The safety action and software reporting path have separate timing budgets. The output must become safe before the ISR begins.

Real use case

A motor-control board detects overcurrent while the CPU may be masked, preempted, or executing another handler.

Calculate

Required shutdown is 0.2 µs. Worst measured software response is 1.0 µs. Software misses the requirement by 0.8 µs and is 5 times slower than the deadline.

Best mechanism

Use an independent comparator-to-PWM kill path. Use the interrupt afterward for timestamping, diagnosis, reporting, and controlled recovery.

Handler contract

Capture the latched cause and service time. If physical event time matters, read a hardware-captured timestamp. Acknowledge the documented source, publish minimal recovery state, and return.

Design warning

Priority 0 is the highest configurable priority, but it is not nonmaskable. PRIMASK and FAULTMASK can delay it; BASEPRI cannot mask configurable priority 0. Product safety must not depend on this handler.

How to prove it

Probe the comparator input, hardware output-disable signal, and a defined in-handler GPIO point. Measure trip-to-kill separately from trip-to-probe response.

Polling baseline

Polling is a timing contract, not a shortcut

Polling is correct only when firmware can guarantee that every relevant condition remains observable until the next check and that the maximum read gap fits the response deadline.

Good fit: a boot-ready bit stays asserted until read, and startup can tolerate a short bounded wait.
Risky fit: a brief edge can occur between checks, or another operation can make the loop interval unbounded.
CPU tradeoff: frequent checks consume cycles even when nothing has changed.
Bounded case: maximum gap between actual register reads plus the work done after detection.
Unbounded case: an unlatched pulse shorter than that read gap can be missed completely.

Choose the electrical signal model. A nominal 100 µs schedule is not itself the guarantee. The guarantee uses the maximum gap between actual register reads.

Nominal register reads: 100 µsG_read,max = max(t_read,n+1 - t_read,n)

Raw input

Status bit

never captured sticky until firmware clears

CPU reads

G_read

Raw, unlatched pulseEvery read returns 0

No finite detection bound. Because the 20 µs pulse is shorter than G_read,max, it can begin and end between reads. Poll faster with a proven gap, or use hardware that latches the occurrence.

Latched or persistent statusRead 3 observes 1L_response,max ≤ G_read,max + T_act,max

Detection is bounded. The event remains observable until a read. If J_gap is the proven extra delay within one inter-read interval, then G_read,max ≤ 100 µs + J_gap. A one-bit latch can merge repeated events, so use a counter or FIFO when multiplicity matters.

Design rule

Choose from the event deadline, rate, payload, and loss tolerance

Do not begin with a favorite mechanism. First ask how quickly the event must be handled, how often it occurs, how much data moves, whether it can be lost or merged, and whether safety must survive late firmware.

Response deadlineEvent frequencyPayload sizeLoss toleranceCPU budget

On a narrow screen, scroll the guide horizontally. The mechanism name stays pinned while you compare the decision columns.

Mechanism	Decision test	Main benefit	Key constraint	ControlNode decision
POLL	The condition remains observable until checked, and G_read,max + T_act,max ≤ D_response.	Simple control flow with no exception entry or shared ISR state.	Every check costs CPU time. Brief pulses can be missed unless hardware latches them.	Poll a boot-ready status for a short, bounded startup wait.
IRQ	An irregular or periodic event needs service sooner than the main loop can guarantee.	Prompt response while the CPU performs other work or sleeps between events.	The handler must stay bounded, service the source correctly, and hand larger work to normal context.	Button edge, 1 kHz timer, and UART FIFO threshold.
DMA + IRQ	Many bytes or samples must move with little CPU work, and firmware can process blocks.	Hardware performs repeated transfers; the CPU handles one completion per block.	Buffer ownership, capacity, overload policy, and cache behavior on cache-equipped targets must be explicit.	20 ksample/s ADC data in 128-sample blocks.
HARDWARE + IRQ	The safe action must occur even if firmware is masked, stalled, late, or faulty.	Hardware-bounded protection that does not depend on software latency.	Latch enough cause information for the reporting IRQ and controlled recovery.	Comparator disables PWM directly; a configurable priority 0 IRQ reports the trip.

Section checkpoint

Interview questions · hardware choices

Two easy, two medium, and one hard scenario. Open each question to compare a strong answer.

Easy · DesignMatch the button, 1 kHz timer, UART RX, 20 ksample/s ADC, and overcurrent trip to polling, IRQ, DMA plus IRQ, or direct hardware action.

Strong answer: Use a GPIO IRQ plus deferred debounce for the button, unless a proven polling bound is comfortably inside the human-response requirement. Use a timer IRQ when software state must advance each millisecond, or timer output compare for a pure pin waveform. Use a FIFO-threshold IRQ for short UART bursts and consider DMA for sustained traffic. Use timer-triggered ADC plus DMA and a block-completion IRQ. Use a direct comparator-to-PWM kill path plus an IRQ for fault reporting.

What the interviewer is testing: connect each choice to deadline, rate, payload size, buffering, and loss tolerance.

Easy · CodingWhy is a 20 ms delay loop inside a GPIO button ISR a poor design, and what should replace it?

Strong answer: The delay holds the CPU in interrupt context, delays lower-priority work, increases nesting and stack risk, and makes response depend on switch behavior. The handler should acknowledge or coalesce the edge, arm a one-shot timer, and return. A timer callback or task should sample the stable input after 20 ms and publish one logical press.

What the interviewer is testing: bounded ISR design, peripheral acknowledgement, and deferred work.

Medium · CalculationAn 8-byte UART FIFO at 115200 baud raises an IRQ when four bytes are present. How much theoretical time remains before byte 9 causes overrun, and what receive design would you choose?

Strong answer: With 8-N-1 framing, each character uses 10 bits, so one byte takes 10 / 115200 = 86.8 µs. From completion of byte 4 to completion of byte 9 is five character intervals, or about 434 µs. That is only a theoretical upper bound. For short bursts, use a threshold IRQ that performs a bounded drain into a static ring buffer. Keep masking and higher-priority interference comfortably below the budget. For sustained traffic, use DMA, hardware flow control, or a documented overload policy.

What the interviewer is testing: derive the timing budget, then translate it into an architecture and safety margin.

Medium · SizingADC samples at 20 ksample/s in 128-sample DMA blocks. The processing task can be unavailable for 18 ms. What mechanism and minimum buffer pool do you choose?

Strong answer: A block completes every 128 / 20,000 = 6.4 ms. Assuming the blackout begins with one DMA-owned active buffer and no queued or task-owned backlog, three blocks can complete while a fourth buffer is being filled, so 1 + ceil(18 / 6.4) = 4 buffers is the mathematical minimum. Add any buffer already queued or task-owned at the start, plus margin for processing time, scheduling jitter, and ownership handoff. Use timer-triggered ADC plus DMA, and let the completion ISR publish only the completed-buffer identity.

What the interviewer is testing: producer-consumer timing, ownership, and capacity planning.

Hard · SystemUART reaches its FIFO threshold, a DMA block completes, and an overcurrent trip occurs while firmware is already in a lower-priority handler. Design the response order and defend every mechanism.

Strong answer: The comparator disables PWM immediately through hardware, independent of CPU state. Its configurable priority 0 reporting IRQ can then preempt lower-urgency configurable work when enabled and not blocked by PRIMASK or FAULTMASK. The safety ISR captures cause and service time, or reads a hardware-captured trip timestamp when physical event time matters, and does not call the RTOS because it is above the syscall ceiling. DMA completion at priority 5 publishes a completed-buffer identity through an eligible interrupt-safe primitive. UART at priority 7 performs a bounded FIFO drain into a ring and returns. Buffer capacity and the 434 µs UART service bound must tolerate the safety and DMA interference. Event-reference and handler probes verify actual ordering and response.

What the interviewer is testing: separate hardware safety action, interrupt reporting, data movement, ownership transfer, priority, and deferred processing.

02 / 06 · Inside the core

Follow one edge through the Cortex-M.

In this lab's common peripheral path, hardware records or asserts a source condition, the exception becomes pending, the processor preserves return state and fetches the vector, firmware services the source, and exception return resumes or tail-chains.

Editorial cutaway of a microcontroller package showing illuminated event paths entering the silicon and reaching controller, core, and memory regions. — Silicon anatomy **An event becomes controlled execution.**
Peripheral status records the condition. The controller arbitrates it, the core preserves return state, and the handler services the source.

End-to-end path

The handler is only one stage in the chain

Select any stage to advance the animated path. This is a conceptual responsibility chain, not a cycle-accurate serial pipeline. Enable and routing are normally configured before the event, and Cortex-M4 overlaps vector fetch with automatic stacking.

01

EXTERNAL HARDWARE

A physical event occurs

A GPIO edge, timer compare, FIFO threshold, or DMA completion can arise independently of the instruction the CPU is currently executing. Synchronous faults follow a different path from the current instruction.

State change

The electrical or peripheral condition becomes true. No handler is running yet.

CPU action

The CPU may still be executing ordinary code. Detection begins in hardware.

What to verify

Probe the event reference and confirm polarity, edge or level semantics, and pulse width.

Dispatch map

The vector table selects executable code

Hover, focus, or click a row to inspect conceptual handler pseudocode.

Entry 0 | Initial MSPConceptual dispatch pseudocode

__StackTop = ORIGIN(RAM) + LENGTH(RAM);
vector[0] = __StackTop;

MSP <- vector[0]

On reset, the processor loads the first vector-table word into MSP. The linker must provide a valid, correctly aligned initial stack-top value. Entry 0 is data, not a handler address.

Exception frame

The saved PC makes return possible

xPSRexecution and condition state
PCresume address
LRinterrupted link register
R12scratch register
R3argument / scratch
R2argument / scratch
R1argument / scratch
R0argument / return

SP after stacking
Points to the eight-word basic frame. SP itself is not a ninth saved word.

Compiler-generated handler code may save more registers. Stack alignment can add padding. On a Cortex-M4 implementation with the optional FPU enabled, active floating-point context and lazy-stacking policy can add or reserve an extended frame.

Timing analysis

Latency is a budget, not one architectural number

current operation

synchronize / arbitrate

mask / higher IRQ

stack + vector

C prologue

L_{event→probe} = L_source/route + L_blocking + L_{core entry} + L_code→probe

Example ControlNode boundaries: (7 + 3) board-specific pre-core cycles + 12 favorable Cortex-M4 entry cycles + 8 cycles to the probe = 30 cycles = 375 ns at 80 MHz. Use non-overlapping boundaries; flash waits, bus contention, masks, wake-up, and higher-priority work can add more.

Two-trace latency measurementone shared time axis

Event reference

In-handler GPIO probe

Response

Response to probe = t_probe_rise - t_event

Instrumented code

Probe high time = t_probe_fall - t_probe_rise

t_event

Defined hardware reference edge at the interrupt source.

t_probe_rise

GPIO write reached inside the handler, after architectural entry and any code before the write.

t_probe_fall

Second GPIO write. This is not the architectural exception-return instant.

Measure from a defined source reference to a defined in-handler probe point. The GPIO transition occurs after architectural entry and includes preceding instructions and bus delay. Probe-high width measures only the instrumented code region.

Section checkpoint

Interview questions · core mechanics

State assumptions before calculating.

Easy · ConceptWhat do vector entries 0 through 3 contain on a typical Cortex-M startup table?

Strong answer: Entry 0 contains the initial MSP value. Entries 1, 2, and 3 contain the Reset, NMI, and HardFault handler addresses. Entry 0 is data, while the later entries are valid Thumb handler addresses.

What the interviewer is testing: startup layout, stack initialization, and the difference between a value and a function pointer.

Easy · MechanicsWhich registers are automatically saved in the basic exception frame, and what may add more stack use?

Strong answer: The basic hardware frame contains R0 through R3, R12, LR, PC, and xPSR. Compiler-generated code may save additional registers. Alignment padding and floating-point context can also increase stack use.

What the interviewer is testing: hardware stacking versus compiler prologue and optional context.

Medium · CalculationAt 100 MHz, an IRQ is masked for 2 µs, waits behind 50 cycles, then needs 12 entry cycles. Estimate latency.

Strong answer: Fifty cycles at 100 MHz is 0.50 µs and 12 cycles is 0.12 µs. Total estimated latency is 2 + 0.50 + 0.12 = 2.62 µs. State that synchronization, bus waits, sleep wake-up, floating-point stacking, and C prologue are excluded unless specified.

What the interviewer is testing: unit conversion, explicit timing boundaries, and honest assumptions.

Medium · Stack traceA FreeRTOS task uses PSP when an IRQ arrives. Which stack receives the saved task frame, and which stack does the handler use?

Strong answer: The interrupted task frame is stacked on PSP because that was the active thread stack. Handler mode then executes using MSP. If a higher-priority interrupt nests, its interrupted handler context is stacked on MSP. EXC_RETURN tells the core which mode and stack to restore.

What the interviewer is testing: PSP versus MSP, nested handler stack pressure, and exception return.

Hard · DebugAfter relocating the vector table to RAM, the first external IRQ jumps to a default handler. Build a precise debug checklist.

Strong answer: Verify VTOR support and alignment, protect the table while copying or switching it, and inspect the exact word at VTOR + 4 × (16 + IRQn). Confirm it points to the intended Thumb handler, the symbol is linked correctly, and the source is enabled only after relocation is complete. Use the barrier sequence documented for the target and current CMSIS example; perform cache maintenance only on applicable cache-equipped systems. Entry 0 should remain valid for table completeness, but it does not select this external IRQ.

What the interviewer is testing: architectural indexing, relocation ordering, barriers, and evidence rather than guesswork.

03 / 06 · Priority & masking

Pending does not mean allowed to run.

The peripheral owns source state, the NVIC owns enable, pending, active, and priority state, and the processor combines those with mask registers and current execution priority to decide preemption eligibility.

NVIC state machine lab

Pending and active form the state. Enabled is a separate permission bit.

Use the event controls to see how one IRQ moves among inactive, pending, active, and active plus pending. A disabled line can still retain a pending request.

Independent configuration bit: NVIC enable

InactivePENDING = 0, ACTIVE = 0

PendingPENDING = 1, ACTIVE = 0

ActivePENDING = 0, ACTIVE = 1

Active + pendingPENDING = 1, ACTIVE = 1

ENABLE = 1PENDING = 0ACTIVE = 0

Inactive

No request is recorded and no instance of this handler is executing.

Eligibility evaluator

A request may remain pending while one acceptance gate blocks it.

Scenario: a priority 7 UART handler is active. Toggle each CPU-acceptance fact and inspect whether a pending priority 5 DMA exception can run now.

Request formation comes first: a peripheral condition plus its local enable normally generates a hardware request. Once NVIC pending is recorded, activation no longer depends on the original condition remaining true. Software can also set pending directly.

Eligible now

All five activation facts are true. The DMA exception can preempt the UART handler.

Vocabulary that travels across architectures

Exception, interrupt, fault, trap, reset, and NMI are related, but not interchangeable

Cortex-M uses exception as the architectural umbrella. External interrupts are exceptions. Faults are error-associated exceptions. Trap is useful cross-architecture vocabulary, not the main Cortex-M category name.

Scope: ControlNode uses a Cortex-M4. Other Cortex-M profiles can omit fault classes, BASEPRI, priority grouping, or VTOR. Always confirm the target core and CMSIS device header.

Term	Practical meaning	Cortex-M examples	Relation to instruction stream	Priority and masking	Normal outcome
Exception	Cortex-M architectural umbrella for reset, system exceptions, faults, and device IRQs.	Reset, NMI, faults, SVC, PendSV, SysTick, external IRQs.	May be synchronous or asynchronous.	Depends on the specific exception.	A handler may return, reset, or stop. Reset does not return normally.
Interrupt	On Cortex-M4, a device IRQ is an asynchronous exception signaled by a peripheral or software request.	GPIO edge, timer compare, UART FIFO, DMA completion.	Normally asynchronous to the instruction stream; software can also pend an IRQ intentionally.	Device IRQs have configurable enable, pending state, and priority; processor masks affect activation.	Service the source, publish required work, then return.
Fault	An error-associated exception caused directly, imprecisely, or by escalation.	HardFault, MemManage, BusFault, UsageFault.	MemManage and UsageFault are synchronous. BusFault can be precise or imprecise.	Configurable fault behavior depends on the core. HardFault has fixed urgency.	Diagnose, recover only when safe, or enter a controlled reset state.
Trap	Informal cross-architecture term, not a Cortex-M exception class, for an intentional or precisely detected synchronous exception.	SVC, enabled divide-by-zero UsageFault, or BKPT with the applicable debug configuration.	Caused by the current instruction.	Uses the priority and masking behavior of the corresponding exception.	Invoke privileged service, debugger, validation, or controlled fault handling.
Reset / NMI	Special architectural exceptions, not ordinary configurable IRQs.	Power-on reset, watchdog reset, software reset, external NMI source.	Reset restarts execution. NMI can arrive asynchronously.	Reset has highest architectural priority. NMI is not blocked by PRIMASK, BASEPRI, or FAULTMASK.	Reset loads initial MSP and Reset vector. NMI runs its handler and may return.

Not every exception is an interrupt, but every external IRQ is handled through the exception mechanism.
Lower numeric configurable priority means higher urgency. Priority grouping decides which bits can preempt.
PRIMASK blocks configurable exceptions. BASEPRI applies a nonzero threshold. FAULTMASK blocks every exception except NMI.

ControlNode policy

Lower logical number = higher urgency

0safety-trip report

5DMA completion · RTOS ceiling

6application timer

7UART RX

10button / debounce

15RTOS tick

These numbers apply to configurable exceptions. NMI and HardFault have fixed urgency above configurable priority 0. Confirm implemented bits, logical versus raw encoding, grouping, and the RTOS syscall ceiling before reasoning from numbers.

Mask behavior

Block only what the invariant requires

PRIMASK

Broad mask

Blocks every configurable-priority exception, including configurable priority 0. NMI and HardFault remain eligible.

BASEPRI

Threshold mask

A nonzero value blocks configurable priorities with numeric values equal to or greater than the threshold. BASEPRI = 0 disables threshold masking and cannot mask configurable priority 0.

FAULTMASK: on Cortex-M4, it blocks every exception except NMI and is specialized fault-handling machinery, not an ordinary application critical section. For normal masks, never blindly disable then enable. Save and restore prior state.

Nested execution

The safety-report ISR pauses UART, then UART resumes

Select a phase or play the story. The timeline highlights the executing context and the readout explains the saved stack state and the eligibility decision.

Thread mode

mainmain resumes

UART ISR | P7

UART bodyUART resumes

Safety report | P0

capture evidence

PHASE 1 | THREAD MODE

Main code executes with no active exception.

Running contextThread mode

Saved contextNone

Source semantics

What re-pends depends on the peripheral

Read each mini trace from left to right. The top row shows the hardware condition or firmware clear. The lower row shows the status or interrupt request seen by the controller.

edge latch

raw edge

latched status

Brief event is remembered

The raw pulse may be gone before the CPU arrives. Service the documented latch and clear only the consumed event.

level source

condition

IRQ request

The request follows the condition

Clearing NVIC pending alone is temporary. Remove the root condition or the request immediately becomes pending again.

W1C clear rule

write 1

sticky status

Write only the handled mask

A read-modify-write can clear unrelated W1C bits that were already set when the register was read. A different bit that asserts only after the read is normally written as zero and remains set. Follow the device definition exactly.

UART FIFO

occupancy

threshold IRQ

Draining data is the service

Read enough entries to move occupancy below the threshold, but keep the work bounded under continuous traffic.

Bound reached; source still assertedUART FIFO remains above threshold.

Return samples the asserted lineClearing only NVIC pending did not remove the source.

IRQ becomes pending againController state reflects the still-active request.

Eligible IRQ reactivatesTail-chaining can leave Thread mode with little CPU time.

Why the loop continues

The peripheral request is level-sensitive. The handler changes controller state but does not drain enough data to deassert the peripheral request, so the IRQ becomes pending again immediately.

Illustrative occupancy, not a measurement

Near-saturated | background starvedhigher

Section checkpoint

Interview questions · priority & masking

Separate pending state from preemption eligibility.

Easy · StateExplain enabled, pending, and active. What happens if the same IRQ occurs again while active?

Strong answer: Enabled permits delivery, pending records a waiting request, and active means the handler has been accepted and has not completed. The same IRQ can become active plus pending if it occurs again, but it normally does not preempt itself. After return, the recorded request can run again.

What the interviewer is testing: independent state bits and correct same-IRQ behavior.

Easy · SourceA level-sensitive GPIO interrupt is pending. The handler clears only NVIC pending while the input stays asserted. What happens?

Strong answer: The peripheral continues presenting its request. Clearing the controller pending bit does not remove the hardware condition, so the IRQ becomes pending again and may create an interrupt storm. Firmware must perform the documented peripheral service or remove the physical condition.

What the interviewer is testing: peripheral state versus NVIC state and level-sensitive re-pending.

Medium · MaskingUART priority 7 is active. Timer priority 6 is pending. BASEPRI blocks logical priorities 5 through 15. Does the timer preempt, and what changes when BASEPRI is cleared?

Strong answer: The timer remains pending but cannot activate because priority 6 is inside the masked range. When BASEPRI is cleared, priority 6 can preempt priority 7 if pending remains set and the NVIC line is enabled. If grouping assigns bits to subpriority, only the preemption-priority field decides nesting.

What the interviewer is testing: lower number means higher urgency, threshold masking, and pending versus eligible.

Medium · CalculationAt 80 MHz, DMA arrives 20 cycles into a 100-cycle UART body. DMA entry takes 12 cycles, its body 40, and return to UART 10. When do the DMA and UART bodies finish?

Strong answer: One cycle is 12.5 ns. DMA body begins at cycle 20 + 12 = 32, so event-to-body latency is 0.150 µs. Its 40-cycle body finishes at cycle 72, which is 0.900 µs after the UART body began and 0.650 µs after the DMA event. After the 10-cycle return, UART resumes at cycle 82 with 80 body cycles left, so its body finishes at cycle 162, or 2.025 µs after it began. Complete UART exception exit requires its final return cost unless another exception tail-chains. Bus waits, compiler saves, late arrival, and floating-point context are excluded.

What the interviewer is testing: nested entry cost, remaining work, and exclusive time versus wall time.

Hard · Failure analysisA shared IRQ reactivates immediately. The ISR clears NVIC pending, reads one UART byte, and writes the full status register back. Logging reduces the symptom. Diagnose and prove a correction.

Strong answer: At least one peripheral source remains asserted or reappears. Clearing NVIC pending is not source service. One UART read may leave the FIFO above threshold, and writing a captured status value back may accidentally clear unrelated W1C bits. Capture status once, inspect every source sharing the line, and service each with its documented read, drain, acknowledge, or clear sequence. Use an exact W1C mask only for bits documented as write-one-to-clear. Define DMA, flow control, local masking, or drop behavior for overload. Prove the fix with source and handler probes, entry status, FIFO high-water mark, reactivation count, deassertion before return, and maximum handler time.

What the interviewer is testing: source semantics, shared IRQ service, W1C safety, bounded work, and measurement.

04 / 06 · ISR design

Design an ISR you can bound, explain, and prove.

Follow one event from status capture through exact source service, bounded publication, and exception return.

Covered: ISR contract · progressive code review · handoff semantics · ownership · overload policy

Interactive contract

Run one bounded ISR from evidence to return

Select each responsibility. The path highlights who owns the work, the code preview shows the minimum action, and the readout states the bound and proof obligation.

STAGE 1 | CAPTURE

Read evidence before changing it

Capture status once and preserve data that a later read or clear could destroy. Status interpretation and register ordering are device-specific.

uint32_t status = UART->STATUS;
uint32_t errors = status & UART_ERROR_MASK;

Bound

A fixed number of register reads.

Failure if skipped

A destructive service can erase the only evidence of the cause.

Proof

Record entry status during controlled RX and error injections.

Progressive code review

Move from uncontrolled work to a complete RTOS-safe handoff

Each version solves a different design problem. Finite code is not enough: the item limit needs a measured worst-case execution budget, and a FromISR call still needs an eligible interrupt priority.

void UART_IRQHandler(void) {
  printf("RX\n");
  while (uart_rx_ready()) {
    parse_full_command(uart_read_data());
  }
  lock_mutex();
  update_policy();
}

UNCONTROLLED | NO FINITE WCET

Several operations have data-dependent or blocking time

Formatted output, an unlimited producer-driven loop, parsing, and a normal mutex make completion time impossible to defend. The mutex can wait for a task that cannot run while the ISR is active.

Timing statement: No finite bound while new bytes can keep the ready condition true.
Design decision: Capture, service a fixed budget, publish to static storage, and defer policy.
Proof target: Measure maximum cycles and lower-priority blocking under continuous traffic.

Handoff and ownership

Choose the smallest primitive that preserves the information

The handoff is part of the ISR contract. Select a payload type to compare what is preserved, how overload is exposed, and which ownership bug to prevent.

Recommended contract

A Boolean means one or more events occurred

Use an atomic exchange or a brief relevant-source mask for take-and-clear. Repeated events intentionally coalesce.

Preserves: Latest readiness state, not an occurrence count.
Overload policy: Coalescing is the policy. Use a counter if each event matters.
Common bug: Load then clear can erase an event that arrives between the two operations.
Priority rule: Use no kernel call for a simple atomic flag.

FreeRTOS priority assumption: all implemented bits are assigned to preemption priority and logical syscall priority 5 is encoded correctly. Approved FromISR calls require a numerical logical priority of 5 or greater. The configurable priority 0 safety-report ISR is above that ceiling and does not call the kernel.

Section checkpoint

Interview questions · ISR design

Explain both device servicing and deferred work.

Easy · Design ruleWhy should an ISR avoid allocation, formatted logging, blocking locks, and long parsing?

Strong answer: These operations have data-dependent or scheduler-dependent time. Allocation may search or lock a heap, formatted output can block, a normal mutex may wait for a task that cannot run while the ISR is active, and parsing often contains unbounded loops. The ISR delays lower-urgency work, increases jitter and stack pressure, and makes worst-case timing hard to prove. Capture, service, publish, and defer policy.

What the interviewer is testing: bounded execution, interrupt-context restrictions, and deferred work.

Easy · Bounded loopWhy can while (uart_rx_ready()) be unbounded even with an eight-byte FIFO?

Strong answer: The producer keeps receiving while firmware drains. If arrivals plus ISR overhead keep the ready condition true, the handler can remain active indefinitely. Bound work by a documented item or cycle limit and define DMA, flow control, local masking, or drops for sustained overload. Finite hardware capacity does not automatically create a finite ISR execution time.

What the interviewer is testing: producer-consumer reasoning and WCET.

Medium · CalculationAn eight-byte UART FIFO triggers at four bytes. At 115200 baud with 8-N-1, masking, interference, entry, and code before the first read total 380 µs. Is it safe?

Strong answer: One character takes 10 / 115200 = 86.8 µs. From completion of byte four to completion of byte nine is five character periods, or about 434 µs. A first freeing read at 380 µs leaves about 54 µs under the stated phase assumptions. It is theoretically safe, but the margin must cover baud and clock tolerance, bus waits, nested work, measurement overhead, and the device's receive semantics.

What the interviewer is testing: derive the service deadline and state assumptions.

Medium · RTOS codingA bounded UART ISR should wake the parser immediately when it becomes the highest-priority ready task. What must the handoff include?

Strong answer: Capture status, perform a bounded drain into static storage, clear only documented status, expose overflow, call an ISR-safe notification or queue function, capture its wake result, and conditionally yield on exception exit. Verify that the IRQ priority is allowed to call the kernel under the configured syscall ceiling. A FromISR name does not override an invalid priority.

What the interviewer is testing: complete ISR-safe handoff, priority ceiling, and exact source service.

Hard · DMA ownershipAssume this design is ported to a cache-equipped, noncoherent Cortex-M7. A DMA ISR posts buffer A to a task, then immediately restarts DMA into A. Under load the task sees mixed samples. Diagnose and prove a fix.

Strong answer: The ownership bug exists before cache coherency: A was reused before the task returned it. Use a bounded pool with explicit DMA-owned, queued, task-owned, and free states. DMA may claim only a free buffer. On a noncoherent cache-equipped target, use direction-specific maintenance: clean CPU-written data before DMA reads it, and invalidate DMA-written data before the CPU reads it. Align and isolate buffers to cache-line boundaries and apply platform-required barriers. Memory barriers alone do not update or discard cache lines. Prove the fix with generation numbers, owner assertions, queue high-water marks, no-free counters, completion timestamps, and integrity tests at maximum load.

What the interviewer is testing: ownership, backpressure, cache coherency, and evidence.

05 / 06 · Shared state & debug

Make every shared update and timing claim observable.

Step through the race, choose a contract that preserves the required information, then debug the complete signal path with evidence.

Covered: lost updates · volatile · atomics · ownership · masking · timing evidence

Embedded development board connected to precision oscilloscope probes, a logic analyzer, and a professional bench instrument. — Measurement on the bench **Timing claims need two reference points.**
Measure from a defined source reference to a defined in-handler probe point. A GPIO transition occurs after architectural entry and includes preceding instructions and bus delay. Probe-high width measures only the instrumented code region.

Interactive race lab

Watch two valid increments produce the wrong result

Choose an implementation, then click the execution steps. The lane view separates the value in memory from each context's private register value.

Main contextReady to load counterlocal register: empty

Shared memorycounter = 5expected after two events: 7

ISR contextWaiting for interruptlocal register: empty

STEP 1 OF 6Main reads the current value

The value 5 is copied into a register. Shared memory has not changed.

What volatile actually provides Observable access: yes Atomic read-modify-write: no Mutual exclusion: no Event counting or ownership: no

Sharing contract

Choose the smallest primitive that preserves what the product needs

The correct primitive depends on information semantics, not habit. A Boolean can preserve readiness while still losing counts, order, and payload ownership.

/* ISR publishes */
atomic_store_explicit(
  &ready, true, memory_order_release);

/* Task takes and clears */
bool was_ready = atomic_exchange_explicit(
  &ready, false, memory_order_acquire);

Information preserved: Latest readiness state, not the number of events.
Ownership rule: ISR publishes. Task atomically takes and clears.
Overload policy: Coalescing is intentional and documented.
Common failure: A separate load then clear can erase a newly arriving event.

PROTECTION SCOPE

A data primitive and an interrupt mask solve different problems

A target-verified lock-free atomic RMW updates one atomic object without a software critical section. It can compile to multiple instructions and may retry after preemption. Atomicity of the flag does not establish payload ownership.

Added IRQ delay: no intentional mask interval in the verified implementationProtects: one atomic object and its defined orderingPreemption may force an implementation retryRTOS rule: priority still must satisfy the syscall ceiling

Evidence-driven debug lab

Start at the physical event and stop at the first broken fact

Select a symptom. The path marks what is proven, the waveform shows the distinguishing evidence, and the readout gives the next measurement instead of a guess.

01Physical event
02Raw status
03Local enable
04NVIC state
05Mask and priority
06Vector entry
07Source deasserts

Event exists, handler probe stays lowtime flows left to right

SYMPTOM | NEVER FIRES

Prove the request before blaming the vector

The first missing fact is often peripheral configuration, not the CPU. Read raw status and local-enable state before changing priorities.

First measurement: Probe the pin and inspect raw peripheral status.
Likely causes: Wrong edge selection, pin mux, clock, or local interrupt enable.
Corrective action: Repair the first broken fact, then continue down the path.
Proof of repair: Correlate the event reference, raw status, NVIC pending state, and ISR probe.

Heisenbug rule: if logging changes the symptom, treat that as timing evidence. Use a GPIO probe, cycle counter, trace, and counters before adding heavier instrumentation.

Section checkpoint

Interview questions · shared state & debug

Two easy, two medium, one hard.

Easy · ConceptWhat does volatile guarantee, and why does it not make counter++ safe?

Strong answer: It requires observable accesses to the volatile object according to the C implementation's rules. counter++ is still a load, modification, and store, so an ISR can interleave and lose an update. volatile provides neither atomicity, exclusion, event preservation, nor a general memory barrier. Use a verified lock-free atomic operation, a correctly scoped critical section, or single-writer ownership.

What the interviewer is testing: compiler visibility versus synchronization.

Easy · Design choiceAn ISR receives ordered UART bytes and the task must process every byte. Why is a Boolean data_ready flag insufficient?

Strong answer: A Boolean coalesces multiple arrivals into one state and carries no payload or ordering. Use a statically allocated single-producer, single-consumer ring or an ISR-safe queue. Define ownership, capacity, publication order, and an observable overflow policy.

What the interviewer is testing: information semantics and bounded storage.

Medium · CalculationA configurable priority 2 IRQ arrives 3 µs into a 12 µs PRIMASK critical section. At 100 MHz, exception entry takes 18 cycles. What is the earliest handler-body start? Would NMI wait too?

Strong answer: The IRQ waits 9 µs for unmasking. Entry then takes 18 / 100 MHz = 0.18 µs, so the earliest body start is 9.18 µs after the event. This excludes synchronization, bus stalls, and higher-priority work. NMI is not blocked by PRIMASK, so it does not incur the 9 µs mask delay.

What the interviewer is testing: masking scope and latency decomposition.

Medium · Code reviewAn ISR writes a sample, performs a release-store to ready, and a task uses an acquire-exchange to clear it. Is the payload completely safe?

Strong answer: Publication ordering is established and the exchange avoids the take-and-clear race, but buffer ownership is unresolved. A later ISR can overwrite the same payload while the task is copying or processing it. Use ping-pong buffers, an owned buffer pool plus queue, or an SPSC ring. If overwrite-latest semantics are intentional, state that contract and use a coherent snapshot technique.

What the interviewer is testing: memory ordering versus payload lifetime.

Hard · Debug scenarioUnder sustained UART traffic, the CPU stays in the UART ISR. Clearing NVIC pending helps only momentarily, and adding logging appears to fix it. Diagnose, correct, and prove the design.

Strong answer: A level-sensitive RX request remains asserted while the FIFO condition exists, so clearing only NVIC pending cannot remove the cause and it becomes pending again. Logging perturbs arrival rate, handler timing, FIFO occupancy, and race windows. Capture status, drain a bounded amount or to the documented threshold, service each cause with the peripheral's required sequence, and use exact W1C masks only where documented. Publish to a sized ring and return. If demand exceeds the budget, use DMA or flow control and expose drop, overflow, maximum occupancy, activation count, and maximum duration counters. Prove the repair with an event and source trace plus in-handler probes under worst-case traffic.

What the interviewer is testing: level semantics, bounded service, perturbation, and proof.

06 / 06 · System synthesis

Prove the complete interrupt design.

Connect every physical event to a timing contract, execution policy, software owner, overload response, and measured acceptance test.

Covered: architecture contracts · integrated execution · safety separation · overload · interview synthesis

Interactive architecture

Inspect one complete source contract

Select a source. The summary identifies its product requirement and priority, while the detail panel explains why the mechanism, ISR, owner, overload policy, and proof belong together.

SOURCE 1 OF 5 | SAFETY CONTRACT

Hardware removes the hazard; software records it

The comparator-to-PWM path acts without CPU participation. The configurable priority 0 interrupt is a reporting path, not the safety mechanism.

Event semantics: A comparator sets a latched fault while an independent hardware path disables PWM.
Timing contract: PWM off within 200 ns. Measure trip-to-handler-probe separately.
Rate and burst: Rare and asynchronous. The response must survive a busy or masked CPU.
Mechanism and priority: Direct hardware shutdown plus configurable priority 0 reporting IRQ. No RTOS call.
Bounded ISR work: Capture cause and service time, or read a hardware-captured event timestamp. Service the documented latch, publish minimal state, return.
Handoff and owner: Hardware owns immediate safety. Recovery logic owns diagnosis and restart authorization.
Overload policy: Remain latched safe, preserve first-fault evidence, and reject unauthorized restart. Count repeats only if hardware keeps exposing them without clearing the safe state.
How to prove it: Probe comparator, PWM disable, and a defined in-handler point. Verify trip-to-kill and trip-to-probe separately.

Integrated execution lab

Follow hardware, CPU, task, output, and proof on one timeline

Choose a system condition and then a phase. The trace highlights the active evidence so the story continues beyond exception return into ownership, product response, and verification.

Nominal acquisition and control releaseshighlighted column = selected phase

PHASE 1 OF 6 | EVENT

Independent hardware events become source state

DMA completion and timer compare set their own documented status. Neither source depends on the main loop noticing it.

Mechanism: Peripheral state preserves a request condition until service. A sticky bit can merge repeated occurrences.
State owner: DMA owns the filling buffer. The timer owns the compare status.
Acceptance check: Confirm the 6.4 ms block period and 1.0 ms timer period.

01 Claim

State the requirement and your design decision.

02 Mechanism

Explain the exact hardware and software path.

03 Tradeoff

Name latency, throughput, memory, and complexity costs.

04 Verification

Give probes, counters, limits, and worst-case conditions.

Final drill

Interview synthesis

Two easy, two medium, one hard.

Easy · SafetyWhy does the ControlNode use both a hardware PWM kill and a priority 0 interrupt for the safety trip?

Strong answer: The output must become safe within 200 ns, while measured worst-case software response is about 1.0 µs. Hardware therefore disables PWM independently of CPU state. The configurable priority 0 interrupt captures cause and service time, or reads a hardware-captured trip timestamp when physical event time matters, then publishes recovery state and services the documented latch. PRIMASK and FAULTMASK can delay this IRQ, so it must not be the safety mechanism.

What the interviewer is testing: hardware versus software responsibility.

Easy · ContractWhat information belongs in a complete interrupt-source contract?

Strong answer: State the physical event and peripheral semantics, deadline, rate and burst behavior, payload and loss tolerance, mechanism and priority, bounded ISR work, handoff and owner, overload policy, and the signals or counters that prove the design.

What the interviewer is testing: requirements-first design.

Medium · RTOS policyThe FreeRTOS syscall ceiling is logical priority 5. Which ControlNode interrupts may call approved FromISR APIs?

Strong answer: Assume all implemented bits are assigned to preemption priority and logical syscall priority 5 is encoded correctly. DMA priority 5, timer 6, UART 7, and button 10 have numerical priorities equal to or greater than 5, so they may call only approved FromISR APIs. The configurable priority 0 safety-report IRQ is above the ceiling and must not call the kernel. Waking a higher-priority task may also require the port's documented ISR-yield operation.

What the interviewer is testing: logical priority ordering and syscall ceilings.

Medium · CalculationAt 100 MHz, UART runs 2,500 times/s for 180 cycles, the timer 1,000 times/s for 120 cycles, and DMA 156.25 times/s for 300 cycles. Entry plus exit costs 24 cycles per activation. Estimate average interrupt CPU load.

Strong answer: UART uses 2,500 × 204 = 510,000 cycles/s. Timer uses 1,000 × 144 = 144,000. DMA uses 156.25 × 324 = 50,625. Total use is 704,625 cycles/s, or about 0.705 percent of a 100 MHz CPU. This is average occupancy only. It does not prove worst-case latency, jitter, burst tolerance, or deadline margin.

What the interviewer is testing: dimensional analysis and utilization versus schedulability.

Hard · FIFO deadlineA 1 Mbit/s 8N1 UART has a 16-byte FIFO and interrupts at occupancy 8. Firmware can be globally masked for 60 µs, blocked by a higher-priority ISR for 30 µs, and UART entry takes 0.2 µs. Can the FIFO overflow before service begins?

Strong answer: At continuous 1 Mbit/s with 8N1 framing, one byte completes every 10 µs. After occupancy reaches 8, bytes 9 through 16 fill the eight free slots at +10 through +80 µs. The next byte at +90 µs is the first that cannot fit. A 90.2 µs latency to handler-body start already loses, and the real contract is threshold-to-first-FIFO-read, so instructions before the read and the peripheral's exact receive semantics also count. Reduce mask and blocking time, trigger earlier, use DMA or flow control, and verify with threshold and handler probes plus overrun and high-water counters.

What the interviewer is testing: serial framing, FIFO headroom, and complete latency accounting.

Primary references

CMSIS NVIC CMSIS startup & vectors CMSIS core registers CMSIS Cortex-M7 D-cache operations CMSIS-SVD register access semantics Arm Cortex-M4 Generic User Guide Arm Cortex-M comparison FreeRTOS Cortex-M priorities FreeRTOS QueueSendFromISR FreeRTOS TaskNotifyFromISR WG14 C11 draft · volatile & atomics

Trace the event. Design the handler. Prove the timing.

Five timing problems with five different event contracts

Polling is a timing contract, not a shortcut

Choose from the event deadline, rate, payload, and loss tolerance

The handler is only one stage in the chain

A physical event occurs

The vector table selects executable code

The saved PC makes return possible

Latency is a budget, not one architectural number

Pending and active form the state. Enabled is a separate permission bit.

A request may remain pending while one acceptance gate blocks it.

Exception, interrupt, fault, trap, reset, and NMI are related, but not interchangeable

Lower logical number = higher urgency

Block only what the invariant requires

Broad mask

Threshold mask

The safety-report ISR pauses UART, then UART resumes

What re-pends depends on the peripheral

Run one bounded ISR from evidence to return

Read evidence before changing it

Move from uncontrolled work to a complete RTOS-safe handoff

Several operations have data-dependent or blocking time

Choose the smallest primitive that preserves the information

A Boolean means one or more events occurred

Watch two valid increments produce the wrong result

Choose the smallest primitive that preserves what the product needs

Atomic flag with take-and-clear

A data primitive and an interrupt mask solve different problems

Start at the physical event and stop at the first broken fact

Prove the request before blaming the vector

Inspect one complete source contract

Hardware removes the hazard; software records it

Follow hardware, CPU, task, output, and proof on one timeline

Independent hardware events become source state

Primary references