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.

MSP-TS430PW28A 32kHz XT1

Other Parts Discussed in Thread: MSP430G2452, MSP-TS430PW28A

Hi there,

I use a MSP430G2452 with the eval board MSP-TS430PW28A.

I would like to use XT1 with 32kHz. When I use the debugger, it dosen't work properly and it stays in oscillator fault condition. If I disconnect  the debugger, it works.

I would like to know why it doesn't work with the debugger...

I use this code, it is writen by TI:

//******************************************************************************
//  MSP430G2xx2 Demo - LFXT1 Oscillator Fault Detection
//
//  Description: System runs normally in LPM3 with WDT timer clocked by
//  32kHz ACLK with a 1x4 second interrupt. P1.0 is normally pulsed every
//  second inside WDT interrupt. If an LFXT1 oscillator fault occurs,
//  NMI is requested forcing exit from LPM3. P1.0 is toggled rapidly by software
//  as long as LFXT1 oscillator fault is present. Assumed only LFXT1 as NMI
//  source - code does not check for other NMI sources.
//  ACLK = LFXT1 = 32768, MCLK = SMCLK = Default DCO
//
//  //*External watch crystal on XIN XOUT is required for ACLK*//    
//
//
//           MSP430G2xx2
//         ---------------
//     /|\|            XIN|-
//      | |               | 32kHz
//      --|RST        XOUT|-
//        |               |
//        |           P1.0|-->LED
//
//  D. Dang
//  Texas Instruments Inc.
//  December 2010
//  Built with CCS Version 4.2.0 and IAR Embedded Workbench Version: 5.10
//******************************************************************************

#include <msp430.h>

volatile unsigned int i;

int main(void)
{
  WDTCTL = WDT_ADLY_1000;                   // WDT 1s interval timer
  IE1 |= WDTIE;                             // Enable WDT interrupt
  P1DIR = 0xFF;                             // All P1.x outputs
  P1OUT = 0;                                // All P1.x reset
  P2DIR = 0xFF;                             // All P2.x outputs
  P2OUT = 0;                                // All P2.x reset
// An immedate Osc Fault will occur next
  IE1 |= OFIE;                              // Enable Osc Fault

  while(1)
  {
   P1OUT ^= 0x01;                           // Toggle P1.0 using exclusive-OR
  _BIS_SR(LPM3_bits + GIE);                 // Enter LPM3 w/interrupt
  }
}

#pragma vector=WDT_VECTOR
__interrupt void watchdog_timer (void)
{
    _BIC_SR_IRQ(LPM3_bits);                 // Clear LPM3 bits from 0(SR)
}

#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
    P1OUT ^= 0x01;                          // Toggle P1.0 using exclusive-OR
  }
  while (IFG1 & OFIFG);                     // OSCFault flag still set?
  IE1 |= OFIE;                              // Enable Osc Fault
}

Thank you in advance

  • Teh default load capacitance setting for XT1 is 6pF. You might want to raise it (depending on your crystals requirements) to 12,5pF by setting XCAP_3 in BCSCTL3 register.

    G Layaz said:
        for (i = 0xFFF; i > 0; i--);            // Time for flag to set

    IIRC, this is superfluous. OFIFG can only be cleared if all fault bits (XT2OF and LFXT1OF) are clear. They auto-clear once the crystal is running.

    G Layaz said:
    #pragma vector=WDT_VECTOR

    You must manually clear the WDTIFG bit in IFG1 inside the WDT ISR, or else the ISR will be called over and over again.

  • I change the capacity settings with 12.5pF but it stills not working when the debugger is running.

    G Layaz said:
        for (i = 0xFFF; i > 0; i--);            // Time for flag to set

    Jens-Michael Gross said:
    IIRC, this is superfluous. OFIFG can only be cleared if all fault bits (XT2OF and LFXT1OF) are clear. They auto-clear once the crystal is running.

    In all TI example they use this method to wait the crystal stabilisation, is it wrong?

  • G Layaz said:
    In all TI example they use this method to wait the crystal stabilisation, is it wrong?

    AFAIK, the wait is not required for 2x family devices. It is required for 1x family devices. Not to mention that an empty for loop may be discarded by the compiler anyway, as it doesn't change the systems overall state (code optimization)
    On 5x family devices, the loop must clear the fault its manually (they don't clear when the fault is removed), but no wait is required too.

    G Layaz said:
    but it stills not working when the debugger is running.

    Maybe it's not working without the debugger too, but you simply don't notice.
    i can imagine that the crystal is for some reason always at the edge of failing. So a fault is generated every now and then. When the debugger is attached and you're setting a breakpoint, you'll always see the ISR being entered. Due to the slow debugger access, the next fault is already flagged when you continue, so the main code doesn't seem to proceed. When not debugging, there's enough time between faults so that the main code does something in between.

    It can as well be related to the power supply. If with attached FET the circuit is powered by the FET, this may work out differently than without the FET and an external supply.

    BTW, you shouldn't use the same P1.0 signal to track both, fault ISR and timer ISR execution. You won't know which one is making the LED blink :)

  • OK, I will remove this loop.

    I put ACLK in the P1.0 (P1SEL |= BIT0) and when the debugger is connected, the signal is always moving in my oscilloscope and when I stop the debug, the signal is stable. It is why I think there is a problem with the debugger.

    I need the debugger, because I would like to connect a sensor with USI (SPI mode) and I need to check the signal step by step. The sensor need a 32 kHz for working...

  • G Layaz said:
    when the debugger is connected, the signal is always moving in my oscilloscope and when I stop the debug, the signal is stable. It is why I think there is a problem with the debugger.

    Not with the debugger, but caused by the use of a debugger. To update memory content information or for other things, the debugger has to halt the CPU core (and partly the clock system), fetch the information, then let it continue. This is intrusive and affects (external) timings. Also, an active debugger connection prevents any LPM above 0.

    G Layaz said:
    I need the debugger, because I would like to connect a sensor with USI (SPI mode) and I need to check the signal step by step. The sensor need a 32 kHz for working...

    You can't eat the cake and keep it. Either you step through the code, or you have it running undisturbed. Both is not possible at the same time.

    But you can attach a logic analyzer, toggle I/O pins at certain program points, and analyze the USI signals (and the signal port pins) on the analyzer display. Then the MSP can run undisturbed and you can still see what's happening when.

  • Thank you for your answer, now I working without the debugger and it running well.

    I eat the cake :-)

**Attention** This is a public forum