Grace Feedback - MSP430 MCLK not sourced by LFXTCLK when selecting LFXTCLK as MCLK Clock Source

Dan K

In Grace, when selecting LFXTCLK as the Clock Source for MCLK, the MSP430 MCLK is still running from DCOCLK.

Grace needs generate code to clear the OFIFG bit in the IFG1 register to enable MCLK to run from the LFXTCLK. This is documented in the manual, but the I thought the reason for Grace is to have some of those kind of obscure details taken care of automatically!

Dan

over 14 years ago

Michael Brunotte over 14 years ago

TI__Intellectual 1690 points

Hi Dan,

we just verified this and filed it as a bug. It will be fixed in the next release.

Thanks a lot for reporting it!

Michael

Anthony F. Seely over 14 years ago in reply to Michael Brunotte

TI__Guru 68810 points

I've been working with a 3rd party that has had similar trouble, except not using Grace but their own startup code.

However, on inspecting what Grace does, I see a discrepency between the User's Manual description of how to handle OFIFG and what's in Grace code.

The User's Manual for the 2xx series http://www.ti.com/litv/pdf/slau144h says on page 281 that you need to clear OFIFG, wait 50us, check OFIFG, if not clear repeat...

What I see in grace is this:

a) there is a time delay loop in BSCTL, but it's *before* BSCTL1 is written to enable XT2.

b) OFIFG is cleared not in BSCTL in a loop as described in the User's Manual - but once in SystemInit().

c) the delay between write to BSCTL1 and clearing OFIFG in SystemInit() seems to depend on how many other modules are enabled; so not really even ensuring that 50us goes by before clearing OFIFG.

I can see where some variation on the code in the datasheet might be wanted to so that additional initialization can happen using the DCO clock while waiting for XT2 to start up; but I'd still think that there should be some explicit time delay between BSCTL1 and SystemInit(); or perhaps some handling of the case where OFIFG is set again after cleared. Maybe this is intended to be done in the Osc Fault handler - but then this probably shouldn't be optional or at least there might be some educational information in Grace explaining the need for this handler.

William Goh over 14 years ago in reply to Anthony F. Seely

TI__Genius 16195 points

Anthony,

Anthony F. Seely said:
a) there is a time delay loop in BSCTL, but it's *before* BSCTL1 is written to enable XT2.

The reason for this is to ensure that the VCC has stabilized before configuring the DCO to a new frequency. This is to ensure that there won't be any VCC vs MCLK violation which may cause Program Counter corruption.

Anthony F. Seely said:
b) OFIFG is cleared not in BSCTL in a loop as described in the User's Manual - but once in SystemInit().

OFIFG flag should be cleared after enabling your external crystals to ensure that it has properly started up. It doesn't matter where the oscillator fault flag is cleared. But, it has to be after enabling the external crystal.

Anthony F. Seely said:
c) the delay between write to BSCTL1 and clearing OFIFG in SystemInit() seems to depend on how many other modules are enabled; so not really even ensuring that 50us goes by before clearing OFIFG.

It doesn't matter what the time it takes from configuring the external crystal to clearing OFIFG. The 50us is required only when you clear it and re-checking the OFIFG flag again.

Regards,

William

Anthony F. Seely over 14 years ago in reply to William Goh

TI__Guru 68810 points

Hi William,

Ok, but if I go to the family user's guide here's exactly the steps it calls out, and it doesn't seem to imply that waiting for OFIFG to clear is an optional step. I'd still be a bit concerned myself w. the mismatch between the User's Guide and Grace - but maybe if step 3 & 4 are really optional then updating the UG is in order.

Would you agree that Grace does steps 1 & 2 below, but skips 3 & 4?

Also, regarding:

"It doesn't matter where the oscillator fault flag is cleared. But, it has to be after enabling the external crystal."

- I'd probably add the caveat that it has to be after the xtal is enabled and before the application expects to be running off XT2,

because if this flag is set then the failsafe kick in and you're running off DCO which might be the wrong freq. for the application.

------------------------------------------------------------------------------------------------------------------------------------------------

From p. 281

The sequence to switch the MCLK source from the DCO clock to the crystal clock (LFXT1CLK or
XT2CLK) is:
1. Switch on the crystal oscillator and select appropriate mode
2. Clear the OFIFG flag
3. Wait at least 50 µs
4. Test OFIFG, and repeat steps 1 to 4 until OFIFG remains cleared.

; Select LFXT1 (HF mode) for MCLK
BIC.W   #OSCOFF,SR ; Turn on osc.
BIS.B   #XTS,&BCSCTL1 ; HF mode
MOV.B   #LFXT1S0,&BCSCTL3 ; 1-3MHz Crystal
L1   BIC.B   #OFIFG,&IFG1 ; Clear OFIFG
MOV.W   #0FFh,R15 ; Delay
L2   DEC.W   R15 ;
JNZ     L2 ;
BIT.B   #OFIFG,&IFG1 ; Re-test OFIFG
JNZ     L1 ; Repeat test if needed
BIS.B   #SELM1+SELM0,&BCSCTL2       ; Select LFXT1CLK

Jens-Michael Gross over 14 years ago in reply to Anthony F. Seely

Guru 227245 points

You both are right. The loop that clears and checks OFIFG is not necessarily required.
If you don't care for a possible fault, or whether the crystal is actually up (or present at all), you can omit thsi step. However, if you want to be sure the crystal is up and running, it IS necessary. Not that you could do anything if it won't start. All you could do is signalling the fault by an LED or such. And since Grace doesn't know what to do if the crystal fails (except perhaps an endless loop), it just skips the test completely, hoping for the best. Since MCLK will automatically fall back to DCO if the selected crystal source fails, this is not critical.

Feel free to write your own code with error handling if you need it.

Since there are no individual fault bits for the different crystals (if any), I'm pretty sure that MCLK will be switched to the crystal as soon as the crystal is detected running. Maybe MCLK is switched a dew times between DCO and crystal while the crystal becomes stable. I don't know. Howeever, with the current setup, I wouldn't expect a stable MCLK speed for some time after power-up. The loop would ensure this once the loop exists.

VictorTagayun over 13 years ago in reply to Michael Brunotte

Intellectual 655 points

Hello Michael,

To what version of grace was it fixed?

I have a 1.1.0 and IFG1 is not initialized when configured as 12kHz.

Victor

William Goh over 13 years ago in reply to VictorTagayun

TI__Genius 16195 points

Victor,

For the 12kHz, this is an internal low frequency oscillator. You would not need to clear the oscillator fault flag for this.

When you are using any external crystal for XT1 and XT2, then you would need to clear the oscillator fault flag to guarantee that the crystal has properly started up before using it. This oscillator fault check should be fixed in the latest grace release v 1.10 and above.

Regards,

William

VictorTagayun over 13 years ago in reply to William Goh

Intellectual 655 points

Hello William,

I have the Launchpad version 1.5 and I'm doing the VLO Lab exercise 3.

Below is the code for that exercise.

1	//***********************************************************						
2	// Lab3a.c  Using VLO/8 as MCLK						
3	//						
4	// Green LED on LaunchPad should toggle about every 3 seconds						
5	//						
6	// SFB 1/2012						
7	//***********************************************************						
8							
9	#include  "msp430g2553.h"						
10							
11	#ifndef TIMER0_A1_VECTOR						
12	#define TIMER0_A1_VECTOR    TIMERA1_VECTOR						
13	#define TIMER0_A0_VECTOR    TIMERA0_VECTOR						
14	#endif						
15							
16	void main(void)						
17	{						
18		WDTCTL = WDTPW + WDTHOLD;		// watchdog timer setup			
19							
20		P1DIR = 0x40;					// I/O setup
21		P1OUT = 0;					
22							
23		BCSCTL3 |= LFXT1S_2;			// clock system setup		
24		IFG1 &= ~OFIFG;					
25		_bis_SR_register(SCG1 + SCG0);					
26		BCSCTL2 |= SELM_3 + DIVM_3;					
27							
28		while(1)					
29		{					
30		  P1OUT = 0x40; 			    // LED on		
31		  _delay_cycles(100);					
32		  P1OUT = 0; 			    	// LED off	
33		  _delay_cycles(5000);					
34		}					
35	}

Please notice Line 24, without this code, the DCO will be used and the LED will blink faster.

You may not notice the blinking because it is very fast, you might need to add more delay.

When I do the Grace, there is no code of this type.

BTW, setting IFG1 = 0x00 will also work as VLO.

Regards,

Victor

Michael Brunotte over 13 years ago in reply to VictorTagayun

TI__Intellectual 1690 points

Victor,

you are right, the MCLK defaults to the DCO if the fault flag isn't cleared. We did not take this use case into account since we did not think that sourcing MCLK with the VLO would be a real use case. From the standpoint of power efficiency, this doesn't make sense. You would rather wake the device up periodically and let it run at DCO speed.

But since we allow it, you are right, we should at least have posted a note for that. We will do this in one of the next releases. For now, the simple workaround is to clear the fault flag manually after the Grace initialization.

Regards,
Michael

**Attention** This is a public forum

MSP low-power microcontrollers

MSP low-power microcontroller forum

Grace Feedback - MSP430 MCLK not sourced by LFXTCLK when selecting LFXTCLK as MCLK Clock Source