NVIC Configuration Helper

This tool generates a ready-to-use NVIC priority configuration table for STM32 microcontrollers, including IRQ enable/disable states, priority assignments (based on ARM Cortex-M’s 4-bit priority grouping), and pre-configured values for system exceptions (SysTick, PendSV, SVC) and common peripherals. It outputs human-readable C code snippets or register initialization logic compatible with HAL/LL libraries.

The Base Priority Level sets the minimum preemptive priority threshold (0 = highest, 15 = lowest on 4-bit systems) applied to all configured peripheral IRQs unless overridden individually. It ensures consistent priority floor across interrupts and simplifies safe priority scaling when multiple peripherals share similar urgency levels.

For FreeRTOS or similar kernels: SysTick is usually set to the *lowest* priority (e.g., 15) to avoid interfering with task switching; PendSV is assigned just above SysTick (e.g., 14) to handle context switching; SVC is often set to a high priority (e.g., 0–3) to ensure immediate handling of supervisor calls. These values prevent priority inversion and support deterministic scheduling.

This defines how many peripheral interrupt lines (e.g., USART1_IRQn, TIM2_IRQn) to auto-generate in the priority table — starting from the lowest-numbered available IRQs. It helps scale configurations for different STM32 families (e.g., 10 IRQs for basic L0/L1 devices, up to 90+ for H7 series), while preserving ordering and avoiding gaps in manual assignment.

Yes — the NVIC architecture is standardized across ARM Cortex-M cores (M0/M3/M4/M7/M33). While peripheral IRQ numbers and names differ, the priority calculation logic, exception handling, and register layout (e.g., AIRCR.PRIGROUP, IP registers) remain identical. Users should map generated priorities to their target MCU’s IRQ vector table.

IRQs with identical priority levels are serviced in hardware-defined order (typically vector number order) — i.e., lower IRQ number wins. The tool warns about duplicate priorities and suggests using sub-prioritization (if priority grouping allows) or reordering to avoid unintended latency in time-critical handlers like ADC or USB.

Copy the generated C code snippet (e.g., HAL_NVIC_SetPriority() and HAL_NVIC_EnableIRQ() calls) into your MX_GPIO_Init() or main() function — typically after HAL_Init() and before the main loop. Ensure the IRQ handler names match those in stm32fxxx_it.c and that corresponding __weak callback stubs are implemented or replaced.

Some RTOS implementations (e.g., CMSIS-RTOS v2) allow configuring kernel-level interrupt masking via BASEPRI or PRIMASK, requiring a dedicated priority floor. This input lets you align the kernel’s critical section behavior with NVIC settings — ensuring that only interrupts *above* this level can preempt RTOS operations without breaking mutual exclusion.

The tool assumes the standard 4-bit priority field (as used in most STM32 devices with SCB_AIRCR.PRIGROUP = 0b101, i.e., 3 bits for preemption, 1 bit for subpriority). If your device uses a different grouping (e.g., 2-bit preemption), manually adjust priority values or use STM32CubeMX to verify compatibility before deployment.

First verify that no two active IRQs share identical priority + subpriority values. Then confirm that BASEPRI is not inadvertently set (e.g., by RTOS critical sections) blocking lower-priority interrupts. Use the NVIC->IABR and NVIC->IP registers in debugger watch window to cross-check actual runtime priority and enable state against tool output.