Out-of-box Cube code generated for STM32F411-E DISCO doesn't run. Error_Handler triggered in clock configuration.

[YIzAKat]

I've just switched to working on an STM32F411-E DIscovery. Starting a new project (STM32CubeIDE) and allowing it to populate the default peripheral config for the board is generating code that will not run (at least not for me).

The clock configuration halts in the Error_Handler after a timeout in the HAL_RCC_OscConfig() call prior.

This is on a completely virgin generated project with no code of my own added or alterations from the defaults. I have several of the same board and they all show the same problem. I don't recall having this problem in the past however it is a considerable time since using one of these boards.

I've not got this same behaviour on the non-Discovery STM32F411CE boards I have.

I've also not seen this problem on any of the Nucleo boards I've got.

This is with IDE version 1.6.1 and firmware package F4 1.26.1

What would be causing this? Before I start manually changing the clock configuration to try and sort this I thought it worth a check to see if anybody else experiences this.

Thanks,

Jason.

[waclawek.jan]

> Before I start manually changing the clock configuration to try and sort this I thought it worth a check to see if anybody else experiences this.

I don't think anybody cares about the gazillion ways of how Cube/CubeMX can and does go wrong.

Just go ahead and program the clock configuration normally. Note, that on the DISCO, you may have to use HSE bypass, if you intend to use the MCO output of STLink.

JW

[TDK]

It looks like default settings use MCO bypass. Ensure solder bridges and resistors are configured accordingly.

 

Looks like R66 is not fitted:

[waclawek.jan]

> looks like default settings use MCO bypass.

As the pictures show the 8MHz X2 populated, and schematics shows R25 populated, this is clearly CubeMX bug.

JW

[TDK]

I agree. Easier to change the default than to get it to work.

[YIzAKat]

Thank you both, yep my guess is that this is because the Nucleo boards I have used source the clock from ST-Link MCO (no crystal fitted) by default and the same invalid default has been generated here. I've checked my various Discovery boards and all have crystals fitted.

I'll just change the default and get on.

Getting late here down-under so I think this can wait until morning now.

Appreciate the quick response!

Cheers,

Jason.

[YIzAKat]

A final follow-up for anybody else encountering this thread/problem.

Things work well enough if you change the default HSE/LSE in the Cube from Bypass to Crystal.

I have found though that going back into the configuration a second time to change anything clock related generates duplicate code which I've had to remove. This happens sometimes but not all the time and I don't have the time or inclination to work out the exact circumstances that cause it.

When using the HSI/LSI I don't see this duplication problem (as far as I can tell).

I've opted to just do the clock config in my BSP.

The rest of the generated code seems fine but I'm a little wary of it now. I'm leaning towards going back to just managing all the initialisation in my BSP.

Cheers,

Jason.