• Locked Locked
  • Replies 9 replies
  • Subscribers 82 subscribers
  • Views 3154 views
  • Users 0 members are here
Support feedback
Options
Options

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.

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

Dan K
Expert 1210 points

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

 

  • 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

  • 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.

     

  • 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

  • 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

     

  • 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.

  • 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 

  • 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

  • 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
    
			
    

		
		
		
		
	
    
	
    
		
    
	
    

	            
                	
	
    
				
		                
                
                
                
                
                
                
        		
		
				
    
		
		 
		
		
     
    
	
    

    
			
    
			
    
		
    

		
    
	
    • 

		
	
  • 
		
    
			 











    
	
    
		
    
							
					
    
		
    
			
											
			
				
									
							
						
				
			
			
			
												
						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