search

RIOT-OS / RIOT

RIOT - The friendly OS for IoT
https://riot-os.org
GNU Lesser General Public License v2.1
4.87k stars 1.98k forks source link

STM32 Nucleo boards improperly clocked #19778

Open Enoch247 opened 1 year ago

Enoch247 commented 1 year ago

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

maribu commented 1 year ago

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.

maribu commented 6 months ago

I should move this one up the priority list in my todo