cancel
Showing results for 
Search instead for 
Did you mean: 

Default HSE set to 25 MHz for NUCLEO-F722ZE

Anton Martinsen
Associate II

Is it intented for STM32CubeMX drivers for NUCLEO-F722ZE to have 25MHz as HSE input by default? The hardware I bought from ST had an 8MHz oscillator as input for HSE, not 25 MHz.

8 REPLIES 8
Amel NASRI
ST Employee

Hi @Anton Martinsen​ ,

This is reported to our STM32CubeMX development team who will take care to bring required corrections.

Thanks,

-Amel

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

Seen the stm32xxxx_hal_conf.h​ contain the wrong HSE_VALUE on occasion as examples moved from EVAL or DISCO series boards with alternate clocking for Ethernet, etc.

As a general rule I tend to print CPU and bus speeds to a debug console so I can quickly check they are as expected, helps when dealing with dozens of boards.​

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

Hi @Community member​ ,

Which example please? What I noted is the difference between stm32f7xx_hal_conf.h and system_stm32f7xx.c regarding HSE_VALUE for same project. This has to be highlighted as well.

-Amel

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

It was more of a historic observation, a quick grep yielded this non-comprehensive list

STM32Cube_FW_F7_V1.16.0\Projects\STM32F767ZI-Nucleo\Examples\FLASH\FLASH_SwapBank\Inc\stm32f7xx_hal_conf.h

STM32Cube_FW_F7_V1.16.0\Projects\STM32F767ZI-Nucleo\Examples\SPI\SPI_FullDuplex_AdvComIT\Inc\stm32f7xx_hal_conf.h

STM32Cube_FW_F7_V1.16.0\Projects\STM32F767ZI-Nucleo\Examples\SPI\SPI_FullDuplex_AdvComPolling\Inc\stm32f7xx_hal_conf.h

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

Hello @Community member​ ,

I am pretty much a beginner at embedded development so if I misunderstand something here, I apologize.

I do not know how I should have printed anything, the main reason I came across this was because I could not print anything over UART or ITM_SendChar.

I tried looking at SystemCoreClock but this was showing the "correct value" because it was calculated from the defined HSE value.

Eventually I noticed there was some activity on UART and I started guessing baudrates until I found there was stuff being printed but with a baudrate of a factor 3 lower than I thought I had setup the UART.

Then I noticed SPI and ITM had the same behaviour which then lead me to believe HSE was wrong. Then I noticed there was no 25MHz oscillator on the board, only an 8MHz.

Best regards,

Anton

Thanks @Community member​ .

This is reported to our STM32CubeF7 development team in order to review examples and set the correct HSE_VALUE.

-Amel

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

ST just has history here with EVAL boards using Ethernet and a single 25 MHz crystal, this includes a handful of DISCO boards.

The bulk of the DISCO/NUCLEO boards use the 8 MHz clock source output by the ST-LINK/V2. The ST-LINK/V3 clocks at 25 MHz, and outputs an awful 8 MHz

Occasionally when examples have been cross-ported there is a mismatch between HSE_VALUE and reality, this might also pollute the PLL settings, sometimes not. It usually shows up as a disparity in baud rates or core speed computations. I occurs sufficiently often, either with stock examples, templates, or user porting efforts, that it gets called out high on the check-list, and especially when the user complains about a 3X off baud rate.

The parts also start off the HSI (or MSI), so the HSE is usually not required, and earlier SPL code had fall-thru behaviour for HSE or PLL not starting rather than vectoring off to Error_Handler()

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

Hello @Anton Martinsen​ 

Thanks for the feedback, issue reported to the tool development team that will plan the correction.

Best regards,

Nesrine