‎2019-08-30 07:27 AM
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
Solved! Go to Solution.
‎2019-08-30 01:24 PM
> 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
‎2019-08-30 07:57 AM
Hello,
How about M=4 N=168P=4 to reach 84MHz, does it work ?
‎2019-08-30 08:00 AM
Tried it as well, with no success
‎2019-08-30 08:13 AM
What value is VOS in PWR->CR register? ideally it should be set to 2.
‎2019-08-30 08:18 AM
the value is 2 indeed.
‎2019-08-30 08:27 AM
If you try to generate an empty CubeMx project and compile it and debug, can you pass the SystemClock_Config function ?
‎2019-08-30 12:02 PM
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.
‎2019-08-30 01:24 PM
> 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
‎2019-08-31 03:47 AM
Bus frequencies, HSE bypass, regulator voltage scale, wrong configuration code sequence, hardware problems... Better share the configuration code. =)
‎2019-08-31 04:18 AM
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?