STM32F405 PLL: 168MHz to 84MHz - how to do this?

[Rogers.Gary]

Posted on July 08, 2015 at 05:07

Hello:

I have an STM32F405 processor, with a 8MHz HSE crystal. It's set up to operate at 168MHz. To see if I can get suitable performance at a lower speed to save power, I'd like to change this (*not* on the fly) at the program start to 84MHz. Is this done by changing the HSE value? It cannot be that simple...as I understand it, the HSE value must match the actual crystal frequency. Thank you...

[Tesla DeLorean]

Posted on July 08, 2015 at 05:48

Why wouldn't you just program the PLL with the desired rate, it's just a combination of multipliers and dividers.

In system_stm32f4xx.c change PLL_N from 2 to 4 The VCO will continue to tick at 336 MHz, but now instead of DIV2 (168 MHz) you have DIV4 (84 MHz). You can also tweak the APB1/APB2 clock dividers, and flash wait states. Look at how the F401 clocks.

[Rogers.Gary]

Posted on July 08, 2015 at 06:16 with this information, I will do some reading so I can better understand the clocking. thanks clive1...

[tm3341]

Posted on July 08, 2015 at 10:01

It's PLL_P which should be changed from 2 to 4, because PLL_P is divider from 336MHz to system clock.

PLL_N is multiplier and should be set to 336 as it was before.

[deliancourt]

Posted on July 08, 2015 at 10:14

I think the most simple is to use STM32Mx software configured with your µC if you want be sure that all clock are well clocked and reporting value of PLL ect... on your code (generally a SystemClock_Config(void) function is used for this)

[Tesla DeLorean]

Posted on July 08, 2015 at 14:02

It's PLL_P which should be changed from 2 to 4, because PLL_P is divider from 336MHz to system clock.

Yes, brain fart on my part.

*-----------------------------------------------------------------------------
* System Clock source | PLL (HSE)
*-----------------------------------------------------------------------------
* SYSCLK(Hz) | 84000000
*-----------------------------------------------------------------------------
* HCLK(Hz) | 84000000
*-----------------------------------------------------------------------------
* AHB Prescaler | 1
*-----------------------------------------------------------------------------
* APB1 Prescaler | 2
*-----------------------------------------------------------------------------
* APB2 Prescaler | 1
*-----------------------------------------------------------------------------
* HSE Frequency(Hz) | 8000000
*-----------------------------------------------------------------------------
* PLL_M | 8
*-----------------------------------------------------------------------------
* PLL_N | 336
*-----------------------------------------------------------------------------
* PLL_P | 4
*-----------------------------------------------------------------------------
* PLL_Q | 7
*-----------------------------------------------------------------------------

[Tesla DeLorean]

Posted on July 08, 2015 at 14:14

I think the most simple is to use STM32Mx software configured with your µC if you want be sure that all clock are well clocked and reporting value of PLL ect...

The math strikes me as something a nine year old should be able to do in their head.

[Rogers.Gary]

Posted on July 09, 2015 at 05:27

to all that responded:

thank you, I appreciate your help! The embedded system is almost functioning 100%, just seems one issue, hope it's not serious. The other item that appears to have required setting is the ''SystemCoreClock'' value (in system32f4xx.c) from 168MHz to 84MHz. The WDT was flipping out until I did this. In addition, for using an ST-Link pod, in the IAR options, I had to set the debugger from a clock speed of 168MHz, to 84Mhz. When I do the call to ''RCC_GetClocksFreq'', I can see on the return value in QuickWatch that all of the clocks have been set to half of their previous values, as expected. However, I can no longer ''printf'' in this clock speed. Everything else appears to be functioning  as before, including the RTOS and WDT. Just this oddball thing about printf, which I really need for debugging the code. Any suggestions as to what I need to do to fix this? Thanks...again!

[Rogers.Gary]

Posted on July 10, 2015 at 05:21

I found the problem with printf.

It's the $25 ST-Link pod. It seems this happened before, and I don't know why. I have access to a Segger J-Link and it runs the same printf statements with no issues. Now....that will be an expensive few printf statements...  8--(

[Tesla DeLorean]

Posted on July 10, 2015 at 05:38

Are you semi-hosting the printf() stuff through the SWV channel? ie ITM_SendChar()

With the SWV Viewer (in ST-LINK Utilities) the clock/trace settings have to match that of the core. Might want to check the firmware version, ST fixed some buffering/overrun issues in later releases.