STM32F4: HSE timeout increased from 0.5s to 5s, needs 10seconds to fallback to HSI

[giulianodianda]

Hi,
i saw mbed-src have been upgraded to CubeF4 drivers v1.5, which increases HSE timeout from 500 to 5000 ms.
https://github.com/mbedmicro/mbed/blob/master/libraries/mbed/targets/cmsis/TARGET_STM/TARGET_STM32F4/TARGET_NUCLEO_F401RE/stm32f4xx_hal_conf.h#L104
I don't know if there have been issues with 500ms timeout (afaik issues were about LSE on Nucleo boards with not correct capacitors), anyway now it takes 10 seconds to fallback to HSI (HSEwBypass->HSEwoBypass->HSI).

[Sissors]

5/10 seconds is indeed way too long for it to be useful. I consider 500ms already very long. With bypass mode there is no reason for anything to startup (unless your oscillator still needs to startup), and it should be nearly instantaniously detected.

The typical startup time with a crystal is specced at 2ms. Sadly no max is given, but still with that information significantly shorter than 500ms should be no problem, and longer for sure is not required.

[0xc0170]

Is the header file from the driver package? If yes, this should be asked in their community. I recall @bcostm redirected us to their community for questions related to their drivers.

[bcostm]

Yes in the Cube package the default timeout is set to 5 sec. I remember that I have changed it manually when I put the Cube package on mbed to 500ms. Maybe it is still too high and we can put a lower value. But recently someone has updated the CubeF4 driver and didn't change this timeout... This is why...

[ohagendorf]

I'm very sorry about this. I thought that the CubeF4 can be used without any changes except the NULL/HAL_NULL problem. @bcostm, are there more changes you did manually?

We needed the update because we are already using the new STM32F446 mcu which was introduced with CubeF4 driver v1.5. We've created an inofficial NUCLEO F446 (removed the original mcu and resoldered the F446 mcu) and are having a running mbed target. If @bcostm likes to have this target, I can send a pull request with it. Beside this an own board is in development.

[bcostm]

There is no problem @ohagendorf :-)

What I did usually when I put a Cube driver on mbed:

• Replace NULL by HAL_NULL. But in the latest Cube driver version (for example CubeF4 v1.5.0) the NULL definition has been removed from the xxx_hal_def.h file. So there will be normally no more an issue (the default NULL equals to 0 is used). For safety this will need to be checked when a new Cube driver is put on mbed.
• Decrease the different timeouts (mainly HSE, LSE).
• Remove the __IO in front of the constant tables (i.e. AHBPrescTable[] in system_xxx.c file. I have sent a request to remove it in the original Cube version.
  That's it.

For the NUCLEO_F446RE (I suppose it is this one) it is great that you have already developped it. It is in my todo list but I didn't start yet. And yes, you can publish it on GitHub. I will use it for testing the board as soon as I have it in my hand.

Thanks.

[Sissors]

Can this be fixed finally? The timeout is ridiculous and it is extremely annoying having to wait 10 seconds after every reset. Not to mention it makes waking up from deepsleep a bit stupid.

[star297]

It would be better to do away with the auto crystal detect code altogether and use the same format for all the STM platforms as employed for the L476 here. Most if not all other vendor platforms use this manual method.

#define USE_PLL_HSE_EXTC (0) // Use external clock
#define USE_PLL_HSE_XTAL (1) // Use external xtal
#define USE_PLL_HSI (0) // Use HSI/MSI internal clock (0=MSI, 1=HSI)
#define DEBUG_MCO (0) // Output the MCO on PA8 for debugging (0=OFF, 1=SYSCLK, 2=HSE, 3=HSI, 4=MSI)

I have set my L476 to external crystal, this initialises extremely quick and wake up from sleep or deepsleep is fast. The user can also choose the set up if the crystals are fitted depending on their application.

[0xc0170]

@Sissors what boards are still affected?

[Sissors]

At least the F4 boards, but I don't know if others are too.

I do like the automatic selection, it is a neat way to solve the problem, however it pretty much makes deepsleep useless (since afterwards it runs that same clock setup code again, instead of remembering what it did on boot), and 10 seconds is just a ridiculous length of time to see if there is an external clock (shouldn't take more than microseconds) and a crystal (which is 2ms typical according to datasheet, but with large spread).

[0xc0170]

@bcostm @dbestm @adustm Please look at the report above from Erik

[dbestm]

We think to put 200ms for all products.
OK for you?

[Sissors]

I think for startup that is fine.

However while it wouldn't be trivial, I think you would still need to reconsider how it behaves after waking from deepsleep. With twice 200ms timeout (once for external oscillator, once for crystal), it takes another 400ms after the wake event happened, before it will be processed (unless all processing happens in the interrupt loop).

[dbestm]

By default there is no timeout (the external oscillator is check first).
For people who are developing their own code by using sleep mode, it will be easy to modify the clock define to avoid this.

[Sissors]

In that case my board must have an issue, since it takes 10 seconds to startup.

[dbestm]

By default SB16 and SB50 (back of the board, where it's written "MCO") should be fit.
Maybe you have a wrong version of the board where it is not done.