10 years, 1 month ago.

STM32 Nucleo-F401RE - Which clock source?

Hello there,

I just got the STM32 Nucleo-F401RE and when I checked the user manual, there is no mention about what kind of oscillator/clock source used by the main microcontroller (STM32F401). I'm sure it is not X3 (empty slot for crystal) and X2 (empty slot for oscillator). But I'm not even sure if it runs out from the ST-Link's crystal (MCO) and I do not see whether which clock source is the default one in the manual. Or is it running from the processor's internal oscillator at 84MHz?

Thanks.

hello i am just knowing how to deal with stm(nucleo board f401re ) i use COIDE and i follow all instructions of hse enable to active stm32f401 at 84MHZ oscillator i check the board too for sure that SB55 OFF and SB54 ON & SB16 and SB50 ON but it give me also 16MHz system clock could any one told me what is wrong in my code

  1. define HSE_VALUE 8000000
  2. include <stm32f4xx.h>
  3. include <stm32f401xe.h>
  4. include <stm32f4xx_nucleo.h>
  5. include <stm32f4xx_hal_conf.h>
  6. include <stm32f4xx_hal_rcc_ex.h> uint32_t rcc_systemclock,SystemCore_Clock;to check the value of system clock by stm studio

int main(void) { reset the clock to there default state HAL_RCC_DeInit(); enabling high speed the external clock crystal clock RCC ->CR |= RCC_CR_HSEON; RCC_PLLInitTypeDef ok; ok.PLLState|=RCC_PLL_ON; ok.PLLSource|=RCC_PLLCFGR_PLLSRC_HSE; ok.PLLM|=3; ok.PLLN|=336; ok.PLLP|=2; ok.PLLQ|=7; RCC->CFGR |= RCC_CFGR_PPRE2_DIV1; RCC->CFGR |= RCC_CFGR_PPRE1_DIV2; while((RCC->CR & RCC_CR_PLLRDY) == 0) { } RCC->CFGR &=( RCC_CFGR_HPRE_0); RCC->CFGR &=( RCC_CFGR_HPRE_1); RCC->CFGR &=( RCC_CFGR_HPRE_2); RCC->CFGR &=( RCC_CFGR_HPRE_3); RCC->CFGR |=( RCC_CFGR_PPRE1_0); RCC->CFGR &=( RCC_CFGR_PPRE1_1); RCC->CFGR |=( RCC_CFGR_PPRE1_2); RCC->CFGR &=( RCC_CFGR_PPRE2_0); RCC->CFGR &=( RCC_CFGR_PPRE2_1); RCC->CFGR |=( RCC_CFGR_PPRE2_2); RCC->CFGR |=( RCC_CFGR_SW_PLL); FLASH->ACR|=FLASH_ACR_LATENCY_5WS;

rcc_systemclock=HAL_RCC_GetSysClockFreq(); SystemCore_Clock=HAL_RCC_GetHCLKFreq();

RCC_PLL_ON;PLLSource=RCC_PLLCFGR_PLLSRC_HSE;PLLM=8;PLLN=336;PLLP=2;PLLQ=7;} while(1) { } }

posted by mohamed abouhashem 30 Jun 2017

/*note that RCC_PLLInitTypeDef in stm32f4xx_hal_RCC_ex.h typedef struct { uint32_t PLLState; /*!< The new state of the PLL. This parameter can be a value of @ref RCC_PLL_Config */

uint32_t PLLSource; /*!< RCC_PLLSource: PLL entry clock source. This parameter must be a value of @ref RCC_PLL_Clock_Source */

uint32_t PLLM; /*!< PLLM: Division factor for PLL VCO input clock. This parameter must be a number between Min_Data = 0 and Max_Data = 63 */

uint32_t PLLN; /*!< PLLN: Multiplication factor for PLL VCO output clock. This parameter must be a number between Min_Data = 192 and Max_Data = 432 */

uint32_t PLLP; /*!< PLLP: Division factor for main system clock (SYSCLK). This parameter must be a value of @ref RCC_PLLP_Clock_Divider */

uint32_t PLLQ; /*!< PLLQ: Division factor for OTG FS, SDIO and RNG clocks. This parameter must be a number between Min_Data = 4 and Max_Data = 15 */

  1. if defined(STM32F446xx) uint32_t PLLR; /*!< PLLR: PLL division factor for I2S, SAI, SYSTEM, SPDIFRX clocks. This parameter is only available in STM32F446xx devices. This parameter must be a number between Min_Data = 2 and Max_Data = 7 */
  2. endif /* STM32F446xx */ }RCC_PLLInitTypeDef;
  • /
posted by mohamed abouhashem 30 Jun 2017

5 Answers

10 years ago.

I checked the SystemCoreClock value on some platforms.

pc.printf("CPU SystemCoreClock is %d Hz\r\n", SystemCoreClock);  

The LPC1768 gives the expected value of 96000000 Hz

The KL25Z gives the expected value of 48000000 Hz

The LPC1549 gives the expected value of 72000000 Hz

The Nucleo F401 on the other hand shows 16000000 Hz which is way below what it should be. Obviously this needs to be fixed.

Shame that the X-tals were removed on the production boards. You can see on the pinmap pictures that initially they were mounted. Hardware modifications would be easy for the crystal, but you also need to mount some SMD capacitors which is trickier.

Accepted Answer

Hello,

Thanks for the response.

I have manually set my Nucleo's clock speed up to 84MHz, using the STM32CubeMX software. The software has a "clock setting tool" which you can manually set the frequency and generate the code to be pasted into the project.

I will put a 8MHz crystal, the small caps and some modifications on the Nucleo for the external crystal later.

posted by Y.H. NG 03 Mar 2014

My "out-of-the-box" Nucleo shows 84000000 Hz. No X2/X3 onboard, SB16&SB50 open.

posted by Sho Tekken 25 Mar 2015

Hello Sho, this post is rather old. The mbed lib for ST Nucleo F401 has been fixed and now they use the internal clockgenerator and the PLL to generate 84MHz when no external Xtal is detected. I think that fix applies to all nucleo boards.

posted by Wim Huiskamp 25 Mar 2015
10 years ago.

(a bit off topic) I just modded my F103 with XTAL and caps. Changed one define in the Mbed source (many thanks to Erik Olieman for the instructions on importing the source). Clock speed is 72mhz.

The caps are tricky but you don't have to be too precise...all I had were 0805 and they were 20pf, not 18pf. Tight fit, but running great. Thank you again for being such a great community.

L293D

10 years ago.

What about the 32kHz RTC crystal and code? is there anything on this or should we wait until 'official' put the code together.

10 years, 1 month ago.

According to the system init code it runs directly from the 16MHz RC oscillator: https://github.com/mbedmicro/mbed/blob/master/libraries/mbed/targets/cmsis/TARGET_STM/TARGET_NUCLEO_F401RE/system_stm32f4xx.c

The good news, it can directly wake up from sleep without having to re-enable its PLL. The bad news an 84MHz core M4F is running at 16MHz. There have been questions asked already about it in the mbed-dev group (https://groups.google.com/forum/#!topic/mbed-devel/Z6xw7MTR7Aw), but no idea if and when it would change. I don't have it myself, so can't do much about it (besides that STM is responsible for it).

Y.H. NG
poster
10 years ago.

Thanks for the answer, Erik. I'm now studying the github files you showed me. I'll port this to the Eclipse + GCC much like I used it in my other STM32 Discovery boards.