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.

MSP430F5529: Chip Lockup when configuring XT2, DCO and XT1

Part Number: MSP430F5529
Other Parts Discussed in Thread: MSP-FET

Hi, 

We have  an MSP430 based product that is experiencing some random lockup issues.   When the chip locks up the MSP-FET debugger is unable to communicate, and we get a 

MSP430: Trouble Halting Target CPU: Internal error

message.  

The device has a 32768 Crystal on XT1 and a 24Mhz Crystal on XT2.   During LPM we disable the XT2.   The processor runs off of the DCO and the peripherals are running off of the XT2 when we are awake.

The issue comes about when the device is asynchronously awakened,  and we enter the lockup state at varying rates depending on the particular board we test.   In the worst case we will lock up 1/3 times in the best case it will go hundreds of times without a  lockup. 

We have been able to track the issue down to the following routine, that runs when we come out of low power mode (LPM3).

Any thoughts ? 

/*  

 * ======== Init_Clock ========

 */

VOID Init_Clock (VOID)

{

// DISABLE interrupts until clock is reconfigured

int key = Hwi_disable();

// Turn on a debug LED for tracking the lockup issue

LED_ERROR_ON;



//  Configure the Crystal selection port

P5SEL |= BIT2+BIT3+BIT4+BIT5;                   // Port select XT2 and XT1



// Enable the FLL

__bis_SR_register(SCG0);



// Set the FLL Initial parameters to Values from after the FLL settled at boot up. 

  UCSCTL0 = FLLSaveCtl0; // Get Clock Going at initial rate

  UCSCTL1 = FLLSaveCtl1;

 

  UCSCTL6 &= ~(XT1OFF+XT2OFF);      // Enable Both Crystals



// Initializes the clocks.  Starts the DCO at USB_MCLK_FREQ (the CPU freq set with the Desc 

// Tool), using the REFO as the FLL reference.  Configures the high-freq crystal, but 

// doesn't start it yet.  Takes some special actions for F563x/663x.  

//

// Assumptions are that there is an external 24MHz and 32.768KHz oscillators. The internal 32.768Khz

// This code sets up MCLK = 24MHz, SMCLK = 1MHz and ACLK = 32.768KHz.  

  // Loop until XT1,XT2 & DCO stabilizes

  do

  {

    UCSCTL7 &= ~(XT2OFFG + XT1LFOFFG + DCOFFG);

                                            // Clear XT2,XT1,DCO fault flags

    SFRIFG1 &= ~OFIFG;                      // Clear fault flags

  }while ((SFRIFG1&OFIFG) || (UCSCTL7 & (XT2OFFG + XT1LFOFFG + DCOFFG)) );                   // Test oscillator fault flag







  UCSCTL6 &= ~(XT1DRIVE0+XT1DRIVE1);                    // Decrease XT1 Drive according to

  // expected frequency



  UCSCTL4 = SELS_5 + SELM_3 + SELA_0;      // SMCLK=XT2 MCLK=DCO, ACLK = XT1



  // Disable LED for Diag purposes

  LED_ERROR_OFF;



  // Restore hardware interrupts if necessary

  Hwi_restore(key);

}

 

  • Hello James,

    When posting code in the forum, please use the </> button to insert code in a readable format. I've modified your post to reflect this change.


    Which LPMs are you using? Depending on the LPM level, different clocks are turned off. For example in LPM3, most lcock sare turned off except ACLK if powered by XT1 or other internal LF Clock. For exact clocks that are off or on in different LPMs, please refer to your device user guide.

    How did you trace the hangup to this series of code exactly? I see two scenarios here.
    1) Your Xtal could be unstable and thus you are stuck in the Xtal loop check. you may need to add extra logic here to pinpoint which oscillator fault source keeps triggering and thus which xtal is unstable.
    2) You could have the hangup in another portion of your code, but the debugger just keeps going to this code section. this would be due to errata EEM13 where the debugger reports the incorrect PC when being halted from an LPM.
  • Hi Jace,
    I traced the issue by toggling an LED around this routine. When I'm in the routine the light is on, and when I'm out the light is off. When I freeze up the LED is on.    I use LPM3. 



    -Jim

  • Jim,

    Then I would suggest implementing some additional checks within this routine to see where its getting hanged up exactly, or which Xtal is not locking correctly. then you can adjust drive strengths or external caps if need be. (check out this app note that can give further insight on what tests can be done for Xtal health -- http://www.ti.com/lit/slaa322 )

    Before doing that though, does this issue happen when not debugging, aka freestanding application? Does the issue occur when in Free Run mode?
  • Ok. Thanks for the app note.   The issue does happen regardless of whether it is connected to the emulator.  

  • Hey Jace, 

    Any thoughts on how to implement additional checks ?   The processor becomes unresponsive when the error occurs.

     

  • James,

    You can reduce the scope of you LED toggling to see if it gets stuck in the potential infinite loop of clearing OSC/Xtal fault flags. If it is (most likely) then you can only clear say XT2 + OSC flags and do a check if its clear, then do XT1 + OSC to see if it clears, then loop again. That way you can do LEd toggling in between these to figure out if one particular Xtal is not stable versus the other.
  • James,

    Did the above suggestion help resolve your issue? If there is no reply soon, I'll have to assume you have resolved your issue and I will close this thread.

**Attention** This is a public forum