STM32H7RSxx + OEMuROT: updating clock settings

[Steve Melnikoff]

We have a board with an STM32H7S3, using STiROT and OEMuROT to run our own application. The application runs in place from external flash, and uses external RAM for data.

The process has proven extremely challenging, but we have been able to get the application to run...up to the point where it needs to initialise a peripheral which uses a PLL-dependent clock.

OEMuROT does some clock initialisation, but we need to change some of those settings, including turning on additional PLLs.

I've tried adding clock setup code to the app (originally generated by CubeMX), but it fails because you can’t change PLL settings while they’re running. So I added a call to the HAL function to reset the clocks first – but that also doesn’t work because we’re running from the external flash at this point, which relies on a PLL!

I then tried moving the clock setup code into the bootloader – in the code which runs at the end of proceedings, or at the start – but they also failed.

This code has to run from internal flash, but I wasn’t able to find a spot in the bootloader where this works.

So, how are we supposed to handle this?

[Steve Melnikoff · Accepted solution]

ST Online Support said:

Regarding your clock issue, the main constraint is that HAL related to clock configuration does not really allow updating the PLL configuration.

The actual clock setting is done in the system_stm32h7rsxx.c in SetSysClock function of the OEMiROT.

You will see only registers access is used.

So, you can make changes either in the OEMuROT or in your application.

In both cases you will probably need to either use register level programming or LL calls.

You can ask CubeMX to generate LL calls to help you having the right sequence. You will then be able to use only needed call to setup your PLLs

Thank you.

I found a solution, though it was fiddly.

I wrote a function which calls HAL functions, first to reset the clocks to defaults, then to set up the clocks and PLLs as we require.

All of the HAL functions it calls (and all the functions they call, etc) are local copies from the HAL library. This entire file, containing my function and the copies of the HAL functions, is executed from internal RAM (via linker configuration). This means that we can safely disable the XSPI peripherals, do what we need to do with the clocks, then turn the XSPIs back on again.