WDT+: What determines clock failover to MCLK?

Rick,

What you would need to do here is to use the NMI interrupt whenever your ACLK fails. You can set the OFIIE bit to enable an interrupt trigger as soon as your ACLK fails. Look at section 5.2.11. When this interrupt fires, the code would need to service the ACLK to either try to power it back up or do some processing here. The WDT should also have failed-safe to MCLK at this point hence your time-out frequency may come pretty quickly.

Regards,

William

Hello,

ral613 said:

Is there any documentation that defines exactly what constitutes an ACLK failure for the WDT+? Does ACLK need to go away for a certain time, or just get messed up?

Specifically, if you are looking for what sets OFIFG (oscillator fault interrupt flag) causing WDT to switch to fail safe mode: If the XT1 OSC is in LF mode - any frequency between 0Hz - 10000Hz will set OFIFG.

Regards,

PT

William,

I watch OFIFG to see if the crystal oscillator failed and I am not seeing OFIFG being set when I get a watchdog reset. (I don't trigger an NMI, but OFIFG is supposed to be sticky so I check it later.) This is why I wondered if the conditions driving OFIFG and the WDT+ failover were different.

What made me suspect XO strangeness is that the real-time clock loses time during huge shocks also. I see timestamps read from the RTC that are known to be 25 ms apart being reported as anywhere from 12 to 20 ms, but only during these very high shocks. Before and after, the RTC is functioning correctly.

Priya,

Does the same logic control the setting of OFIFG and the failover to MCLK in a WDT+ module? I believe I am seeing WDT+ failover, but OFIFG is not being set, which leads me to believe the two mechanisms are similar, but not the same. In the WDT+ documentation I see a block called "fail-safe logic" with no indication that it is connected to OFIFG.

Thanks for the help everyone.

--rick

While the detection of the CLOCK/WDT problem might be interesting, the mere fact that the watch crystal seems to fail should make you think about a more physical solution.

Quartz crystals work by converting electrical energy into mechanical energy and back. If a shock is large enough to make the crystal stop oscillating for a short time, it might be large enough to cause a very high voltage spike too (you know these piezo spark ignition  for lighters/ovens? that's the same effect, based on a quartz crystal).

So worst case, this will not only make your RTC skip some milliseconds or cause device/WDT reset, it can even destroy the MSP. It's possible that you don't get a WDT reset because of a WDT clock source change/OSC fail, but a device reset due to an ESD spike.

In any case you should protect your quartz crystals from shock, mayby by a thick, soft double adhesive or something similar.
After all, quartz crystals are just that: quartz crystals. And crystal+shock = shatter.

The crystals are shock mounted already, although we are constrained by physical dimensions as to how much padding we can use. Our experience is that if we go much higher in shock level the crystal just shatters.

We have been looking at alternatives, but none of the ones we have found are accurate enough to run a real-time clock that keeps time to within a few seconds per month.

It's an interesting problem. We are way beyond rated specs for just about all the components in the device.

--rick

Did you look at the MEMS?
The description explicitely mentions their improved shock resistance compared to quartz crystals.
http://medicaldesign.com/electrical-components/alternative_quartz_oscillators/
Also have a look at this:
http://www.silabs.com/Support%20Documents/TechnicalDocs/SiliconOscillatorWhitePaper.pdf
It's not available for 32768Hz (but 1048576Hz should be available, with an external divider of 32)

Thanks. We are aware of the Silicon Labs parts but we have not looked at MEMS yet. 

--rick