STMCubeMX 4.18.0 generates incorrect PLL timing

[Elwood Downey]

Posted on December 05, 2016 at 21:55

I am using STMCubeMX 4.18.0 configured for STM32F446ZET. When I set Clock Configuration HCLK to 180 the following lines in main.c cause the processor to hang:

  RCC_OscInitStruct.PLL.PLLM = 4;

RCC_OscInitStruct.PLL.PLLN = 180;RCC_OscInitStruct.PLL.PLLQ = 2;RCC_OscInitStruct.PLL.PLLR = 2;

Changing to the following allows the processor to run correctly at 180 MHz:

  RCC_OscInitStruct.PLL.PLLM = 16;

RCC_OscInitStruct.PLL.PLLN = 360;RCC_OscInitStruct.PLL.PLLQ = 7;RCC_OscInitStruct.PLL.PLLR = 7;

[Tesla DeLorean]

Posted on December 06, 2016 at 04:04

How do the Q and R taps of the PLL looked to be configured in the Clock Tree View?

[Nesrine M_O]

Posted on December 06, 2016 at 17:04

Hi

Downey.Elwood

‌,

According to RM0390 reference manualthe

VCO output frequency = VCO input frequency × PLLN with 192 ≤ PLLN ≤ 4 So the generated PLLN=180 is wrong.

Thanks for highlighting this issue,I will report this issue to our MX team.

-Nesrine-

Ifmy suggestanswers your question, please mark it as correct.Thank you

[Tesla DeLorean]

Posted on December 06, 2016 at 17:23

The operational frequency of the PLL is 192 MHz to 432 MHz, here an N of 180 is valid because the input frequency via the M of 4 is 2 MHz (top end of comparison frequency). The VCO frequency is 360 MHz which is within the operational range.

The issue with crashing has more to do with the Q and R taps, assuming P is at 2. The setting of Q needs to get something in the 48-75 MHz range depending on the USB, SDIO or CRYPT logic clocking from that.

One would also need to review the Flash Wait states in the context of the CPU clock, perhaps 5 or 6 for 180 MHz operation.

[Elwood Downey]

Posted on December 07, 2016 at 16:31

CubeMX does seem to be setting a reasonable FLASH latency that I have not found a need to change:

HAL_RCC_ClockConfig(&RCC_ClkInitStruct, FLASH_LATENCY_5)

The way I confirm the clock is really running at 180 MHz is to put a scope on PC_9 to see 90 MHz and include this call in the code:

HAL_RCC_MCOConfig(RCC_MCO2, RCC_MCO2SOURCE_SYSCLK, RCC_MCODIV_2);

Here is a screen shot of the setup:

[Tesla DeLorean]

Posted on December 07, 2016 at 16:47

Ok, so the use of HSI seems to have precluded the use of USB, but the default settings need to bring the 48 MHz clock to some semblance of normality. The PLL taps are going to clock regardless of whether the source clock is HSE or HSI, the HSI+PLL clock is just not going to be stable enough to use for USB, but isn't the CRYPT+SDIO still using that clock, and viable?

Pretty sure there isn't an OFF setting for the individual P, Q and R taps, just if the PLL is enabled, or not.

[Tesla DeLorean]

Posted on December 07, 2016 at 16:51

My F4 DISCO and NUCLEO code was reworked so it can recognize what chip it is running on, and set the PLL and Flash Latency on the fly. Saved me a lot of time from having to fork the project(s) a dozen ways.

[waclawek.jan]

Posted on December 07, 2016 at 16:51

What does this mean? Why 8?

[Tesla DeLorean]

Posted on December 07, 2016 at 16:53

I think this is a bug

Downey.Elwood

ran into when this, or the prior thread was opened. The Clock Tree view needs somefixing and thought.

Edit: This one

https://community.st.com/0D50X00009Xke6cSAB

[Sirma Siang]

Posted on July 05, 2017 at 11:35

Hello All,

I just check, using CubeMX4.21, that correct PLL values are generated.

About the wrong HSI and LSI values, it was just a type, anyway those values are not modifiable.

Kind regards

Sirma