STM32U031/U073/U083 SVDs incorrectly specify nvicPrioBits=4 instead of 2
The official STM32U0 SVD version 1.0 files for STM32U031, STM32U073, and
STM32U083 specify:
<nvicPrioBits>4</nvicPrioBits>
The manual (RM0503) documents four programmable interrupt priority levels implemented with
two priority bits. ST's own current CMSIS device headers also specify the
correct value:
stm32u031xx.h: #define __NVIC_PRIO_BITS 2
stm32u073xx.h: #define __NVIC_PRIO_BITS 2
stm32u083xx.h: #define __NVIC_PRIO_BITS 2
The svd metadata files are used in the rust ecosystem as well as other third party tooling.
SVD code generators exposing this value to software firmware.
I’m using the rust RTIC framework along side stm32/stm32-rs crate which depend on the SVD for source of
truth configuring for various stm32 MCUs.
The issue above manifests in the following bug in that framework:
In stm32-rs/stm32-rs, svd2rust generated `NVIC_PRIO_BITS = 4` from
the ST SVD. RTIC then converted logical priorities using four bits. Logical
priorities 1, 2, 3, and 4 were written as 0xf0, 0xe0, 0xd0, and 0xc0. The
STM32U073 hardware retains only bits 7:6, so every priority read back as 0xc0.
This prevented a nominally higher-priority LPTIM wake interrupt from preempting
an RTIC software-task executing WFI (RTIC uses NVIC priorities extensively for scheduling tasks).
Overriding the generated value to 2 made the priority read back as 0x00 and allowed my LPTIM interrupt to preempt and wake up the exclusive sleep task.
Thanks very much for reading this far
