cancel
Showing results for 
Search instead for 
Did you mean: 

Problem with clock configuration of STM32F401VCT6 MCU - works fine on 42MHz clock, but crashes when set to 84 MHz

MKola
Associate II

I'm programming a custom board built around the STM32F401 MCU and I'm having a hard time configuring the system clock.

I'm using a 8MHz external crystal and I'm trying to set up the PLL to get the maximum frequency given by the datasheet, i.e. 84MHz. I've double checked the values with the cubeMX Clock Configuration tab (i'm not using it to generate code though) and the reference manual, the resulting setup being like this:

pll_m = 8,
 
pll_n = 336,
 
pll_p = 4,
 
pll_q = 7.

the formula for SYSCLK frequency value is

SYSCLK_freq = HSE_freq/pll_m*pll_n/pll_p

which gives us

8MHz/8*336/4 = 84MHz

which is a maximal frequency the MCU can run on. There are some additional constrains on the clocks' values, but they are all satisfied with this setup.

The problem is, it doesn't work. The software crashes even before the main() function - the clock setup function is called from the initialization code in reset handler, and the mcu crashes shortly after setting the sysclk source to PLL.

Interestingly, everything works fine if I set the pll_m value to 16 instead of 8 - the MCU then runs on 42MHz.

The thing is, it shouldn't - the smallest input clock frequency tolerated by the PLL is 1MHz, but it's easy to see that in this case it's HSE_freq/pll_m = 8MHz/16 = 500KHz.

I've checked the HSE frequency with a scope and it indeed equals 8MHz, also checked the frequency of the working setup - indeed it is 42MHz.

The high clock frequency is not that critical and my application can run just fine on 42MHz, however I'm just curious and a little surprised as to why this happens.

I'm using the StdPeriph library to set up the clock and it takes care of setting the flash wait states to 2WS, which is appropriate value for 84MHz clock running at 3.3V, so it's not the flash issue I think.

Any ideas about what could I be doing wrong would be greatly appreciated

1 ACCEPTED SOLUTION

Accepted Solutions

> What is your flash wait state?

>

A logical question, but the initial post answers it:

>> I'm using the StdPeriph library to set up the clock and it takes care of setting the flash wait states to 2WS,

I'm more inclined to believe this is a hardware problem - inadequate power source, improper routing of power and/or ground, improper decoupling, improper VCAP...

JW

View solution in original post

15 REPLIES 15
Mike_ST
ST Employee

Hello,

How about M=4 N=168P=4 to reach 84MHz, does it work ?

Tried it as well, with no success

Mike_ST
ST Employee

What value is VOS in PWR->CR register? ideally it should be set to 2.

the value is 2 indeed.

Mike_ST
ST Employee

If you try to generate an empty CubeMx project and compile it and debug, can you pass the SystemClock_Config function ?

Tilen MAJERLE
ST Employee

What is your flash wait state? Be aware that with higher CPU clock, higher flash wait state necessary and it depends on voltage too.

See product datasheet for details what value to set, usually not higher than 4 in this product.

This normally causes issues when set too low.

> What is your flash wait state?

>

A logical question, but the initial post answers it:

>> I'm using the StdPeriph library to set up the clock and it takes care of setting the flash wait states to 2WS,

I'm more inclined to believe this is a hardware problem - inadequate power source, improper routing of power and/or ground, improper decoupling, improper VCAP...

JW

Piranha
Chief II

Bus frequencies, HSE bypass, regulator voltage scale, wrong configuration code sequence, hardware problems... Better share the configuration code. =)

S.Ma
Principal

The idea to create a project at 84MHz, and compare the HW registers with 42 is nice.

The other way is to recompile say with 50, 60, 70, 80 MHz and look at the behaviour to collect some clues.

You can also try to run 84 MHz then prescale by 2 to see what happens.

Power consumption/vdd drops down to trigger reset or abnormal behaviour, flash waitstates, etc... were covered.

Can you reach the first code line of main() in debug mode?