MSP430F5529: Shall I use crystal XT2 as direct clock signal for MCLK or to stabilize the DCO and use the DCOCLK for MCLK?

HF crystal oscillators consume mode power than DCO. On the other hand crystal oscillators are much more precise than FLL-driven DCO, especially if FLL reference sourced from internal calibrated RC oscillator. Xtal start-up speed is slower. So knowing which property of clock is important to you - you can use one or another.

tml said:

Hi!

What is the better attitude in case I have both XT1 and XT2 populated on the PCB (in this case MSP430F5529 LaunchPad) - use the XT2 crystal (4MHz) as clock signal (XT2CLK) for MCLK or to stabilize the DCO via FLL and use the DCOCLK for MCLK? In my application I do not care much about processing speed therefore I can use 4MHz, I can see these two options presented below - which will be better (the device is going to operate in the field with temperatures changing along the year from -30 to +40 deg of Celsius).

With Regards,

tml

On all my MSP430F5xx USB boards, XT2 is used for USB module and MCLK. Don't know about DCO/XT1/XT2 working temperature relation.

tml said:

use the XT2 crystal (4MHz) as clock signal (XT2CLK) for MCLK or to stabilize the DCO via FLL and use the DCOCLK for MCLK? In my application I do not care much about processing speed therefore I can use 4MHz,

Also, FLL works better, the higher the factor between reference and DCO output is. At a factor of 1, it becomes instable.

Besides this, you should tell what you want to achieve (and why!), not ask how to do something that you think you need but perhaps don't need at all.

Does the following code makes sense?

	WDTCTL = WDTPW + WDTHOLD;

	// ACLK = XT1 = 32768 Hz
	// MCLK = SMCLK = XT2 = 4.0 MHz

	//////////////////////// use XT1 32768 Hz ////////////////////////////////////////////
	P5SEL |= BIT4 + BIT5;						// Select XT1
	UCSCTL6 &= ~XT1OFF;							// Enable XT1
	UCSCTL6 |= XCAP_3;							// Internal load cap

	WDTCTL = WDTPW + WDTCONFIG;

	// Increase Vcore setting to level3 to support fsystem=25MHz
	// NOTE: Change core voltage one level at a time..
	SetVcoreUp (0x01);
	SetVcoreUp (0x02);
	SetVcoreUp (0x03);

    //////////////////////// use XT2 4.0 MHz ////////////////////////////////////////////
	P5SEL |= BIT2 + BIT3;						// Select XT2

	UCSCTL6 &= ~XT2OFF;							// Enable XT2
	UCSCTL3 |= SELREF__XT1CLK;					// FLLref = XT1

	do											// Loop until XT1 and XT2 stabilize
	{
		UCSCTL7 &= ~(XT2OFFG + XT1LFOFFG + DCOFFG);		// Clear XT2, XT1 fault flags
		SFRIFG1 &= ~OFIFG;						// Clear oscillator fault flag
	} while (SFRIFG1 & OFIFG);					// Test oscillator fault flag

	UCSCTL4 |= SELA__XT1CLK + SELS__XT2CLK + SELM__XT2CLK;			// ACLK = XT1, MCLK = SMCLK = XT2

There are 2 resons for which I ask:

1. without increasing the Vcore (lines 19-21) the launchpad works pretty unstable, encountering resets when in active mode, I also think that sometimes the contents of RAM is lost while CPU keeps running

2. with and without increasing the Vcore the MSP gets reset when there is a thunderstorm nearby.

The application of the Launchpad is the weather station that I described here: http://eltomek.blogspot.com/2014/10/diy-weather-station.html

Regards,
tml

tml said:

Does the following code makes sense?

Almost, but I would set it up as followed;

int main(void)
{
	// ACLK = XT1 = 32768 Hz
	// MCLK = SMCLK = XT2 = 4.0 MHz

	WDTCTL = WDTPW + WDTHOLD;	// Stop watchdog timer


	// Increase Vcore setting to required level to support fsystem.
	// 0 = 8MHz, 1 = 12MHz, 2 = 20MHz, 3 = 25MHz.
	// NOTE: Change core voltage one level at a time.
	//SetVcoreUp (0x01);
	//SetVcoreUp (0x02);
	//SetVcoreUp (0x03);


	// *** Setup XT1 *********************************
	P5SEL |= BIT4 | BIT5;					// Port select XT1
	UCSCTL6 &= ~XT1OFF;						// XT1 On
	// If required enable internal XT1 load cap's
	UCSCTL6 |= XCAP_3;
	//
	// Loop until XT1 fault flag is cleared
	do {UCSCTL7 &= ~XT1LFOFFG;}				// Clear XT1 fault flags
	while ((UCSCTL7 & XT1LFOFFG) != 0);	// Test XT1 fault flag
	//
	// Decrease XT1 Drive according to expected frequency
	UCSCTL6 &= ~XT1DRIVE0;


	// *** Setup XT2 *********************************
	P5SEL |= BIT2 | BIT3;					// Port select XT2
	UCSCTL6 &= ~XT2OFF;						// XT2 On
	//
	// Loop until XT2 fault flag is cleared
	do {UCSCTL7 &= ~XT2OFFG;}				// Clear XT2 fault flags
	while ((UCSCTL7 & XT2OFFG) != 0);		// Test XT2 fault flag
	//
	// Decrease XT2 Drive according to expected frequency
	UCSCTL6 &= ~XT2DRIVE0;


	// Set Clock sources
	UCSCTL4 = SELA__XT1CLK | SELS__XT2CLK | SELM__XT2CLK;


	// Stop DCO
	__bis_SR_register(SCG0 | SCG1);
	// Clear DCO fault flag
	UCSCTL7 &= ~DCOFFG;


	// Now that osc is running enable fault interrupt.
	// Add an UNMI_ISR to handle the fault.
	SFRIFG1 &= ~OFIFG;		// Clear Oscillator fault interrupt flag
	SFRIE1 |= OFIE;			// Enable fault interrupt

	// Enable Interrupts
	__bis_SR_register(GIE);

	while(1)
	{
		// ...
	}
}

Why it is necessary to increase Vcore I do not know, but I understand that you get the 3.3V via a LDO from the 3.8V, this may give an unstable 3.3V.

Your weather stations is a great project, but to protect it against ESD you have to do more than add a few low-ESR capacitors.

old_cow_yellow said:

Do you use the USB interface? During that, you probably need to turn on XT2. In most other situations, I think FLL with REFO as reference is quite adequate and robust.

No, although I use UART communication at 115200 and I found it to be a bit unstable so I switched to XT2.

old_cow_yellow said:

The other alternative is to use 32768 Hz crystal controlled XT2 as FLL reference

As far as I know XT2 is only HF and 4MHz or higher.

old_cow_yellow said:

(a) you have more choices of the FLL DCO frequency

I don’t see any difference, maybe you can clarify this a bit.

old_cow_yellow said:

(2) if and when XT2 fails, REFO will automatically kick in and help

I think this applies only to XT1-LF, but I could be wrong.

Thanks Guys!

Anyway, do you see any particular issue in my initial code that could cause resets that sometimes end up with total system hangup (i.e no WDT active, I suppose the infinite do loops because then WDT is held).

Why would increasing Vcore help in this case? Without increasing Vcore I had approx. 4h, 2k, sometimes 7k minutes of uptime after which reset occured, with Vcore lifted up I had more then 25k minutes and would probably have even more but the thunderstorm came and triggered a reset.

I'd love to understand what happens but I don't have the possibility of attaching the debugger and waiting for that long.

tml said:

...Anyway, do you see any particular issue in my initial code that could cause resets that sometimes end up with total system hangup ...

old_cow_yellow said:

Leo tried to help, but he was too polite and said you were "Almost right" instead of "Entirely wrong". Did you make any attempt to read Leo's code?

:-) I am ok with "entirely wrong" as long as I take a lesson out of it.

Yes, I've studied it and saw a major difference to be disabling the DCO and not assigning XT1 as a reference for FLL. I am currently testing the updated clock setup procedure as adviced by Leo, so far with promising results.

Hi Leo,

Unfortunately with the code presented the MCU still resets, I've observed a reset after ~7500 minutes (5 days). I will try to inrease the Vcore.

Best Regards,
Tomek