STM32H5 (all lines): wrong PLLxRGE / VCI range generated – incorrect rules in the CubeMX RCC database (still in 6.18.1)

[JSanEst]

Hello,

I would like to report what looks like a bug in the STM32CubeMX MCU database for the whole STM32H5 family: the PLLx input frequency range (PLLxRGE) that CubeMX generates does not match the actual PLL reference frequency.

A similar case was already reported for the STM32H5E4 and PLL3 in this thread (internal ticket #0064521). As far as I can see, the problem is wider: it affects every STM32H5 RCC database file, plus some PLL1 and PLL2 rules, and it is still present in STM32CubeMX 6.18.1.

Disclosure: this was found by a Claude Opus AI agent while reviewing the code generated by STM32CubeMX for my project. I have checked the generated code and the database lines it points to, but I have not verified the behaviour on hardware (PLL lock/jitter), so please treat it as a report to be confirmed by your team.

Setup

• MCU: STM32H563VIT6 (RCC IP STM32H5_rcc_v1_0)
• STM32CubeMX 6.17.0 (DB.6.0.170) and 6.18.1 (DB.6.0.181), with STM32Cube FW_H5 V1.6.0 and V1.7.0: same result
• HSE 25 MHz, USB clock from PLL3Q

Generated code (HAL_PCD_MspInit)

• PLL3 M=25, N=240, Q=5 (1 MHz reference, VCO 240 MHz) → PLL3RGE = RCC_PLL3_VCIRANGE_3 and PLL3VCOSEL = RCC_PLL3_VCORANGE_WIDE. Expected: RCC_PLL3_VCIRANGE_0 (1–2 MHz).
• PLL3 M=5, N=48, Q=5 (5 MHz reference) → PLL3RGE = RCC_PLL3_VCIRANGE_0 and RCC_PLL3_VCORANGE_MEDIUM. Expected: RCC_PLL3_VCIRANGE_2 (4–8 MHz).

The “PLL3 input frequency range” parameter is read-only in the RCC Parameter Settings (and hidden when the default rule applies), so it cannot be corrected from the GUI.

Root cause (as far as I can tell)
In db/mcu/IP/RCC-STM32H5_rcc_v1_0_Modes.xml the PLL3_VCI_Range conditions do not match their values/comments:

• Line 8351: RCC_PLL3_VCIRANGE_0 (“Between 1 and 2 MHz”) has the condition 4000000 <= VCOInput3Freq_Value < 8000000
• Line 8355: RCC_PLL3_VCIRANGE_1 (“Between 2 and 4 MHz”) has the condition 8000000 <= VCOInput3Freq_Value < 16000000
• Lines 8359/8363 (_2 and _3) have the correct conditions but seem to be shadowed by the two above
• Any value below 4 MHz falls through to the hidden default RCC_PLL3_VCIRANGE_3 (line 8366, “Less than 4 or greater than 16”)

As a result, no PLL3 reference frequency from 1 to 16 MHz gets the correct range (only exactly 16 MHz does). This is consistent with the H5E4 case in the thread above (4 MHz → VCIRANGE_0).

Same rules in the other files. I found identical conditions in:

• RCC-STM32H5_rcc_v1_0_Modes.xml (H562/H563/H573)
• RCC-STM32H5_rcc_v1_1_Modes.xml (H5E4/H5E5/H5F4/H5F5, lines 9467–9483)
• RCC-STM32H5_rcc_v1_2_Modes.xml (lines 6590–6606)
• RCC-STM32H5_rcc_v1_512_0_Modes.xml (lines 5568–5584)

Related issues in the same block (line numbers from rcc_v1_0):

1. PLL1, line 8322: the RCC_PLL1_VCIRANGE_3 (8–16 MHz) condition is (f >= 8 MHz & f < 8 MHz) | f = 8 MHz, so it only matches exactly 8 MHz. Other inputs between 8 and 16 MHz only get the right value through the hidden default.
2. PLL1, line 8372: the PLL1_VCO_SEL MEDIUM condition compares against RCC_PLL1VCIRANGE_0 (missing underscore), so it never matches and PLL1 always gets RCC_PLL1_VCORANGE_WIDE, even with a 1–2 MHz reference. The same typo appears in all five H5 RCC files.
3. PLL2, line 8331: the RCC_PLL2_VCIRANGE_0 condition is (f > 4 MHz | f = 1 MHz) & f < 2 MHz, so it only matches exactly 1 MHz.

Questions

• Can you confirm the issue, and whether ticket #0064521 covers all STM32H5 RCC database files and the PLL1/PLL2 rules above?
• Is there a planned CubeMX/database version for the fix?
• Is RCC_PLLxVCORANGE_WIDE allowed with a 1–2 MHz reference (RM0481), or is MEDIUM mandatory in that case?

Workarounds I am considering: taking the USB clock from PLL1Q with a 5 MHz reference (PLL1 M=5, N=96, P=2, Q=10), or overriding PLL3RGE/PLL3VCOSEL in user code. I can attach the .ioc if needed.

Thank you!