2016-12-05 12:55 PM
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;
2016-12-05 07:04 PM
How do the Q and R taps of the PLL looked to be configured in the Clock Tree View?
2016-12-06 08:04 AM
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
2016-12-06 09:23 AM
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.
2016-12-07 07:31 AM
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:
2016-12-07 08:47 AM
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.
2016-12-07 08:51 AM
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.
2016-12-07 08:51 AM
What does this mean? Why 8?
2016-12-07 08:53 AM
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
2017-07-05 02:35 AM
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