I want to quote the hardware manual:
"The crystal oscillator fault bits XT1LFOFFG, XT1HFOFFG, and XT2OFFG are set if the corresponding crystal oscillator is turned on and not operating properly."
My questions is this. What about the oscillator causes the fault bits to be set? The sentence implies that the oscillator is on, but not generating a signal. So how does the MSP430 check this? Is this a edge detect circuit of some kind.
We check the fault bit every 4 hours. When the bit indicates a clock fault has occurred, we create an entry log, clear the bit and switch the clock source back to external ACLK. We do nothing special to address the fault since we did not expect to ever see them – except in manufacturing.
So what could be causing the fault to occur and how does the MSP430 circuitry detect ths fault?
Hi David,
Typically the processor-specific data sheet lists a frequency below which the internal fault signal will be set. For example:
If the rate of oscillation of XT1 in LF mode falls below 10000 Hz, the internal fault signal might be set. If the rate of oscillation falls below 10 Hz, the internal fault signal definitely will be set. It only takes one overlong cycle to set the flag.
The x5xx User's Guide says that this fault signal has to be clear for 8192 consecutive cycles (for XT1 in LF mode) for the firmware to be allowed to clear XT1LFOFFG. I'm guessing that's what family you're using.
Jeff
Thanks Jeff.
But can you tell me how this fault is detected? In hardware, is this an edge triggered gate that starts a timer of some sort. In other words, how did you guys come up with 10Hz and 10000Hz. That has to be measured and compared some how.
-David
David,
Interesting question. Maybe Monday somebody from TI will respond, but they often don't chime in on internal design questions.
So I'll just guess.
An edge on the clock probably "latches" the state NO_FAULT. However, the "latched" state probably decays with time. If I had to guess I'd go with some kind of RC circuit where the clock edge charges the cap fully. Anyway, the amount of time it takes for the NO_FAULT state to decay into the FAULT state is going to be really hard to specify. It's voltage, temperature, process, and device dependent.
As long as edges keep coming, the latched state stays at NO_FAULT (not enough decay occurs between edges). But as soon as an edge doesn't arrive in time, we decay into the FAULT state and reset the 8192 counter (which controls XT1LFOFFG).
On old 1x family, the fault detection was more or less a retriggerable monoflop, triggered by the oscillator, whose expiration was latched into the OFIFG bit, while clearing the bit was triggering the monoflop. You had to clear the bit and then wait for the worst-case time whether it is set again.On 5x family, this mechanism has been expanded: the monoflop expiration sets a counter which counts down on every oscillation cycle. Its zero/non-zero output is reflected in the OFFG bit(s), which nail the OFIFG bit to '1' if set. So you cannot clear OFIFG unless all OFFG bits are clear too.
The counter size is different for different oscillators and oscillator modes. Also, the DCOFFG bit is not derived by such a monoflop/counter combo but rather indicates that the DCOx bits are all-0 or all-1 (indicating an FLL over/underrun and a required RSELx change).
_____________________________________Before posting bug reports or ask for help, do at least quick scan over this article. It applies to any kind of problem reporting. On any forum. And/or look here.If you cannot discuss your problem in the public, feel free to start a private conversation: click on my name and then 'start conversation'. But please do so only if you really cannot do it in a public thread, as I usually read all threads. And I prefer to answer where others can profit from it (or contribute to it) too.
David Escandon ... XT1LFOFFG, XT1HFOFFG, and XT2OFFG ... We check the fault bit every 4 hours....
Those bits are non-latching. If the oscillators are "operating properly" while you check them, they are all 0s. Faults during the rest of each 4 hours are not detected.
XT1LFOFFG, XT1HFOFFG, and XT2OFFG are ORed together and set OFIFG. which can only be cleared by software. If you check OFIFG, you are more likely to detect oscillator faults. OFIFG can also be used to trigger a reset.
old_cow_yellow [XT1LFOFFG, XT1HFOFFG, and XT2OFFG] are non-latching.
[XT1LFOFFG, XT1HFOFFG, and XT2OFFG] are non-latching.
I'm still just assuming that David's customer is using a 5xx/6xx MCU. I don't think those specific flag names are used in the other families. (??)
In the 5xx/6xx, the XT1LFOFFG and similar flags are actually latched:
And the "fault condition" they refer to is a "smart" condition. The crystal must be operating correctly for many consecutive cycles before that "fault condition" clears.
Jeff Tenney I don't think those specific flag names are used in the other families. (??)
You are right.
Thanks guys. This is very helpful, and more definiitve that the datasheet. Much appreciate.
Cheers,
David
How are you doing with this fault bit? I encountered same problem as you had last year, once a while, I guess in very special situation when the system voltage get interfered, but still in the spec tolerances, the XT1LFOFFG bit get set. I am using an oscillator, seems to me the Xin input is solid. have you figure out what triggered the fault in your system finally, any suggestion are appreciated.
David Sun
We found out that in production the crystals were giving us the problem. Make sure you have a good crystal in place.