Running a bootloader at a different clock frequency than the firmware

[rsoc]

So this might be a easily answered question, and I think I know the answer, but I just want to confirm for safety:

If a bootloader program for an stm32l4 (or any family of chip) is set up to run at a different clock frequency than a firmware package on the same chip, can that be potentially harmful for synchronous operation between the two applications? For example, the bootloader starts first every time at 24 MHz, and then jumps to the firmware memory address, but I need the firmware application to run at a higher rate (48MHz). I cant change the bootloader at this point in time, so I wanted a second opinion if that can cause conflicts. I feel like no, because each application has its own start up items on initialization (including clock setup) so I feel like its ok. Am I missing something important?

[TDK]

No, you can change the clock speed within your program all you want. It's not like the bootloader and the main program can run simultaneously. Their only communication, if any, will be through memory.

[berendi · Accepted solution]

If the application is using the stock Reset_Handler and SystemInit functions, it will reset the clock setup to HSI/MSI (whichever is the power-on default of your MCU), and then sets up its own clocks from this state. It might not be able to catch all possible clock setups, but it will probably work.

Clock frequencies can be changed anytime in the application with some limitations described in the reference manual, but some peripherals might not take it well, so it might be necessary to disable or reset those peripherals through the RCC registers during or after the clock change. Disabling all peripherals for the jump from bootloader to application is recommended practice anyway. If the bootloader fails to do that, you can still do it in SystemInit.