> I agree it is unlikely to be the RTC clock at issue unless it runs a watchdog of done form.

Fairly standard technique to run the watchdog off the RTC clock, because that might still work if the main clock is wonky.

Indeed, and historically, a slower RTC clock was also preferred because it would draw a lot less current during sleep mode. And it allows the rest of the system to throttle the main system clock up and down for power savings.

I said "historically" because I don't know is if these are still important issues on a modern system relative to all of the other things that are probably using the main system clock during sleep mode, and the more generous battery.

Clock throttling is still a thing. Many ARM Cortex-Mx parts, when in deep sleep, draw less current than the self-discharge rate of a standard alkaline battery sitting on a store shelf waiting to be purchased. It is common to leave the RTC running, stash important data in the small RAM that is backed up by a super-cap, and go into a “wait for interrupt” deep sleep mode.

In the embedded world this is very standard; timed wake-up from sleep is driven by the 32.768KHz clock, the code then wakes up faster clocks/peripherals as required by the application.