STM32-F401RE About clock Setting in various system_stm32f4xx.c files

[Jcorn.19]

Hello Everybody

I started using Nucleo-F401RE (MB1136 C-04) a few months ago and I am trying to understand how work the SystemInit() function and the clock setting.

As IDE, I use SystemWorkbench/AC6.

When I start a new project using HAL or LL drivers, the system_stm32f4xx.c file which is loaded uses a simple SystemInit() function which sets HSI on and uses it ; it is fairly clear.

But if I start a new project using SPL (standard peripheral lib), the system_stm32f4xx.c file which is then loaded uses a SystemInit() function which calls a SetSyssClock() function.

• At the beginning of the SystemInit() function, the HSI is set on, OK.
• But then in SetSyssClock() function, the HSE is also set on.
• Then when I run/debug the prog, I see in the RCC_CR register that both HSION and HSEON are set ; so I understand no more ! Which clock is then used to drive the system, or better to feed the PLL ?

Can someone tells me where can I find basic documentation about the setting of the clock on a such board ? I read the official doc and search the internet but do not find anything very clear.

Thank you inadvance

Jack-Michel CORNIL

P.S. sorry if my english is not correct but I am french !

[Tesla DeLorean]

The Reference Manual should cover the RCC register bits.

The HSI and HSE can be enabled separately from being selected as the source. At least one clock must be supplied to keep the system running even if transitioning to another.

System starts with HSI, then enables HSE, uses that to start the PLL and then eventually switches over to the PLL as the primary clocking source.​

[Jcorn.19]

Thank You CLive for your quick answer.

I have read the ref manual dans the data sheet : obviously the ref manual describes all the bits of all the register but I found it lacks of examples for how starting the board.

When HSI and HSE are on, I wonder where "the PLL is said" to take the first or the second as source ?

Is it because the HSE is on that the PLL takes mandatorily the HSE as source ?

Moreover is it good to let HSI on when it is HSE which drives the PLL ?

Thanks in advance

[Tesla DeLorean]

There is a register setting that defines the PLL source clock, and there is another register setting the CPU source clock.

HSI and HSE can both run, if you want to save power you can turn one of them off when you can run from a derivative of the other.

[Jcorn.19]

Thank you very much Clive.

Among the various multipliers and dividers, I did not see the PLLSRC bit of the RCC_PLLCFGR.

Now it is a little more evident for me.

[Tesla DeLorean]

The synchronous design always needs a clock.

You might need more than one running as you bring another up.

You might need a second source running so you can switch immediately.

Clocks take time to start and stabilize, external clocks can take a long time if the as-built characteristics aren't ideal.

The clock source can be shifted cleanly by the logic in the chip, you should wait for it to flag the transition has completed.

The PLL has to be OFF in order to change its functional parameters, after restarting you must wait for it to lock.

If switching to a faster clock source you must adjust the flash wait-states FIRST, this will slow things at the slower clock, but prevent failure at the higher clock.

If you change the system clock all the peripheral clocks will change, you will need to address CAN and USART baud rates, for instance, if you change the settings after initialization.

The system decodes the RCC and PLL settings to determine its operating speed. If you use an external clock, then the HSE_VALUE definition needs to reflect you board/component choices.

[Jcorn.19]

Thank you very much for all these precisions.

But I have still a question about BYPASS (a mystery for me who am only an old math teacher).

I read in this post https://community.st.com/s/global-search/stm32F4%20bypass that Nucleo boards derive the 8MHz source from the ST-Link and then it is mandatory to set BYPASS on. Yet my board is a Nucleo-F401RE (MB1136 C-04) and after execution of the SetSysClock() function, the HSEBYP bit of the RCC_CR register is still to 0.

Any explanation would very well become and would help me to get out my lack of knowledge.

Thanks in advance

[Tesla DeLorean]

ST uses BYPASS inconsistently.

In the general sense it is used when you apply an external clocking source, ie a square wave from something else in your circuit, to the primary clock input pin and you don't want/need it to output an inverted copy on the secondary output clock pin.​

[Jcorn.19]

Hello and sorry for the delay but I was busy with my grandson !

If I do understand what you said, set or reset the HSEBYP bit has no influence on what is running inside the board, except perhaps the pin 31 which can then be used as GPIO if HSEBYP=0 ?

As I dived into the startup file and its SystemInit() function, I noticed the one of the first steps is to reset the RCC_PLLCFGR register with the value 0x24003010, and it rises to me a few questions ?

• The first nibble is written as "reserved" in the ref manual, why to write 2 into it ?
• Then the corresponding values of the PLL are (if I am right) M=16, N=192 and P=2 which gives 96 MHz. Why this reset value which seems me incompatible with th F401RE and why not 0 ?

Is there a documentation (other than the ref manual and the data-sheet) where we can find how to start such a board what to do and what not to do, in order to not breaking the board ?

Perhaps would you think that I abuse with all these question but you seems knowing so much the stm32 and I would start clean and try not to build on the sand.

Best regards

[Jcorn.19]

Hello everybody

After summer I dive again in the init files of the stm32 (NucleoF401RE) and I have a lot of questions about the SystemInit() function that I found in the system_stm32f4xx.c.

In this function, there are successively the following instructions :

 /* Reset the RCC clock configuration to the default reset state ------------*/

 /* Set HSION bit */

 RCC->CR |= (uint32_t)0x00000001; // Instr 1

 /* Reset CFGR register */

 RCC->CFGR = 0x00000000;          // Instr 2

 /* Reset HSEON, CSSON and PLLON bits */

 RCC->CR &= (uint32_t)0xFEF6FFFF;  // Instr 3

 // 0xFEF6FFFF = 0b 1111 1110 1111 0110 1111 1111 1111 1111 

 /* Reset PLLCFGR register */

 RCC->PLLCFGR = 0x24003010;     // Instr 4

 // 0x24003010 = 0b 0010 0100 0000 0000 0011 0000 0001 0000

 //           = 0b 0010 0100 0 0 0000 00 0 011000000 010000

 // which gives : PLLQ = 8 PLLSRC = 0 PLLP=2 PLLN =192 PLLM=16

 // and then SYSCLK = 16 / 16 * 192 / 2 = 96

1. Instr 1 put to 0 almost all the bits of the RCC->CR register, ten the HSITRIM[7:0] are initialized automatically at startup as it is said in the description of the RCC->CR register. Is there not a risk ?
2. I am wondering the benefit of Instr 3 : it reset three bits of the register RCC->CR although Instr 1 has still reset all the bits except the zero one.
3. instr 4 gives specific values to bits 28-31 and 18-21 of the RCC_PLLCFGR register although I read in RM0368 sect 6.3.2 that these reserved bits must be kept at reset value.
4. If I make no mistake, Instr 4 gives SYSCLK = 96Mhz : why this value since it is said in sect 3.11 of the data sheet that the maximum frequency is 84MHz. Moreover the PLL is not later used !

Best regards

Jack-Michel