STM32CubeMX "MSI Auto Calibration" shows error, stuck on "enabled" for STM32L552CCTx

Stefan Hamminga · ‎2021-01-05

I'm trying to create a very simple baseline project for an STM32L552CCTx MCU: FDCAN1, USB (device), SWD and a LED. No HSE / LSE clocks present. The 'Clock Configuration' tab works well and a proper clock is found, but in the 'RCC' configuration the project is stuck. "MSI Auto Calibration" shows as "enabled" and with an error indicator. The dropdown only shows a greyed out "enabled" option, so no way to change it.

If I disable the USB support the option becomes "disabled", but the RCC still shows an error icon (but no longer at a specific parameter).

I'm using STM32L5 MCU Package v1.3.1

In an unrelated (?) issue it seems not possible to generate code with a Makefile for this MCU?

Khouloud ZEMMELI · ‎2021-01-06

Hi @Community member

After check, when the USB device is enabled, the USB clock source must be equal to 48MHz, for this reason, a red cross appeared in your project on Clock Configuration Panel, you need just to click on resolve clock issue to equilibrate all clock values.

Now, seeing the USB clock input frequency, the PLLSAI1Q is checked, the PLLSAI1Q and PLLQ depend on PLL Source Mux and PLLSAI1 Source Mux, and the default input PLL MUX is MSI , when the USB clock source comes from the MSI, the Auto calibration must be enabled to reach a stable 48MHz as the Auto calibration is done with the LSE as reference this clock must be enabled to have a functional USB clocked by the MSI.

That explains the red cross on RCC because the MSI Auto Calibration is forced to enabled and the only way to resolve the problem is by configuring LSE (in the case of choosing MSI as PLL Mux input).

Another way to fix the problem by choosing a PLL Mux input other than MSI (for the case of HSE, you need to configure it on RCC first).

Hope my answer helped you, when your question is answered, please close this topic by choosing Select as Best. This will help other users find that answer faster.

Thanks, Khouloud

View solution in original post

Khouloud ZEMMELI · ‎2021-01-05

Hi @Community member

The MSI Auto Calibration needs the activation of LSE mode in pinout tab, did you activate first the LSE then enable the MSI Auto Calibration and later disable the LSE ? Because in this case a red cross will be appeared in the MSI auto Calibration parameter and you need to disable it.

If you faced a problem with the disable option please share your ioc file to check more the issue.

Thanks, Khouloud

Stefan Hamminga · ‎2021-01-05

Hi Khouloud! Thanks for the suggestion. I didn't activate the LSE (or touch any RCC parameter). I even made a new project with exactly the same result (to make sure I didn't accidentally do something similar). Enabling the LSE will clear the error, but then I'll have to provide an LSE clock, something I'd rather not do for this board.

Khouloud ZEMMELI · ‎2021-01-05

@Community member So as I have understood, the MSI auto Calibration parameter is enabled from the beginning by default and the error appeared on it, right ?

If you still face an issue thanks to share your ioc file, the normal behavior is to not face any error in the GUI of CubeMX..

Khouloud

Stefan Hamminga · ‎2021-01-05

The MSI Auto Calibration parameter gets enabled as soon as USB Device support is activated, from that moment the RCC is in a permanent state of error. I've attached the ioc file to this post.

Khouloud ZEMMELI · ‎2021-01-05

This will be internally checked, I'll give you an update as soon as possible.

For your question concerning the Makefile support, the Makefile and GPDSC are disabled for multicontext SOCS (H7 DC, L5 and MP1..), there's no plan to support them for the moment.

Thanks, Khouloud

Stefan Hamminga · ‎2021-01-05

Thank you for clearing up the Makefile point. I hope it'll come available at some point!

I'll await your feedback on the RCC issue, thanks so far!

Khouloud ZEMMELI · ‎2021-01-06

Hi @Community member

After check, when the USB device is enabled, the USB clock source must be equal to 48MHz, for this reason, a red cross appeared in your project on Clock Configuration Panel, you need just to click on resolve clock issue to equilibrate all clock values.

Now, seeing the USB clock input frequency, the PLLSAI1Q is checked, the PLLSAI1Q and PLLQ depend on PLL Source Mux and PLLSAI1 Source Mux, and the default input PLL MUX is MSI , when the USB clock source comes from the MSI, the Auto calibration must be enabled to reach a stable 48MHz as the Auto calibration is done with the LSE as reference this clock must be enabled to have a functional USB clocked by the MSI.

That explains the red cross on RCC because the MSI Auto Calibration is forced to enabled and the only way to resolve the problem is by configuring LSE (in the case of choosing MSI as PLL Mux input).

Another way to fix the problem by choosing a PLL Mux input other than MSI (for the case of HSE, you need to configure it on RCC first).

Hope my answer helped you, when your question is answered, please close this topic by choosing Select as Best. This will help other users find that answer faster.

Thanks, Khouloud

Stefan Hamminga · ‎2021-01-06

I ran the clock configuration solver again and it seems to only find solutions that cause the MSI issue. Manually changing the PLL configuration to use the HSI does seem to fix it as you said. Should't the clock resolver try to find a solution that fits the hardware (thus without forcing use of an LSE)?

Thank you for the detailed help in resolving this.

Beachmiles · ‎2023-05-23

This is still an issue on the stm32L496-Nucleo project as well as a brand new stm32L496ZGT6P project when enabling USB. In the Clock Configuration GUI you have to select,

"System Clock Mux" to be "PLLCLK"

"PLL source Mux" to be HSI

"CLK48 Clock Mux" to use HSI48

Have to manually pick PLL dividers that generate the clock you are looking for as the "Resolve clock issues" button always sets the MSI to be the System Clock Mux.

for an 80Mhz clock but these PLL values work.

PLLM = /1

*N = x10

/R = /2

Wish the stm32cube team could fix these 2+ year bugs in their software.