Reducing MSP430 Crystal startup time through XCAP

paddu1 said:

So we are thinking to start-up the crystal after power up with default XCAP(1pF)

Not a good idea. YOu're right, a lower load leads to a faster start, because it is reducing the load times and tehrefore the oscillation frequency increases. However, crystal oscillation is a mechanical oszillation, and low-power mechanical operations are reather slow.
With decreasing the load capacitance, you also lower the energy that flows through the crystal, resulting in a higher frequency but (much) lower intensity. It is well possible that the crystal will oscillate, with, say, 40 or even 50kHz, but the amplitude is so low that the MSP won't be able to handle it. So the crystal won't come up at all. It highly depends on the individual device.
You may start with 1pF and after 1ms switch up (so worst case you wasted this 1ms). But don't wait for the crystal to run before you set the final load. It may be an eternal wait.
Also, it may well be that when you add the additional capacitance at the wrong moment, it might even stop an already ongoing oscillation. At least that's a possibility that has to be researched.

If you want to run MSP430G2231 with a 32kHz crystal and make sure that it starts quickly then you have more problems than what you've mentioned. Read the errata of this chip:

http://www.ti.com/lit/er/slaz061b/slaz061b.pdf

page 5: XOSC5 and XOSC8

Your options are either to go into LPM when power switches off (but that requires some auxiliary power although a miniscule one)
OR
use DCO clock if strict real time precision is not required
OR
use a different MSP430 chip that doesn't have these problems.

Paddu,

I know your question was regarding Xtals, so first I will say that I agree with Jens Michael. But if you just need to reduce startup time there are other ways to help facilitate a faster startup.

One way is to use the __no_init function for declared variables, particularly big ones like large arrays. When the part starts up and these variables are initialized, the DCO is not yet configured. During init the clock is running significantly slower, so these variable initializations can potentially take a long time.

Using __no_init can help cut down on this startup time, and then you can perform your critical initial tasks after startup, and then initialize in the application code. I am not sure how much this might help you without knowing anything about your application or variables, but it is a thought that may help.

Thank you all for the support.

Hello Mike,
Could you please let me know where exactly can we use the __no_init function.

As an alternative solution we are planning to use DCO as the clock
for a little while until the crystal starts up properly,
but as the timer needs precise clock(±1%), we are worried about the accuracy (tolerance over
temperature/voltage of ±3%).

Regards.
Paddu