2020-09-25 05:42 AM
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.
2020-09-29 04:24 AM
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.
2020-09-29 05:16 AM
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.
2020-09-29 08:17 AM
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.
2020-09-29 01:23 PM
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
2020-09-30 07:26 AM
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
2020-09-30 08:50 AM
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.
2020-09-30 10:58 AM
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()
2020-10-09 07:34 AM
Hello @Anton Martinsen
Thanks for the feedback, issue reported to the tool development team that will plan the correction.
Best regards,
Nesrine