STM32 CSS Does the Recovery Oscillator Needs to be Activated?

[TrickyNekro]

Hi!

A simple question. I am using a STM32WB35 in a recent project of mine and I am doing some custom HAL - Low Level Stuff ( because in all honesty the ST HAL left me heavily wanting...).

It is not very clear to me, or I have not yet found that in the Datasheet ( RM0434 ), whether or not the recovery Internal Oscillators for the HSE Clock Security System,
either the MSI or HSI as selected by the STOPWUCK bit, should be Active or Not for the System to Recover in a case of HSE failure, or if the system turns them automatically on.

And... that´s the question. I am in the part where I just put multiple guards against setting and resetting certain bits, that´s why I am asking, it´s not easy to test at this stage.

Thanks in advance,

- Lefteris

[bson]

Should be easy to test... just short the crystal and see if it continues running, if so it has to be on the fallback.
(Actually, use a resistor just small enough, like 220Ω or something to cause the XO to stop, rather than an actual short.)

[TrickyNekro]

Well...

Got to write the code for the ports ( clocks alternate functions etc. ) then use the MCO to clock out the "deactivated" selected clock and see when creating a fault if it activate.

I don´t want to sound as arrogant, but I do know the procedure, there not lies the problem.
Problem is that the micro is on a custom board with stuff connected to it and I have just began writing the custom HAL, which means, even the ports don´t work if I don´t get to do the clocks first correctly
and just wanted to ask if someone had past experience to save some time. Sure, the CSS is not needed to test or write code for the other parts but... it feels lonely reading through a 1500+ page datasheet, only for the peripherals that is.


Anyhow, thanks for replying,

I´ll be testing it and I´ll post the answer, it´s interesting to know and some of these details either don´t exist or are very difficult to find ( all the while that an s-ton of people use STM32s ).

- Lefteris

[bson]

Yes, I understand what you're doing.  I've implemented more or less the same in the past, although not on versions with CSS.  I also observed that after starting the HSE and trying to stop the HSI it would never update its status to indicate it was stopped.  I don't know if this was because it actually wasn't stoppable, or just a problem with its status (I can imagine many programmers would never see any reason to wait for it to stop).  It's possible the CM7 clock tree is a little different, these are fairly new as is the CSS.  Sometimes for undocumented behavior or potential bugs, the only way to tell what's happening is to actually write code to see for yourself.  Hence the suggestion to test it.

[TrickyNekro]

It should be stoppable but only after setting another clock as system clock ( directly or indirectly when used with the PLL ) and only after the switch is made ( you can monitor the switch status bits and compare them with the switch setting bits ) and the clock you are switching to is "ready" first. But the HSI is also a bit peculiar as it can be forced ON by some peripherals like the low power UART and / or timer.

At least that´s the case with the STM, I am using. Don´t know if it would have been so similar in your case.

I make all this checks in software, before changing / disabling clocks, but the datasheet seems to imply that the hardware performs these checks also, as it explicitly states when you should perform software checks before you change / disable clocks, but like the case with CSS, leaves room for interpretation in other places.