Bug: STM32G4 Clock configuration panel bugs with HCLK at 170Mhz

[BarryWhit]

Several issues here.

First issue, the indicated limits on PLLR are wrong:

The error suggests the PLL output can be no higher than 150Mhz, which is wrong since the chip supports HCLK freqs up to 170Mhz. Which is also explicitly stated below the HCLK box:

Second Issue, possibly related, the automated search feature, which tries to find a PLL configuration that produces a desired HCLK, fails to find a solution when the user chose target HCLK to be 170Mhz:

But, if the user sets the target HCLK as 85Mhz, you do get a solution:

If we then change the PLLR divider to /2 instead of /4, we get the desired HCLK of 170Mhz, and no violation is flagged for PLL/R (as shown above). Something here is clearly inconsistent.

Summary:

1. The upper limit for PLLR should be corrected to 170Mhz.

2. if addressing (1) doesn't fix it, the automated search feature should be fixed so that it finds a solution for a target of HCLK=170Mhz.

3. Because issue (1) exists, the limits for PLLM and PLLN should also be reviewed to ensure they conform to current datasheet specifications.

Minor issue:

4. given an input HSE frequency, a python script can enumerate all achievable HCLK frequencies in a fraction of a seconds. Yet the search algorithm in CubeMX (presumably in java) takes several seconds to do the same thing. It could  run much faster. 

[BarryWhit · Accepted solution]

I see this for STM32G431CB on CubeIDE 1.14.1, but it's actually fixed in CubeIDE 1.16.0 (or some prior version). My bad.