Hello everybody, I'm trying to program an STM32F446RCT6. It should run from HSE, which works fine after loading the program on the chip, but after rebooting (switching the voltage source off and on) it does nothing.

[MBjel.1]

I have already tried to use a second SystemClock_Config (copied from a fresh project after code generation), to first use the HSI after reboot and initialize everything (USART, GPIO,...), and then switch to the HSE, but it didn't work.

I would appreciate any help.

[Tesla DeLorean]

Your own board design?

Make sure BOOT0 is pulled LOW

Have Error Handler and Hard Fault Handler output useful information

[MBjel.1]

Yes, it's my own board design.

BOOT0 shouldn't be the problem, everything works perfectly fine when i choose HSI as the clock source.

I have to admit that I'm relatively new to this community, so I'm not sure what exactly you mean with Error Handler/ Hard Fault Handler. The Problem is not that an Error is thrown, if you mean that. The Problem is, that the STM won't change to HSE after rebooting.

[Tesla DeLorean]

Sorry, "didn't work" and "does nothing" are a bit non-specific.

Is it stuck in a loop somewhere? Inside the oscillator function, or outside? If not using a debugger in the power-cycle case, perhaps GPIO or UART to waypoint progress into the code, or common places where it goes to die.

If you are running from the PLL, you can't change that on the fly. With STM32 parts you generally want to switch on the secondary clock source, and then select that, along with speed appropriate flash/bus settings. Change the PLL settings, and bring that back up, before switching to it.

For other clocked peripherals you'll have to revisit the baud rates, dividers, etc.

The HAL is a bit bloated, I'd expect you'd need to stage through HAL_RCC_OscConfig() several times to get from A to B, but at register level it might be easier to manage.

void Error_Handler(void)

{

 // Place to silently die

 while(1);

}

void HardFault_Handler(void)

{

 /* Go to infinite loop when Hard Fault exception occurs, die quietly and hope no one notices */

 while (1)

 {

 }

}

I find it more enlightening to output actionable diagnostic data so I can root-cause the failure

[MBjel.1]

Hi Clive, sorry for my late reply.

"Does nothing" means here that after rebooting, I'm not able to communicate with the controller via UART. It just sends zeros (0x00) for ca. 10 seconds and then stops.

"Didn't work" means, that the controller still runs with the HSI instead of the HSE, when I try to change the clock source mid programm with a second SystemClock_Config() function.

Do you maybe have an example, how to mange it at register level?

[waclawek.jan]

If you use ST code (Cube) for the clock setup, the arbitrary timeout in waiting for HSERDY may be inadequate for your hardware.

Observe HSE startup time on your hardware (not directly, that would disturb the oscillator and give false results) but directing it to MCO pin out any other indirect method, and then adjust the timeout accordingly or write your own clock setup routine.

JW