STM32H563 External loader: HAL_RCC_ClockConfig() fails

[SimonTapmeyer]

Hello,

I am trying to develop an external loader application for the STM32H563ZI which is connected to a QSPI flash of type W25Q129JV. I have managed to create a project as described in the ST example. My problem is that the call to HAL_RCC_ClockConfig() in the function SystemClock_Config() always fails and enters the Error_Handler().

Does anyone have any idea why the clock initialization fails?

Best regards

[Tesla DeLorean]

>>Does anyone have any idea why the clock initialization fails?

Magic Eight-Ball suggests that one or more of the parameters passed is incorrect.

Clock/PLLs don't start as expected, or system is in the incorrect state. HSE_VALUE is wrong, VCO exceeds operational limits.

If the system is running you might not even need to change the clocking.

Fixture so you can debug the code from application space, provide telemetry/diagnostics to a serial port so you can understand what's happening internally. An ErrorHandler() or while(1) loop will cause timeout failures with STM32 Cube Programmer

[SimonTapmeyer]

Hello,

I use the nucleo H563ZI board. The clock settings are the same as for my main firmware project (which works without problems). I changed the linker script of my external loader project so that it runs from flash and call Init() at the beginning of the main(). When I run that with a debugger, it starts without problems. UART is working fine.

When I try to integrate UART into my external loader I experience crashes when I try to activate the clock of the UART (I only come here when I remove the call to the Error_Handler() in the clock initialisation).

[Tesla DeLorean]

Be aware that interrupts and vector tables aren't going to work as expected under the loader, and shouldn't be necessary.

Also that code in startup.s and main() are not going to be called. Be conscious that statics won't be initialized, and auto/local variables/structures on the stack will contain junk unless explicitly cleared.

The system clock shouldn't need (re)initializing, so either dispense with that or determine what specifically the HAL code is objecting too in what you're passing it. Consider if the structure is completely initialized, or may contain junk fields.

Get the UART working so you have some grasp as to what's broken.

[SimonTapmeyer]

Thank you for your ideas.

The UART fails to initialize because of an error in the function UART_SetConfig(). I added a screenshot with the part of the function that fails. The variable pclk contains the value 7 which results in usartdiv=0. When I run the same function with the debugger, the variable is 250.000.000 (which makes sense as I run the MCU with 250 MHz). It has to be a problem with the clock configuration but I don´t get what it is.