RTC criteria for activating CSS

[AFahr.1]

Hi ST Community.

A colleague and I were having issues on an STM32L4, in that the CSS detects an LSE failure and swaps to the LSI.

We looked at Errata ES00335 - Rev 15 and it confirms what we see that the LSI becomes unstable. We're looking for a workaround.

When the LSE is used as RTC source, what is the criteria for detecting a failure? The question is not about "the criteria is when the LSE fails", but rather, "what mechanism determines that an LSE failure has occured?" Is it a comparison with the LSI, HSE, HSI, timers, or any other solution that I'm not thinking about?

Glad to get an answer from the experts, as that will determine how we deal with our LSE errors. We can't avoid LSE errors as our product lives in a harsh environment and the oscillator might get damaged.

Cheers,

Albert

[waclawek.jan]

The exact criterium is not public, but it will be something simple, like one counter clocked by LSI and one by LSE, and a circuit which when LSI counts to N checks if LSE counted to M.

Nonetheless, the cited erratum makes LSECSS entirely unusable - the offered workaround, i.e. resetting the backup domain upon each powerup, is an absurd requirement. So, IMO the only real workaround is to forget about LSECSS entirely, and check LSE against any other clock in software, e.g. reading out RTC DR periodically (with all the caveats of the reading out RTC registers), or by using the internal connections of LSE to some timers (TIM15, TIM16) where an automated check could be devised by using this signal in the timer's slave-mode controller to reset the clock, and installing an "alarm" compare interrupt when a corresponding to maximum conceivable LSE period is reached by the timer's counter.

JW

[AFahr.1]

Thanks JW, I was hoping there'd be more of an explanation from ST, but I supposed that would be giving away their secret sauce.

One thought was to actually get rid of the LSECSS as well, that interrupt is not helping at all. Since we're running a timer in milliseconds as well, any time drift could be detected after all. Fortunately we do not need to be too accurate.

Cheers,

Albert

[waclawek.jan]

> I was hoping there'd be more of an explanation from ST

Please note that this is a primarily user-driven forum, with only casual ST presence.Maybe ST could offer an explanation, but for that you have to ask ST, through FAE or web support form.

JW