Is there any way to detect that the RTC (Real Time Clock) crystal is bad? Is there any way to detect that some other aspect of the RTC clock source is not working for the purposes of the Watchdog?
I see example code that tests the HIBRIS.WC bit for the crystal to stabilize. Is this method guaranteed to detect a bad crystal or other clock failure? How long would be considered long enough to wait for this bit to be set before deciding that there is an unrecoverable error (other than using a fallback clock source)?
In this particular application, the RTC is not used for anything other than the Watchdog. In other words, no Wall Clock or Time of Day function is being used. Thus, if the RTC fails, there's no great loss to work around the missing feature. However, the Watchdog itself is critical, and must work if at all possible, and be detected if it's not going to work. Thus, if there is a way to detect a failed RTC, then the Watchdog could fall back to the less-accurate HIB LFIOSC at the same speed. The latter has been tested as sufficient, although the accuracy is not preferred. At least if the RTC is broken, the LFIOSC can perform within -70% to +127% of nominal.
Extra credit for detecting RTC failure on the fly, but I suppose that might require periodic testing - I dont see how it could be automatic since the Watchdog would stop working if the RTC failed after launch.
p.s. I noticed that the example code that I have found in TivaWare sets the Hibernate Oscillator into Low Drive mode after waiting for the crystal to stabilize. Is that the correct order? That's not supposed to be done first? The data sheet says that the drive should not be changed after the Hibernation Oscillator is running, so this looks suspicious. However, the example code does not Enable the RTC or select it as the Counter Mode until afterwards, so perhaps all is well. i.e. is it correct to wait for the crystal to stablize before setting the drive, but to make all other settings after the drive level?
