MSP430F6723 XCAP setting has no effect

So far could not get further, maybe it's something like a problem I had before:

http://e2e.ti.com/support/microcontrollers/msp430/f/166/t/240709.aspx

Any help appreciated

First thing, don't use bitfields on an MSP. Bitfields are highly ineffective, especially on hardware registers. They prohibit optimization, increase code size and execution time. They are convenient, but better spend a few seconds more (if any) to construct a proper single-line assignment like UCSCTL6 = XCAP_3 | XT2OFF; than wasting some microseconds each time the code is executed. Each time you set or clear a bit, the compiler needs to generate a separate read-modify-write operation instead of a simple assignment for all together.

Now for the problem. You say the clock frequency doesn't change when you switch the internal caps. How do you measure? Outputting ACLK/SMCLK on a pin? Do you follow the procedure of ensuring that the crystal is up? I tmight be that you're still running on REFO fallback all the time (which will of course be unaffected by any XCAP setting)

For ensuring that crystal is up i do:

    do
    {
        UCSCTL7_bit.XT1LFOFFG = 0;
        UCSCTL7_bit.DCOFFG = 0;
        UCSCTL7_bit.XT2OFFG = 0;
        SFRIFG1_bit.OFIFG = 0;
        __delay_cycles(1000);
    }    while (SFRIFG1_bit.OFIFG);

The micro is definately not running on internal clock (no fallback).

We use a meter that directly measures the crystal frequency without connecting to the crystal.

Thanks for attendance!

This is indeed unexpected behaviour.
Well, it is possible that the DCO reports a fault. this happens when it is set to minimum or maximum tap. Then your attempt to clear DCOFFG fails and OFIFG cannot be cleared too. Since XT1 fallback to REFO is the startup condition, it won't end.
However, in this case you weren't able to leave the do/while.

Also, even if, since you are measuring the crystal frequency directly, you should see a difference for different XTAL settings in the crystal speed independently of the acceptance of the crystal signal by the clock module.

Can you tell me hat kind of meter you use? We bought a special FET probe (ultra-low capacitance) to connect to the crystal and check the oscillation with a scope. (we had severe startup problems with a certain batch of MSPs)

Actually we use the ACLK output in production for measuring the crystal frequency.

I tested it with the following sample of M430Ware/slac511c.zip (slightly modified) using a frequency counter (Type TOE 6723, Manufacurer TOELLNER)

#include <msp430.h>

void main(void)
{
    WDTCTL = WDTPW | WDTHOLD;              // Stop WDT

    // Setup J1.3 ACLK
    PJDIR |= BIT3;                          // ACLK set out to pin
    PJSEL |= BIT3;                          // PJ.3 for debugging purposes.

    // Setup LFXT1
    UCSCTL6 &= ~(XT1OFF);                   // XT1 On
    UCSCTL6 |= XCAP_0;                      // Internal load cap

    // 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);              // Test oscillator fault flag
    UCSCTL6 &= ~(XT1DRIVE_3);               // XT1 stable, reduce drive strength

    while(1)
        {
            asm("NOP");
        }
}

For XCAP settings XCAP_0..XCAP_3 there were no differences in frequency.

Even if I comment out the settings for UCSCTL6

    // Setup LFXT1
    //UCSCTL6 &= ~(XT1OFF);                   // XT1 On
    //UCSCTL6 |= XCAP_0;                      // Internal load cap

the software gets past the loop.

The XT1 oscillator circuit seems still working since when I put a finger on the crystal, I can manipulate the frequency measured at ACLK.

Edit:

ACLK frequency when using crystal on XT1 is 32.769,553Hz (no matter what XCAP setting)

ACLK frequency when using REFO is 33.008,069Hz

Also tested a completely other crystal (short-) wired directly to the XIN/XOUT pins and the traces on pcb cut with similar results.

That's really strange.
It might be a hardware problem in teh MSP itself.

usually, with no external caps and internal caps disabled, the crystal shouldn't oscillate at all. Possibly the internal switches are for some reason fixed to a working setting. Can you replace the MSP (or check with a different PCB/MSP)?
It would be a very unlikely but not an impossible fault.

I already checked this with at least 5 different pcbs and micros.

I also tested different crystals.

I read through the AUX section of the manual since the oscillator circuit is powered by AUX3, but didn't find any hints.

The weird thing is that just putting a finger near the crystal or changing the ambient temperature affects the frequency but not the xcap settings.

I'm pretty shure there is something missing, but I can't get it.

Since the chip revision is A, maybe it's because the micro is too new......?

Maybe someone can confirm the problem.

Thomas Henle said:

Since the chip revision is A, maybe it's because the micro is too new......?

It's possible that there is a bug in the silicon revision that affects all MCUs you have.

We too ha dsome problems with the oscilaltors (MSP430F1611 and XT2 8MHz crystal). We didn't change the PCB (in fact, the batch that sometimes failed to start the crystal was build on PCBs form teh same order as the ones that worked before), the crystal brand was the same as before, firmware was the same, but suddenly, 10% of the devices failed to work right after production. Changing the capacitors or replaing the crystal worked (we suspected crystal failure due to mechanical stress during transport, or wrong capacitors, but next order didn't change the situation), but we never found an explanation except perhaps a silicon change on the MSP itself.

So unexplainable crystal problems aren't new to me :(

However, I never worked with or have a 6723, so I cannot check it myself.

OK, thank you very much!

So we will contact our distributor to check if we can get some devices from another production lot, maybe there's already a new inofficial chip revision.

Though there's no errata for this.

Hi Thomas,

Thomas Henle said:

I already checked this with at least 5 different pcbs and micros.

One thing that came to my mind is that it would be very helpful if you could perform your testing on the MSP-TS430PZ100B EVM board and check whether you observe same results.

The EVM has solder holes for the XT1 crystal on the PCB so you can easily solder one on it.

Regards,

Mo.

Hi Thomas,

Thomas Henle said:

UCSCTL6 |= XCAP_0;                      // Internal load cap

This line does nothing since XCAP_0 = 0. You'd have to do UCSCTL6 &= ~XCAP_3 to really clear those bits. Since UCSCTL6 defaults to having XCAP_3 set as the default (see user's guide), this current piece of code is really always running with XCAP_3 setting if you are just using "UCSCTL6 |= XCAP_x" to change the settings. You should be able to see this in the debugger if you pause the code and look at this register to see the current setting in UCSCTL6.

If you add the line "UCSCTL6 &= ~XCAP_3; //clear XCAP setting" before the line where you are putting on your new XCAP value, do you get any different result?

Regards,

Katie

Katie Enderle Pier said:

his line does nothing since XCAP_0 = 0.

Good catch, Katie. This completely slipped my attention. No MSP problem, but a basic coding mistake.

Hi Katie, hi Jens

for the example code you're absolutely right!

In the original code in my application (see posted above) I use the bit definitions.

    UCSCTL6_bit.XCAP0 = 0;
    UCSCTL6_bit.XCAP1 = 0;
 

So each bit is set/reset accordingly.

Though the settings did have no effect.

The real reason was the setting of the SVSMHCTL register.

To save some power (it's a battery sourced remote control) I disabled both, SVSH and SVMH.

In this case the XCAP settings don't work, the crystal frequency is always as if XCAP = 11b.

Leaving SVSH and SVMH enabled results in working XCAP settings.

Strange but it's true:D

Hi Thomas,

Can you attach a code snippet/example with your PMM + UCS configuration so I can look into this? That does sound odd, but I'm wondering if it could have something to do with the fact that the crystal power on this part comes from AUXVCC3. Are you testing all of this on the MSP-TS430PZ100B?

Regards,

Katie

Hi Katie,

here's the code for MSP-TS430PZ100B

#include <msp430.h>

void main(void)
{
    WDTCTL = WDTPW | WDTHOLD;                  // Stop WDT

        P1DIR |= BIT0;                          // Set P1.0 to output direction
        
    // Setup J1.3 ACLK
    PJDIR |= BIT3;                          // ACLK set out to pin
    PJSEL |= BIT3;                          // PJ.3 for debugging purposes.

    SVSMHCTL &= ~(SVSHE | SVMHE);
        
        // Setup LFXT1
    UCSCTL6 &= ~(XT1OFF);                   // XT1 On
    UCSCTL6 &= ~XCAP_3;
    UCSCTL6 |=  XCAP_1;
        
    // 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);              // Test oscillator fault flag
    UCSCTL6 &= ~(XT1DRIVE_3);               // XT1 stable, reduce drive strength

    while(1)
        {
            if (SFRIFG1 & OFIFG)
            {
                __delay_cycles(100000);                             // Delay
            }
            else
            {
                __delay_cycles(400000);                             // Delay
            }
            P1OUT ^= BIT0;                             // Toggle P1.0 using exclusive-OR
        }
}

Simply comment the line where "SVSMHCTL" is initialized in/out.

Thomas

Oh, those dreaded bitfield types!

I agree that they are convenient to use and avoid problems like the non-functioning OR instruciton.

However, they produce highly inefficient code and in this specific case, they also cause unintended (and unavoidable) spikes.

Thomas Henle said:

    UCSCTL6_bit.XCAP0 = 0;
    UCSCTL6_bit.XCAP1 = 0;

In this case, XCAP changes from 3 to 2, then to 1. Lots of superfluous code, since the compiler has to mask teh register for each assignment separately, and also you have an intermediate state which is neither the sourc enor the destination state and may cause havoc. (Well, in this specific case, it doesn't, but think of the OUTMODes of the timer modules. Worst case, you switch to OUTMOD_0 temporarily, causing an immediate output change rather than just changing the behaviour at next compare event)

If there were UCSCTL6_bit.XCAP, taking values from 0 to 3, this would be less bad. Still the code is inefficient and big, compared to a simple

UCSCTL6 = (UCSCTL6 & ~XCAP_3) | XCAP_0;

which can be optimized by the compiler to a simple single instruction.

Note: It is more important to make the result fast, small and efficient, than to make the coding convenient for the coder. We're not writing PC programs (where my 1000 times faster PC with 1000 times more ram doesn't do the job faster than my old PC/AT.)

In general I'm absolutely on your side. The code in a small micro should be as efficient as possible without loosing the readability of it.

In this case I could not find it that inefficient:

     UCSCTL6 &= ~XCAP_3;
B2F0F3FF6C01 AND.W   #0xfff3, &0x16c
     UCSCTL6 |=  XCAP_1;
A2D26C01     BIS.W   #0x4, &0x16c

Compared to        

     UCSCTL6_bit.XCAP0 = 1;
A2D26C01     BIS.W   #0x4, &0x16c
     UCSCTL6_bit.XCAP1 = 0;
B2C26C01     BIC.W   #0x8, &0x16c

Hi Thomas,

I think what was really happening with the code you posted is that you were resetting your part over and over, so the XCAP setting was always at the default (which is XCAP_3) and all your other clocks were also simply set to the default settings.

You need to unlock the PMM registers before you can modify them, or else you trigger a PUC (see the PMM register description on p. 114 of the 5xx/6xx user's guide which describes the PMM password mechanism).

So when I ran your code, this line always causes the part to reset:

SVSMHCTL &= ~(SVSHE | SVMHE);

Because the password needed to be written in PMMCTL0 before doing this.

If you put a breakpoint at the top of the code you will hit it repeatedly because a PUC happens and you go back to the beginning.

Your code works correctly without this line, correct?

You can try replacing it with this instead:

    PMMCTL0_H = 0xA5; 	//unlock PMM
    SVSMHCTL &= ~(SVSHE | SVMHE);
    PMMCTL0_H = 0; 		//lock PMM

Regards,

Katie

Hi Katie,

meanwhile I have so many code snippets and test projects for different target lying around.
So the code I posted was actually not the one I used for latest tests.

Here's the code for our target pcb with XCAP=01b using a MSP430F6723:

#include <io430.h>

void main(void)
{
  WDTCTL = WDTPW | WDTHOLD;

	P9DIR_bit.P9DIR1 = 1;
		
	PJDIR_bit.PJDIR3 = 1;
	PJSEL_bit.PJSEL3 = 1;

	PMMCTL0 = 0xA500;				
	SVSMHCTL_bit.SVSHE = 1;	
	SVSMHCTL_bit.SVMHE = 1;	
	PMMCTL0_H = 0x00;				

	UCSCTL6_bit.XT1OFF = 0;
	UCSCTL6_bit.XCAP0 = 1; 
	UCSCTL6_bit.XCAP1 = 0;
		
	do
	{
		UCSCTL7_bit.XT1LFOFFG = 0;
		UCSCTL7_bit.DCOFFG = 0;
		UCSCTL7_bit.XT2OFFG = 0;
		SFRIFG1_bit.OFIFG = 0;
		__delay_cycles(1000);
	}	while (SFRIFG1_bit.OFIFG);
	
	UCSCTL6_bit.XT1DRIVE0 = 0;
	UCSCTL6_bit.XT1DRIVE1 = 0;

    while(1)
		{
			if (SFRIFG1 & OFIFG)
			{
				__delay_cycles(100000);
			}
			else
			{
				__delay_cycles(400000);
			}
			P9OUT ^= BIT1;
		}
}

I had to split into 2 post, because my post was permanently denied.

The results are as follows:
SVSH and SVMH disabled: f=32768.76Hz (same as XCAP=11b)
SVSH and SVMH enabled: f=32771.91Hz

On the MSP-TS430PZ100B with shipped MSP430F6736 and crystal the results are as follows:
SVSH and SVMH disabled: f=32768.10Hz (same as XCAP=11b)
SVSH and SVMH enabled: f=32769.31Hz

Can you confirm this?

Thanx
Thomas

Thomas Henle said:

In this case I could not find it that inefficient:

You're right, in this specific case, it isn't. However, if you had to set both bit (or clear both bits), the bitfield code would be same size while both bits could be set or cleared in one |= or &= instruction.
If you have multi-bit bitfield members, things are even worse.

However, in your example, you have an intermediate state of both bits clear (or both bits set, depending on execution order), which might be desastrous in some cases. Imagine switching between two OUTMOD settings in a timer, with an intermediate state of 0, you'd unintendedly switch the output state to the current OUT bit value when switching the bits using the bitfield.

Hi Thomas,

What position are the AUXVCC1-3 jumpers in on your MSP-TS430PZ100B target board? This could have an effect on crystal behavior I think, because the crystal is powered off of AUXVCC3.

Does the pin toggling on your board indicate if the fault flag is set or not?

Regards,

Katie

Hi Katie,

the jumpers are all set to DVCC.

The fault flag is not set.

Thanx

Thomas

Hi Thomas,

I have not really reproduced a correlation with SVS settings. I think that you could have your crystal working (though more or less reliably) even without the correct cap setting, it just won't be robust. I don't think that you are seeing the XCAP value not taking effect, I think your crystal is just running anyway (though probably at a worse safety factor than if you use the correct setting, if you try using the wrong XCAP setting) but it could be more susceptible to noise and other disturbances. Turning the SVS on and off changes the current consumption of the MSP, so depending on what you power the MSP off of if it is causing your voltage supply to fluctuate at all it could be causing the crystal to be oscillating a little differently. You could also see different frequencies depending on how you measured the crystal (did you use a frequency counter?) and other factors like temperature. The best thing to do is to see the MSP430 crystal app note and run the oscillation allowance testing described in it to find the safety factor of your crystal circuit with the correct XCAP setting.

Regards,

Katie

Regards,

Katie

Hi Katie,

we do see the above described behaviour depending on the SVS settings on both, the eval board and our target hardware. We used a frequency counter (TOE 6723 Universal Counter).

So it's strange that you cannot reproduce this, though we've seen it on different targets.

It look like there is a relation between SVS and XT1.

Regards

Thomas

Hi Thomas,

Sorry for the delay and that I wasn't able to reproduce at first. I altered my testing and I think I can see the behavior now. I am going to provide these results to some people involved with the design to see if they can provide some insight into why the SVS setting seems to be having an effect on the LFXT behavior.

Regards,

Katie

Hi Thomas,

An update: we've been investigating this in more detail, running simulations and tests. It is looking like if you disable the SVSHE after you set the XCAP settings, you'll be fine and that the issue only occurs if you clear SVSHE before setting/clearing your XCAP value.

The investigation is still ongoing, but could you try moving the line of code where you clear SVSHE to somewhere after you have set your XCAP setting to the desired level to confirm that in this case the XCAP setting is correctly taking effect?

Regards,

Katie