Repository navigation
soc: st: stm32h7x: NUM_IRQS computed too small since Zephyr 4.4, causing build failure #107585
Description
Describe the bug
Describe the bug
Since Zephyr 4.4, NUM_IRQS is computed automatically via dt_highest_controller_irq_number, which scans only DTS nodes with status = "okay". On STM32H7 targets the scan may return a value lower than the actual hardware maximum. Any application using an IRQ number above that limit fails at build time:
gen_isr_tables.py: error: IRQ 118 (offset=0) exceeds the maximum of 96
Setting CONFIG_NUM_IRQS=150 in prj.conf has no effect because NUM_IRQS is a promptless Kconfig symbol — user assignments are silently ignored with a warning:
`warning: NUM_IRQS was assigned the value '150' but got the value '97'
Expected behavior
NUM_IRQS reflects the actual hardware maximum for the SoC, regardless of which peripherals are active in the DTS.
Impact
All STM32H7 variants are affected. The correct values per CMSIS headers are:
Variants
H723, H725, H730, H730Q, H735 -> 163
H7A3, H7A3Q, H7B0, H7B0Q, H7B3, H7B3Q -> 155
H742, H743, H745, H747, H750, H753, H755, H757 -> 150
Regression
- This is a regression.
Steps to reproduce
- Use any STM32H7 board
- Enable a peripheral whose IRQ number exceeds what the DT scan finds (e.g. FDCAN on STM32H742: IRQ 118)
- Build → gen_isr_tables.py error
Relevant log output
Impact
Annoyance – Minor irritation; no significant impact on usability or functionality.
Environment
- Zephyr: 4.4
- SoC: STM32H742 (also expected on all STM32H7 variants above)
Additional Context
This issue was reported from the online documentation page using the 'Report an issue' button.
Activity
github-actions commentedon Apr 20, 2026
Hi @SpooniSpoon! We appreciate you submitting your first issue for our open-source project. 🌟
Even though I'm a bot, I can assure you that the whole community is genuinely grateful for your time and effort. 🤖💙
etienne-lms commentedon Apr 20, 2026
The point of commit 71aa3be was that interrupts are expected to be handled from drivers described from an enabled node in the DT. Do you think your issue could be handle this way?
erwango commentedon Apr 20, 2026
If you enable node with higher IRQ, then it should be taken into account by
gen_isr_tables.py. If it doesn't happen, this should be investigated. Did you try a pristine build after enabling the node ?SpooniSpoon commentedon Apr 21, 2026
For my application, I need certain specific functions of the peripherals (STM32 SoC) that are not supported by the zephyr drivers. For example, I measure the frequency of an input signal by combining multiple timers. These drivers use the STM32’s low-level (LL) functions directly. To avoid conflicts, the corresponding timer nodes are intentionally not enabled in the device tree (DT). Required interrupts are enabled according to the following scheme:
IRQ_CONNECT(TIM17_IRQn, 2, DefPeriTim17Isr, NULL, 0);If these interrupt numbers fall outside the calculated NUM_IRQS value—which does not match the numbers supported by the SOC—an error occurs during compilation.
If there is a way to circumvent the calculation of NUM_IRQS, I am open to that. However, this should not result in any incomplete or unnecessary drivers being initialized.
mathieuchopstm commentedon Apr 21, 2026
Note that you can always add a dummy node in Devicetree with a large enough
interruptsproperty to setNUM_IRQSarbitrarily. However, I agree that being able to assign a value to the option directly would be more convenient.See #107674 for implementation of this proposal.
mathieuchopstm commentedon Apr 21, 2026
The proper solution as described by @nordicjm in #107674 is to override
CONFIG_NUM_IRQSusing the boardKconfig.defconfig:SpooniSpoon commentedon Apr 23, 2026
Thank you for the detailed explanation of how to adjust NUM_IRQS via a board-specific configuration. This is a good, working solution for me.