This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Starting fast external crystal - check code failing

Other Parts Discussed in Thread: MSP430F2272

Below is a function I am using to start an external crystal on an MSP430F2272.  The intention of the function is to ensure that the crystal has started before continuing.  If the crystal fails to start a certain amount of times (indicated by the OscFaults variable), the calling function will revert back to the DCO.  Before calling this function, the DCO is setup to run at 8MHz.  I am noticing that the line where I check if the OFIFG flag is set is occasionally returning true (as in it is not set).  If I put a break point on the break statement and watch IFG1, I notice that OFIFG is still set in IFG1 even though the conditional just before apparently says otherwise.

I am disabling OFIE before calling this function.  I need to use the crystal for accurate timing for algorithms elsewhere in the code.  It cannot stay on all the time because this is a low power application and I use a low power mode when nothing needs to be done.  What is causing the OFIFG flag to occasionally slip through, or should I take a completely different approach?

I should add that I have a special circuit with a switch for the crystal in order to verify that this function is working properly and appropriately handles an XT2 failure.

void StartXT2( void )
{
	unsigned int i,j;

	BCSCTL1 |= XTS;                         
	BCSCTL3 |= LFXT1S1;                 
	BCSCTL1 &= ~XT2OFF;              
	for(i=0; i<500; i++){
	  IFG1 &= ~OFIFG;
	  for(j=0xff; j>0; j--) _NOP();
	  if(!(IFG1 & OFIFG)) 
		break;
	}
	if(i < 500){
	  BCSCTL2 |= SELS + SELM_3;
	  IE1 |= OFIE;
	}
	else{
	  BCSCTL1 |= XT2OFF;				
	  OscFaults++;
	}
}

  • I'll add some more information to this post.  I've been fiddling with some things, and the above function appears to work great if I remove the for loop that just executes _NOP().  That for loop is there to wait at least the recommended 50 microseconds as per 5.2.7.1 in SLAU144J.

    The errata sheet for the MSP430F2272, SLAZ168G, mentions that a fault may not be properly detected on the LFXT1 oscillator.  Even though I'm using XT2CLK instead of LFXT1, could this be my issue?  The specific errata item is XOSC5.

  • Jacob Preston said:
    I should add that I have a special circuit with a switch for the crystal in order to verify that this function is working properly and appropriately handles an XT2 failure.

    That circuit might have caused XT2 to fail.

  • Yes, I am forcing XT2 to fail in order to test this code.  The problem is sometimes the code doesn't catch that it has failed and it goes on its merry way thinking it is running XT2 when it actually isn't.  I have seen this happen with the crystal completely removed from the circuit board, not with just a switch.

  • In order to delay for 50 usec, try replace the line: for(j=0xff; j<500; j--) _NOP(); by: __delay_cycles(50*8);

  • Jacob Preston said:
    I am disabling OFIE before calling this function.

    Clearing OFIE doesn’t help you. It only prevents the NMI from being called on oscillator fault. The fault is still detected and (for MCLK), the clock falls back to DCO.
    The question is: why gets OFIFG set. Apparently, your crystal is not properly oscillating.
    It may be the layout, the load capacitance, crosstalk from other signals.
    Most likely, it is a hardware problem. You should describe your hardware setup (schematics, maybe evn layout).

  • Jens-Michael Gross said:
    The question is: why gets OFIFG set. Apparently, your crystal is not properly oscillating.

    If I understand you correctly, changing clock configuration registers won't set OFIFG?  It appeared that it would only get set as soon as I modified the clock registers, thus why I disable OFIE while changing the clock configuration.

    Jens-Michael Gross said:
    Most likely, it is a hardware problem. You should describe your hardware setup (schematics, maybe evn layout).

    I can't get into too much detail about the schematic or layout, but the 7.37MHz crystal is as close to the MCU as possible.  Each pin on the crystal is connected to a 22pF capacitor.  There is a speaker close to the crystal (about 2mm).  Could the speaker signal be propagating onto the oscillator circuitry?  The speaker emits a signal outside of the range that humans can hear.

    I'll try using an oscilloscope to see if anything is propagating onto the crystal circuit.

  • Jacob Preston said:
    I'll try using an oscilloscope to see if anything is propagating onto the crystal circuit.

    I don't see anything on the oscilloscope that would cause an issue, but perhaps I'm not seeing everything.

  • Changing the clock registers won’t by itself set OFIFG. However, enabling a crystal that was disabled before, may instantly flag a fault for the crystal (until it is running) and this will set OFIFG. If you don’t have an NMI ISR that handles a oscillator fault, you never need to set (and never should set) OFIE. OFIFG will be set and indicate an oscillator fault even if OFIE is clear. It just won’t trigger an NMI.

    The speaker itself likely won’t cause the crystal to fail. Even though it is possible (the crystal is a transformer between electrostatic and mechanical energy, so vibrating the crystal will influence its oscillation). But more likely the electrical signals to the speaker may cause crosstalk and influence the electrical side of the oscillation.

    Unfortunately, attaching a scope to the crystal will have heavy impact on the oscillation too. (We bought an $800 high-impedance-low-capacitance active FET probe  - 1M||0.9pF - for measuring directly on crystal pins)

    The 22pF caps sound a bit low. This means only 12pF load capacitance, which is far less than what I have seen on our 8MHz crystals (around 18pF). Double-check the required load capacitance: double it and subtract two, this is the required capacitance per pin. Wrong load capacitance will influence frequency and significantly weaken oscillation.

  • Jens-Michael, digging through the post I located this thread. I'm also having problems starting the XT2CLK and I'm uing TI hardware--specifically the EM430F5137RF900 development board. I debugged my code using the jittery internal oscillator, but now need to switch to the 26MHz oscillator provided for the radio section. (It's a frequency counter application.)

    For testing, I'm poking registers within Code Composer, but the chip is not responsing "correctly".

    1)  To avoid overspeeding SM_CLK, I first set the divider to divide-by-2 and I see this on pin 14 of the '5137 set to the default alternate of PM_SMCLK. The frequency changes from ~12 to 6MHz.

    2) I clear the XT2OFF bit in UCSCTL6 to enable XT2. I see the bias on the oscillator clock pins change from 0 to ~700mV, but the oscillator doesn't appear to oscillate. I generously attribute this to the scope loading, but I don't think it's working. I removed the scope probe.

    3)  I change the selection in UCSCTL4 to source SM_CLK from XT2CLK

    4) I check the fault flag in UCSCTL7, XT2OFFG, to make sure it's cleared.

    I believe the oscillator doesn't start and the SM_CLK on pin 14 never jumps to from 6MHz to 13MHz (26MHz/2).

    Where am I going wrong? Was I handed bum hardware? Does the radio need to be enabled to allow XT2CLK to function?

    David Ehrenberg

     

  • I grabbed another '5137 develops PWB loaded my code. I probed the oscillator--same behavior.

    I cut/pasted Ray Keefe's code into my program and after commenting out:

    // P7SEL |= BIT2; // Set the PSEL bit for XT2IN SLAU208m 5.2.5, not on '5137

    and modifying:

    // UCSCTL6 &= ~(XT2DRIVE0); // set the correct drive level for 20MHz
    // UCSCTL6 |= XT2DRIVE1;

    to read XT1DRIVEx the code compiled and but does not work. The clock(s) never come on and the nothing (as far as I can tell) is running.

    Examine fault flags in Code Composer shows all flags down, but i don't know whether to believe this is the clock system is inoperatable.

    Any suggestions out there on why this fails and how does one source SM_CLK from XT2?

    DE

     

  • If one of the fault flags is set, any clock using this faulty oscillator falls back to REFO or DCO (REFO, it if is LFXT1, DCO if it is HFXT1 or XT2). Also, OFIFG gets set.
    As long as OFIFG is set, the clocks don’t switch back to the selected oscillator, even if the fault flags are clear. So after clearing all fault flags, you also need to clear OFIFG. Then the switch will occur.
    Note that on 5x family, all clocks have a fallback. It cannot happen that ACLK, SMCLK or MCLK are dead due to a non-oscillating crystal being selected as clock source. This could happen for ACLK on older families, but not for 5x family.

    Since no crystal is running at power-on, OFIFG is always set right from the start and needs to be cleared once all used crystals are up and running.

**Attention** This is a public forum