You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have access to two STM32 Nucleo boards (nucleo-f303ze and nucleo-f767zi) both do not have their external crystals populated (X3). Instead the HSE is provided by the on board stlink. They appear to work when powered via the stlink, However, one of my nucleo-f767zi boards would hang for several seconds on boot when powered externally via its header. I traced the issue back to the unit hanging waiting on the PLL to report that it was ready.
There appears to be a bypass bit (HSEBYP bit of RCC_CR register for HSE, and LSEBYP of RCC_BDCR register for LSE on the STM32F7) that must be set when the HSE/LSE is clocked by an external oscillator rather than connected to a crystal that must be excited. I switched to running off the HSI and the hang went away. I also populated X3 and the hang went away when running from the HSE. I am uncertain on what boards ST populates X3, if any. We should have a way to tell RIOT about the source of HSE and LSE so that the bypass bits can be properly set.
Steps to reproduce the issue
Power the Nucleo board without X3 populated and being powered externally. Observe that some boards will boot normally and that some copies will hang for several seconds or even minutes. Others have encountered the issue, which is what clued me into what was going on. See here.
I think @jmfriedt had issues with clock initialization on STM32 boards, I think on the iM880B. The symptoms do ring a bell.
I agree with the assessment that there should be a way to control this from the periph_conf.h.
Btw., I wonder why we are using defines (e.g. CONFIG_BOARD_HAS_HSE) here, rather some stm32_clock_conf_t structure as we do with other driver configurations. That would IMO make it a lot easier to document what settings are available and make use of the type system for some checks. I bet that the optimizer would do constant folding and that there is no runtime cost for this.
Description
I have access to two STM32 Nucleo boards (nucleo-f303ze and nucleo-f767zi) both do not have their external crystals populated (X3). Instead the HSE is provided by the on board stlink. They appear to work when powered via the stlink, However, one of my nucleo-f767zi boards would hang for several seconds on boot when powered externally via its header. I traced the issue back to the unit hanging waiting on the PLL to report that it was ready.
There appears to be a bypass bit (HSEBYP bit of RCC_CR register for HSE, and LSEBYP of RCC_BDCR register for LSE on the STM32F7) that must be set when the HSE/LSE is clocked by an external oscillator rather than connected to a crystal that must be excited. I switched to running off the HSI and the hang went away. I also populated X3 and the hang went away when running from the HSE. I am uncertain on what boards ST populates X3, if any. We should have a way to tell RIOT about the source of HSE and LSE so that the bypass bits can be properly set.
Steps to reproduce the issue
Power the Nucleo board without X3 populated and being powered externally. Observe that some boards will boot normally and that some copies will hang for several seconds or even minutes. Others have encountered the issue, which is what clued me into what was going on. See here.
Expected results
Board should not hang on boot.
Actual results
The board hangs for tens of seconds on boot.
Versions
My tree derives from 2023.04-devel
The text was updated successfully, but these errors were encountered: