Confusion about the Crystal on Nucleo_F7xxx boards
The Nucleo_F767ZI board has 4 crystals onboard:
- X1: 8 MHz connected to the JTAG-chip on the STLink
- X2: 32 kHz connected to STM32F767ZI for real time clock
- X3: Not soldered
- X4: 25 M
H
z connected to STM32F767ZI for HSE input clock
From this information, it is only logical to conclude that the 25 MHz crystal is connected to HSE input of the microcontroller. However, CubeMX fills in 8 MHz by default for the Nucleo board. It looks like that is plain wrong:
I currently work with mbed-OS from ARM on this Nucleo board. I use the official mbed version that you can clone from github. I have noticed that this OS uses the ST HAL under the hood to access the chip hardware. So I don't use CubeMX to generate any code. Neverhteless, I discovered that the value of the crystal is also wrong in the HAL running under mbed-OS. Look at these files:
system_stm32f7xx.c
( mbed-os/targets/TARGET_STM/TARGET_STM32F7/
TARGET_NUCLEO_F767ZI/device/system_stm32f7xx.c )
&sharpif
!defined
(HSE_VALUE)&sharpdefine
HSE_VALUE ((uint32_t
)8000000)/*!< Default value of the External
oscillator in Hz */
&sharpendif
/* HSE_VALUE */
stm32f7xx_hal_conf.h
( mbed-os/targets/TARGET_STM/TARGET_STM32F7/
TARGET_NUCLEO_F767ZI/device/stm32f7xx_hal_conf.h )
&sharpif
!defined
(HSE_VALUE)&sharpdefine
HSE_VALUE8000000U
/*!< Value of the External
oscillator in Hz */
&sharpendif
/* HSE_VALUE */
Naturally I fixed the bug by changing
HSE_VALUE
from 8 MHz to 25 MHz:&sharpdefine
HSE_VALUE ((
uint32_t
)25000000)
Unfortunately, this messes up just about everything. My SPI clocks fall down to a much lower frequency, and the mbed serial logger outputs nonsense characters. Probably because the baud rate is no longer correct.
So how can I correct this bug?
#stm32f7 #clock #!stm32-!cubemx-!bug-!pll-!clock #hse #cubemx-bug