Tool/software: Code Composer Studio
In our temperature rig tests we have occasionally seen instances of a failed LFXT (32.768kHz) crystal on our MSP430FR5043 design. We detected this failure as our timers were no longer accurate and we determined that the ACLK clock which was now running on MODOSC (39kHz) rather than the LFXT input due to the LFXT failure. We believe that the LFXT failure is likely due to the fact that our temperature chamber is not humidity controlled and, as such, the PCBs would get wet when warmed up from cold. This is a bit unfair on the crystal and ideally we’d have the PCBs sealed or humidity control the chamber. Neither of these options are easily available at present and in reality the fault only occurs occasionally. In the FW I have now implemented a feature that regularly checks the LFXT fault failure flag [CS_LFXTOFFG]. If I find it in the failed state then I enter the failure in our diagnostic logs and clear the flag. We are now monitoring the diagnostic logs after our rig tests to see if any units have shown the LFXT failure.
From my bench tests I can see that the crystal shows a failure if I place a drop of water on it (perhaps no surprise!). If I then dry the crystal it returns to life. Note that this is without having to power reset the unit or clear any flags internally – other than the CS_LFXTOFFG flag which I clear regularly during the fault polling. Once the crystal dries I see that the CS_LFXTOFFG flag is no longer being set. So as far as I am concerned things work as stated in the MCU datasheet.
However, we have had two instances of separate PCBs failing and then NOT recovering. Both these meters subsequently had the power disconnected and reconnected and the PCB then recovered. However, we have yet to capture a recent live failure and analyse it properly.
Can it be confirmed that I am handling the LFXT failure properly? i.e. there is no bit I am supposed to set/clear to force the LFXT to recover or reconfigure? From what I see and read the LFXT user configuration is returned to once the LFXT failure recovers (i.e. ACLK will again use the LFXT automatically once the LFXT starts to run again). Is there some instance that the ACLK will remain on the MODOSC without some user intervention?
