Skip to main content
MKola
Associate II
August 30, 2019
Solved

STM32F401VCT6 works fine on 42MHz clock, but crashes at 84 MHz

  • August 30, 2019
  • 15 replies
  • 4053 views

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

This topic has been closed for replies.
Best answer by waclawek.jan

> 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

15 replies

Mike_ST
ST Technical Moderator
August 30, 2019

Hello,

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

In order to give better visibility on the answered topics, please click on 'Best answer' on the reply which solved your issue or answered your question. 
MKola
MKolaAuthor
Associate II
August 30, 2019

Tried it as well, with no success

Mike_ST
ST Technical Moderator
August 30, 2019

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

In order to give better visibility on the answered topics, please click on 'Best answer' on the reply which solved your issue or answered your question. 
MKola
MKolaAuthor
Associate II
August 30, 2019

the value is 2 indeed.

Mike_ST
ST Technical Moderator
August 30, 2019

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

In order to give better visibility on the answered topics, please click on 'Best answer' on the reply which solved your issue or answered your question. 
MKola
MKolaAuthor
Associate II
September 2, 2019

I just created an empty project in CubeMX and the code crashed in the HAL_RCC_ClockConfig() function (after configuring the PLL as the system clock source)

Tilen MAJERLE
ST Employee
August 30, 2019

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.

waclawek.jan
waclawek.janBest answer
Super User
August 30, 2019

> 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

MKola
MKolaAuthor
Associate II
September 2, 2019

I feel very dumb now - of course I forgot connecting the capacitor to the VCAP2 pin - will try soldering directly to the MCU pin and check if it fixes anything

Piranha
Principal III
August 31, 2019

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

Tesla DeLorean
Guru
August 31, 2019

Should be working examples in the SPL. Even if you took the the 168MHz examples and moved P from 2 to 4

STM32F401 discovery firmware package

https://www.st.com/en/embedded-software/stsw-stm32136.html

Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..
MKola
MKolaAuthor
Associate II
September 2, 2019

That's exactly the thing I did, the initialization code is straight out of the SPL (in file system_stm32f4xx.c), I just changed the PLL values to match the value of HSE (SPL assumed 25MHz crystal)

S.Ma
Principal
August 31, 2019

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?