MCLK stuck high

[AaronInSpace 4]

Hey all. Working out a bug right now I'm hoping for some help with. I have an MSP430F2619 on a project which freezes up occasionally. The WDT is off and no LPM is implemented. When it freezes, my crystal remains active, as does SMCLK which is driven off of it, but my MCLK, which is also driven off of it, stops oscillating and just idles high while the MCU remains unresponsive. My Vcc is 3.4V and my xtal is LFXTAL1 on HFXT mode at 5 MHz. As for what is happening in code, nothing unusual. Just running through a state machine which runs a task every 15 seconds and another every 3 seconds.

 

Does anyone know what it means if MCLK gets stuck high?

[AaronInSpace 4]

I just realized that the UART (driven off SMCLK) stopped outputting about 5 minutes before the crash happened on the last run. I can tell this because I have another output which continued to output timestamped data 5 minutes longer. I couldn't get the UART output coming in on my PC again until I restarted the MCU.

[AaronInSpace 4]

So I've found with some more testing that when the UART stops spitting out but my other continues, the MCLK appears corrupted before it completely freezes up. It looks as if it is switching between crystals very quickly. The signal isn't constant or clean. It might be a fault on my crystal, right? That was a problem I had the last few days which I thought I had fixed by replacing some wiring on the JTAG part of my board which looked nasty. What would happen is the DVcc would drop to 2.7V or so and the AVcc would stay at 3.4V. Then OFIFG would flag often as I could tell by flipping an LED on that fault. I checked the LFXTAL fault flag but it didn't show up. I don't have any other crystals hooked up or active.

 

Here's my initialization code:

 

void init_clocks_and_io(void)
{
volatile u32 i;

WDTCTL = WDTPW + WDTHOLD;		// Stop WDT
//    WDTCTL = WDTPW + WDTCNTCL;		// Clear WDT

// for LED
P1DIR |= BIT0;
P1OUT &= ~BIT0;

   // for MCLK output on P5.4
P5DIR |= BIT4;
P5SEL |= BIT4;
// for SMCLK output on P5.5
P5DIR |= BIT5;
P5SEL |= BIT5;

   // for ACLK output on P5.6
P5DIR |= BIT6;
P5SEL |= BIT6;

P5DIR |= BIT3;

// interrupt pin
   P2SEL &= ~BIT3; // P2.3 configured as I/O not peripheral module
   P2DIR &= ~BIT3; // P2.3 configured as INPUT
   P2IE  |=  BIT3; // Interrupt Enable for P2.3
   P2IES &= ~BIT3; // Edge Select for P2.3, interrupt triggered on a LOW-TO-HIGH transition
   P2IFG &= ~BIT3; // Ensure that the Interrupt flag IS INITIALLY NOT SET

BCSCTL1 = 0x87;	// Default reset
BCSCTL2 = 0x00;	// Default reset
BCSCTL3 = 0x05;	// Default reset

BCSCTL1 |= XTS;					// XTS = high-freq mode
BCSCTL3 &= ~ (BIT2 + BIT3);		// Turn oscillator capacitor to ~1 pF
BCSCTL3 |= LFXT1S_2;			// LFXT1S = 10 = 5MHz

do
{
	IFG1 &= ~OFIFG;		// Clear OSCFault flag
       for (i = 0xFFF; i > 0; i--);    // Time for flag to set
//		WDTCTL = WDTPW + WDTCNTCL;	// Clear WDT
} while (IFG1 & OFIFG);

IFG1 &= ~OFIFG;		// Clear OSCFault flag

BCSCTL2 |= SELM_2 + SELS;		// SELM = 5MHz & SELS = 5MHz (MCLK and SMCLK -> 5 MHz)

init_UARTA0();
init_UARTA1();

init_TimerA();

//	__enable_interrupt();
}  /* init_clocks_and_io() */

[zeke 693]

Is your msp damaged?

 

Try swapping in another msp.

[AaronInSpace 4]

So you wouldn't think the crystal could be to blame? I should have said earlier that when the crystal faults, the DCO takes over for MCLK until the crystal stops faulting at which time it should switch back to the crystal. The fact that the signal becomes unclean before the freezeup is what lead me to believe that the crystal was faulting. If it were easy to swap out the MSP430 I would certainly try that right away like you suggested but its in a moderately complicated system soldered in. Before I spend the day doing that I'm just hoping to hear why you lean towards the MCU instead of the crystal?

[zeke 693]

Usually, replacing the msp430 is the quickest way of determining if there's a hardware issue.

 

If you want to do a complete root cause analysis then you have to start fresh with code that you know will work.

 

In this case, you want to exercise the DCO to make certain that it is operating fully and properly. I recommend that you try out the TI sample C program "clks". This is it:

 

//******************************************************************************
//  MSP430x26x Demo - Basic Clock, Output Buffered SMCLK, ACLK and MCLK/10
//
//  Description: Buffer ACLK on P5.6, SMCLK(DCO) on P5.5, MCLK on P5.4 and 
//  MCLK/10 on P5.3.
//  ACLK = LFXT1 = 32768Hz, MCLK = SMCLK = CALxxx_8MHZ = 8MHz
//  //* External watch crystal on XIN XOUT is required for ACLK *//
//
//            MSP430F261x/241x
//             -----------------
//         /|\|              XIN|-
//          | |                 | 32kHz
//          --|RST          XOUT|-
//            |                 |
//            |             P5.6|-->ACLK = 32kHz
//            |             P5.5|-->SMCLK = 8MHz
//            |             P5.4|-->MCLK = DCO
//            |             P5.3|-->MCLK/10
//
//  B. Nisarga
//  Texas Instruments Inc.
//  September 2007
//  Built with CCE Version: 3.2.0 and IAR Embedded Workbench Version: 3.42A
//******************************************************************************
#include "msp430x26x.h"

void main(void)
{
 WDTCTL = WDTPW + WDTHOLD;                 // Stop Watchdog Timer
 if (CALBC1_8MHZ ==0xFF || CALDCO_8MHZ == 0xFF)                                     
 {  
   while(1);                               // If calibration constants erased
                                           // do not load, trap CPU!!
 }  
 BCSCTL1 = CALBC1_8MHZ;                    // Set DCO to 8MHz
 DCOCTL = CALDCO_8MHZ;
 P5DIR |= 0x78;                            // P5.6,5,4,3 outputs
 P5SEL |= 0x70;                            // P5.6,5,4 options

 while (1)                                 // 10 MCLK cycle loop
 {
   P5OUT |= 0x08;                          // P5.3 = 1
   P5OUT &= ~0x08;                         // P5.3 = 0
 }
}

 

Bust out your oscilloscope and measure the signals on pins P5:3,4,5 & 6.

 

Make sure that they are what they ought to be.

 

If they are then you can conclude that your program is doing something not quite right.

 

If they are not doing what they ought to be then replace the chip and try again.

 

Let us know how it goes.

[AaronInSpace 4]

Thanks for your suggestions. I'm too busy at the moment to get into this problem for another week or so but I can say that I have tried what you suggested (scoping the clock lines) and that is where I observed the strange phenomenon I have been observing. They look great until the problem starts creeping up an hour or so into run time. I also observed last run that leaving the JTAG unplugged from my system causes I2C timeouts, but keeps the MCLK from crashing and the oscillator from faulting! So that leads me to think it's a power delivery issue or a problem with the JTAG. Anyways, I plan to replace the MSP430 when I can but that requires soldering and desoldering it from a breakout board inside of a build and will take a while to get to. Again, thanks for your suggestions!

[zeke 693]

Sound like you have a hardware clock drift happening.

 

Are you using external bypass caps on your XTAL?

Are you configuring the MSP430 clock module to use internal CAPs?

[AaronInSpace 4]

Those sound like some good questions but I'm too much of an EE noob to answer them. I'll ask my EE guy to help me answer those questions. What I can say at my level of understanding is we have two capacitors with "22" etched on them going to ground. One on the XTAL input and one on output. Circuits I've seen on other TI products call for 12 but I guess that depends on the crystal (mine is soldered in pretty good so that I can't see its name but I guess we'll have to tear that out and inspect it)?