• State TI Thinks Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 82 subscribers
  • Views 1194 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

32kHz oscillator on MSP430F4152

BuffaloEngineer
Intellectual 680 points

I'm having trouble getting the 32kHz oscillator to work with the MSP4152. Whenever I include this code snippet, the code gets stuck repeating this loop, so it appears the oscillator fault flag keeps going high:

  do
  {
    IFG1 &= ~OFIFG;                           // Clear OSCFault flag
    for (i = 0x47FF; i > 0; i--);             // Time for flag to set
  }
  while ((IFG1 & OFIFG));                   // OSCFault flag still set?

I've tried switching out oscillators and MCUs, but still have the same problem - when I probe XIN, I get 3V, when I probe XOUT, I get 0V.  I've also tried the example below (msp430x41x2_LFxtal_nmi.c), I just changed the output port that is toggled. It always enters the NMI, never toggles at 1sec intervals.  Any suggestions of what to try next?

 

#include  <msp430x41x2.h>
volatile unsigned int i;

void main(void)
{
  WDTCTL = WDTPW + WDTHOLD;                 // Stop WDT
  FLL_CTL0 |= XCAP10PF;                                 // Configure load caps
  IE2 |= BTIE;                                                         // Enable BT interrupt
  BTCTL = BT_ADLY_1000;                               // 1s Interrupt
  P7DIR |= 0x20;                                                   // Set P7.5 to output direction

  // An immedate Osc Fault will occur next
  IE1 |= OFIE;                                                        // Enable Osc Fault
  __bis_SR_register(LPM3_bits + GIE);       // Enter LPM3 w/ interrupts
  
}

// Basic Timer interrupt service routine
#pragma vector=BASICTIMER_VECTOR
__interrupt void basic_timer(void)
{
    P7OUT ^= 0x20;                          // Toggle P7.5 using exclusive-OR
}

#pragma vector=NMI_VECTOR
__interrupt void nmi_ (void)
{
  do
  {
    IFG1 &= ~OFIFG;                         // Clear OSCFault flag
    for (i = 0xFFF; i > 0; i--);            // Time for flag to set
    P7OUT ^= 0x20;                          // Toggle P7.5 using exclusive-OR
  }
  while ((IFG1 & OFIFG));                   // OSCFault flag still set?
  IE1 |= OFIE;                              // Enable Osc Fault
}

  • 0
    Intellectual 680 points

    Other things I've tried:

    I tried each of the XCAPxF settings, including 0pF with an oscillator with external 22pF capacitors. 

    I've tried including a couple different series resistors, 10k and 33k.  The rated ESR of the oscillators that I'm using is 50k max. I've also tried adding a parallel 1M resistor.

    I've tried both the Seiko SPT2AF-12.5PF20PPM and the Citizen CM200S32.768KDZF-UT. 

    I've tested the oscillators with another MCU, and they all work. 

    I'm not sure what else to try - anyone run into a similar problem?

  • 0 in reply to BuffaloEngineer
    Intellectual 340 points

    I have never worked with the F4152 but I think it should not be much different than any other F4x. And yes, the oscillator is a little tricky, it is running with very, very little energy. My first guess would be, that the capacity of the board is too large... you used 22pF caps... try 15pF first, the PCB will add some 3-5pF.
    Maybe you are using a socket? In that case, the socket will add another ~3-5pF and the smallest or second smallest XCAP setting might work without any external cap.
    Hope this helps...
    Johannes

  • 0
    TI__Genius 16205 points

    There are several recommendation guidelines that you can follow from our wiki site here.

    http://wiki.msp430.com/index.php/Crystal_Oscillators_Using_MSP430

    One thing that jumps out here is your load capacitance is too high. Try bringing it down to like 12pF.

  • 0 in reply to William Goh
    Intellectual 680 points

    I'm (still) having trouble finding a 32kHz crystal that will reliably stabilize.  I've been using the internal load capacitors, and have gotten a few 9pF crystals to work, but not consistently (some boards stabilize, others don't).  When testing oscillators I use the example code MSP430x41x2_clks.c (a copy of which is pasted at the bottom).  The crystals I'm trying are all over 50kohms ESR.  

    I use the statement FLL_CTL0 |= XCAP18PF; to set the effective load capacitance to 11pF (9pF from the crystal + 2pF parasitic).  The one thing I forgot to do in the prototype boards is isolate the GND beneath the oscillator from the rest of the GND plane.  Is this enough to prevent the oscillator from stabilizing?  

    Are there recommended crystals for the MSP430F4xx series?  Would a series resistor help it to stabilize?  Is there a recommended load capacitance (6pF, 7pF, or 9pF)?  Thanks very much!

     

    #include "msp430x41x2.h"

    void main(void)

    {

      volatile unsigned int i;                  // Use volatile to prevent removal

                                                // by compiler optimization

      WDTCTL = WDTPW + WDTHOLD;                 // Stop WDT

      FLL_CTL0 |= XCAP18PF;                     // Configure load caps (altered for use with 9pF crystal)

      for (i = 0; i < 10000; i++);              // Delay for 32 kHz crystal to

                                                // stabilize

      do

      {

        IFG1 &= ~OFIFG;                         // Clear osc fault flag

        for (i = 0; i < 1000; i++);             // Delay for osc to stabilize

      } while(IFG1 & OFIFG);                    // Check to see if osc flag is set



      P1DIR = BIT1+BIT6;                        // Set P1.6,1 as outputs

      P1SEL = BIT1+BIT6;                        // Select P1.6,1 as clk option

      while(1);                                 // Loop in place

    }


  • 0 in reply to BuffaloEngineer
    Guru 227245 points

    BuffaloEngineer said:
    volatile unsigned int i;  // Use volatile to prevent removal by compiler optimization

    This is a common mistake. 'volatile' does not mean 'do not optimize'. It means that this variable may be read and written outside the the current function scope. But in case of a local variable, the compiler KNOWS that nobody has a reference to it and therefore it CANNOT be accessed outside the program flow. So it will be optimized anyway.
    Relying on this 'trick' only works with specific versions of soem compilers and there is no guarantee that the code is portable or will even survive a newer version of the same compiler.
    If you need a delay, set up a timer (after system start, usign the DCO and a timer is as reliable as a working 'for' loop - after teh system clock has stabilized, it is way more precise) or at least use the __delay_cycles() intrinsic (from intrinsics.h) if available.

    Depending on the clock module version, it may take up to 100ms until the fault flag appears again after you cleared the fault flag (see device datasheet, minimum fault frequency). On some newer ones, you cannot clear the fault flag at all unless a certain number of clock impulses have passed the test.

    BuffaloEngineer said:
    The one thing I forgot to do in the prototype boards is isolate the GND beneath the oscillator from the rest of the GND plane.  Is this enough to prevent the oscillator from stabilizing?

    Definitely. This ground plane forms a big capacitor, boosting parasitic capacitance to maybe desasterouts heights.
    It's best to have nothing beneath the crystal and enclose the crystal area with a GND line. You can try to compensate on your current board by reducing the XCAP setting, but it is only a dirty hotfix and its effectiveness depends on the actual layout.

  • 0 in reply to Jens-Michael Gross
    Intellectual 680 points

    Thanks very much - is there a recommended area for the isolated GND?  For example, the area under the crystal + an 8mil border?  How far from from the rest of the GND plane should the isolated GND plane be?  

    I'm assuming I can connect it to the rest of the GND plane using a standard width trace at any point on the isolated GND, preferably midway between the 2 pads of the crystal.  

  • 0 in reply to BuffaloEngineer
    Expert 2080 points

    Did you try a crystal with higher ESR? The MSP430F41x2 is affected with XOSC8 silicon error (see errata : SLAZ055A), there is some workaround for this problem.

    The Epson FC255 works just fine with F2252 who has the XOSC8 problem too.

    I really don't think the quatz will not starts up with a poor pcb design, there is some interaction between ground loop and crystal lines of course, but it will only generates frequency drift especially with the MSP430 oscillator.

    On another way, have a look to SLAA322B page 7, there is some PCB layout example, you can download some routing from developpement board (launchpad for example). I you want I could send you the layout of our guard ring tomorrow (didn't have the information on me).

  • 0 in reply to BuffaloEngineer
    Guru 227245 points

    Whiel it might be advisable from the EMI view to have a ground plane beneath the crystal, it is advisable to keep any ground (or other signals) as far away from the crystal pins and the wires from crystal to MSP and the load capacitors. Else the ground plane (whether isolated or not only affects the influence of currents through the plane, which is of course a disturbing influence too) forms a parasitic capacitor with the wires.
    You can, of course, try to calculate it and select your load capacitors (or the MSP load capacitor settings) accordingly. Or you leave the space below the capacitor and the connection free. Thin traces from MSP to crystal reduce the parasitic capacitance, but increase the resistance (but with a crystal with 50k ESR, it doesn't really make a difference).

    Side note: a 3.2mm wire over a ground plane with 1.6mm PCB thickness forms a near-perfect simulation of a 50 Ohms antenna cable. So much for ground planes and parasitic (or in this case expected) capacitance.

**Attention** This is a public forum