Interrupt Priority Calculator

This tool calculates NVIC (Nested Vectored Interrupt Controller) priority encoding for ARM Cortex-M microcontrollers, including the resulting preemption and sub-priority levels, effective priority grouping, and IRQ latency in microseconds. It converts user-specified priority group bits and priority values into the actual 8-bit AIRCR.PRIGROUP setting and corresponding priority register (PRI_N) byte value. The output helps engineers verify correct interrupt nesting behavior and timing compliance.

Priority grouping determines how the 8-bit priority field is split between preemption priority (higher bits) and sub-priority (lower bits), directly affecting interrupt nesting and tail-chaining behavior. Incorrect grouping can cause higher-priority interrupts to be blocked unexpectedly or prevent lower-priority handlers from preempting longer-running ones. This calculator helps avoid subtle real-time scheduling bugs by validating your NVIC configuration against hardware constraints.

Preemption priority determines whether an interrupt can interrupt another currently executing handler — only higher preemption values (numerically lower when mapped to AIRCR) trigger preemption. Sub-priority breaks ties when multiple pending interrupts share the same preemption level, determining execution order *without* preemption. Note: sub-priority has no effect unless preemption priorities are identical.

Cortex-M3/M4/M7 support 0–4 priority group bits (i.e., PRIGROUP = 0x000 to 0x004), yielding 5 possible splits: 0:8 (no preemption), 1:7, 2:6, 3:5, 4:4 (max preemption). Cortex-M0+/M23 support only 0:4 or 2:2 groupings. Values outside 0–4 will clamp or produce invalid configurations — the calculator validates and warns on out-of-range inputs.

The calculator uses CPU clock (MHz) to convert raw cycle-based latency (e.g., 12 cycles) into microseconds: latency_us = (cycles × 1000) / CPU_MHz. This assumes zero wait states and ideal pipeline behavior; real-world latency may increase due to flash wait states, bus contention, or unaligned memory accesses. Always measure worst-case latency on target hardware for safety-critical applications.

Yes — misconfigured priority grouping (e.g., setting group bits >4 on M4, or assigning equal preemption priorities to time-critical ISRs) often leads to priority inversion, lockups, or HardFaults on illegal priority writes. The calculator flags invalid combinations and shows the exact PRI_N byte written to the NVIC, enabling cross-check against datasheet limits and startup code initialization.

“IRQ Type” is a descriptive label (e.g., “Timers”, “USART”, “ADC”) for documentation and traceability — it has no computational effect but helps organize interrupt assignments in larger projects. Unlike priority values, it doesn’t influence NVIC registers; however, pairing it with calculated priority values aids in maintaining consistent, readable interrupt vector tables and CMSIS-based startup files.

Check your device’s reference manual under “NVIC” or “System Control Block” — it specifies supported PRIGROUP values. Most Cortex-M4 designs use 3:5 (GRP=3) for balanced preemption/sub-priority flexibility. If using CMSIS drivers, consult __NVIC_PRIO_BITS in your device header or core_cm*.h; mismatched group bits between software config and hardware setting cause undefined behavior.

Yes — the underlying NVIC priority model applies uniformly to all exceptions (IRQs, SVC, PendSV, SysTick). However, system exceptions have fixed or configurable base priorities; for example, SVC defaults to lowest priority unless explicitly raised. The calculator outputs the raw priority byte used by all exceptions, so ensure manual overrides (e.g., NVIC_SetPriority(SVCall_IRQn, …)) align with your grouping scheme.

The NVIC stores priority values left-aligned in the upper bits of the 8-bit PRI_N register — unused LSBs are ignored and read as zero. For example, with 4:4 grouping, only bits [7:4] are active; writing 0x21 becomes 0x20. The calculator displays the *effective* value written to the register, matching what you’d observe in memory view or via NVIC_GetPriority(), accounting for hardware masking behavior.