I am using a 149F device, it is setup to run of an 8MHz crystal.  My 
question is if for some reason there is an problem with the 
oscillator and the OSC fault is detected what happens?  It appears 
that the MCLK reverts back to run off the DCO, but then what?  Will 
the processor run off the DCO forever unless it is set back to run 
off the external crystal?  
There is currently no ISR for the OSC fault in the code, should I 
enable the OSC fault interrupt and construct a handler?  Any 
examples of what this ISR should look like?  I'm tiring to make the 
system as stable as possible since the product is expected to run 
continuously.

Thanks for the help,
Josh  

Normally the OSC fault flag is set after POR because the DCO needs 
some time to start up. You'll solve that problem by deleting all OSC 
fault flags in a loop
do (deleting flags and wait short time)
while (flags are set) 
at start up.

example (#defines could be different):
while((FLLCTL2 & 0x000F) > 0x0)
{
  FLLCTL2 &= ~0x000F; 
  for (k=0; k<0xFF; k++);
}
  IFG &= ~OFIFG;    

Regards
Ewald


--- In msp430@msp4..., "josh_schadel" <josh_schadel@y...> 
wrote:
> 
> 
> I am using a 149F device, it is setup to run of an 8MHz crystal.  
My 
> question is if for some reason there is an problem
with the 
> oscillator and the OSC fault is detected what happens?  It appears 
> that the MCLK reverts back to run off the DCO, but then what?  
Will 
> the processor run off the DCO forever unless it is
set back to run 
> off the external crystal?  
> There is currently no ISR for the OSC fault in the code, should I 
> enable the OSC fault interrupt and construct a handler?  Any 
> examples of what this ISR should look like?  I'm tiring to make 
the 
> system as stable as possible since the product is
expected to run 
> continuously.
> 
> Thanks for the help,
> Josh

A robust design strategy should include fault handling. This includes 
the NMI/OSC/FLASH ISR. On an oscillator fault the system will revert 
back to the DCO, so you should record, if possible the last actions and 
machine state before the oscillator failure, then try and restart the 
clock oscillator. Make sure that you do NOT get caught in a continuous 
loop. My clock start up code will loop forever if the clock fails to 
stabilise. This in itself is a diagnostic tool. The very next function 
is usually a power up sequence for peripheral power, so ifn that occurs 
my clock is OK, if not, and the beast doesn't spring to life it is a 
clock error. This is deliberate at start up. I don't want to even start 
running if there is a clock problem, however, this is not desirable in a 
clock fault handler. This should make a number of attempts to restart 
the clock then, somehow report the failure. In a long term system it may 
be necessary to use an external resistor for the DCO to achieve the 
desired high frequency clocking in the event of an oscillator fault that 
cannot be quickly recovered from. I would set the system up to 
periodically retry clock recovery, but try and maintain optimum 
operation by, for example having temperature/voltage calaibration data 
available for the DCO, using a secondary 32kHz oscillator (perhaps only 
on main clock failure) than can act as the base of a n FLL to obtain 
tolerable DCO accuracy. All of these approaches depend very much upon 
the impact a failed clock has in your design. Only at the design stage 
can you make the decision whether or not it is worth adding hardware, or 
spending resources on calibration (the 32kHz crytsal will almost 
certainly work out cheaper than a calibration routine.

Cheers

Al

josh_schadel wrote:

> 
> 
> I am using a 149F device, it is setup to run of an 8MHz crystal.  My 
> question is if for some reason there is an problem with the 
> oscillator and the OSC fault is detected what happens?  It appears 
> that the MCLK reverts back to run off the DCO, but then what?  Will 
> the processor run off the DCO forever unless it is set back to run 
> off the external crystal?  
> There is currently no ISR for the OSC fault in the code, should I 
> enable the OSC fault interrupt and construct a handler?  Any 
> examples of what this ISR should look like?  I'm tiring to make the 
> system as stable as possible since the product is expected to run 
> continuously.
> 
> Thanks for the help,
> Josh  
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> .
> 
>  
> Yahoo! Groups Links
> 
> 
> 
>  
> 
> 
> 
>