Can I change XCAP setting while running MCU ?

Masayoshi SAKAMOTO said:

First, I use XCAP setting as 6pF,  then the clock late about 5sec/day.
So I change XCAP setting as 1pF, then the clock gains about 5sec/day.

So you say you know how to change XCAP sucessfully. Then why you ask? :)

Masayoshi SAKAMOTO said:

But Is it able to change XCAP setting while running the oscillator ?

Yes, you can do that, everything will be fine.

BTW there's other way to "trim" RTC oscillator - by adding/substracting it's counter.

Mr. Ilmars, thank you for your reply.

> So you say you know how to change XCAP sucessfully. Then why you ask? :)

My first way to change the XCAP setting is selecting  pull-down menu in Grace on CCS.
Today, I tried to change XCAP register value in my program, and changing done with no hung-up.

>Yes, you can do that, everything will be fine.

I'm afraid to changing the load capacitance while running might cause unstable oscillation.
I do not know the XCAP internal circuit mechanism to change the load capacitance.

>BTW there's other way to "trim" RTC oscillator - by adding/substracting it's counter.
 Thanks for new idea.

Regards,
Sakamoto

Masayoshi SAKAMOTO said:

I'm afraid to changing the load capacitance while running might cause unstable oscillation.

Don't be afraid. If you finish your RTC calibration project - come back and share with us

Masayoshi SAKAMOTO said:

I'm afraid to changing the load capacitance while running might cause unstable oscillation.

Indeed, this is possible. Suddenly adding capacitance may disturb oscillation. Also, adding charged capacitance back in the middle of an oscillation may also affect it. So you shouldn't switch too often.

I think, nobody has tried this before, so you a re a pioneer in this field. Please share your results.

Anyway, it may be better to manipulate the digital usage of the crystal than the crystal speed itself. The RTC modules offer calibration tweaks in hardware. (+- 2ppm steps) by simply omitting one clock pulse every now and then, or skipping counts.

If the device is constantly running, and using a software RTC that counts timer overflows, you can manipulate the count at which the timer overflows, s a second is 32769 or 32767 oscillations instead of 32768.

Of course, this is all being very specific to your 1 device, on your 1 board, at some known temperature.

Once you change any one of these, then the amount of drift will vary, so it's not a solution for a production product.

The only way to have repeatable, accurate timing is to use an accurate source to begin with.

In your situation, you could also determine what the correct load capacitance should be, and add that to the circuit board and turn off the XCAP function altogether.

Jens-Michael Gross said:

I think, nobody has tried this before, so you a re a pioneer in this field. Please share your results.

I did. When tested XCAP "precision" for multiple chips to find resulting oscillator freq for given "fork" + XCAP combination and decide - do I need to use external caps or internal is good enough, do I need trimming or not. During my "XCAP switching" tests I did not see any single oscillator failure.

Disclaimer: application is not the same and I did not test XCAP switching stability actually, just resulting frequency. So your mileage can vary. Indeed I am interested in your results too because "change XCAP for yyy seconds per day" could be simple and elegant way of trimming RTC.

Brian Boorman said:

Of course, this is all being very specific to your 1 device, on your 1 board, at some known temperature.

Sure! Actually this (and not only) is why we are having this conversation - about RTC trimming/calibration.

Fork oscillator frequency is temperature-dependant so if you temperature-compensate crystal then you can compensate XCAP temp drift too. You just need XCAP temperature curves which most probably will be the same for all the chips manufactured using same process.

Brian Boorman said:

The only way to have repeatable, accurate timing is to use an accurate source to begin with.

As I already mentioned - crystal itself is not that accurate source. Main question is - what kind of precision you are looking for.

Ilmars said:

During my "XCAP switching" tests I did not see any single oscillator failure.

'failure' means 'no oscillation detected for a long period of time'. But it still may cause the crystal to hiccup and miss a few oscillations, making the cure worse than the disease. (fault detection range is from 3 to 3000 missing oscillations - deadly for any RTC precision)

Jens-Michael Gross said:

But it still may cause the crystal to hiccup

Good point. XCAP switching moment could cause rogue clock pulses. Quick way to test this would be to switch XCAP fast - like 1000 times/sec and see ACLK clock period on scope with infinite persistence on.

Following code, not a single glitch for > 165k cycles (of scope capture):

int main( void )
{
  WDTCTL = WDTPW + WDTHOLD;    //Stop watchdog timer
  BCSCTL2 = SELM_3;            // MCLK = LFXT/1
  P1DIR |= BIT0;               // P1.0 = ACLK
  P1SEL |= BIT0;
  
  while (1) {
    BCSCTL3 = XCAP_2;          // 10 pF
    BCSCTL3 = XCAP_3;          // 12.5 pF
  }
}

Measurements

, Frequency(1 ) , + width(1 )
Current, 32.812080 kHz, 13.793287 µs
Mean, 32.768185 kHz, 13.7861202 µs
Min, 32.332261 kHz, 13.326144 µs
Max, 32.943165 kHz, 14.208704 µs
Range, 610.903941 Hz, 882.560 ns
Std Dev, 121.849573 Hz, 161.81308 ns
# of Meas, 181.96 k , 181.96 k

We have a mix of (F5528-based) boards - several with a crystal that is 8.5 pF, and several with a crystal at 12 pF. We do not know the board until the code is running, and a value is updated representing serial number.

Based on the previous posts, I plan to initialize the code with the 12 pF setting (XCAP3). Then after running, if the serial number is of the type that needs the 8.5 pF setting (XCAP2), I will then switch the XCAP setting from XCAP3 to XCAP2.

It appears that this is a workable solution - does anyone see any problems with doing it this way?

Checking the serial number first and then setting the XCAP value shouldn’t be a problem. Except if you already need the crystal running to retrieve the serial number. :)

Well, you could try one setting first and when the crystal doesn’t come up in time, try the other. Takes worst case a bit longer, but doesn’t need to know the relation between serial number and required XCAP. However, if both settings work, you might run the crystal with the wrong one and get a detuned frequency. 
You could try an even lower XCAP where it is sure that the 12pF won’t run but the 8.5pF will, then wait whether it runs and decide to go for 8.5 or 12pF then.

Jens-Michael:

Thank you - the boards do not have a problem with either setting. However, the accuracy of the clock is what is the issue, especially when running the RTC. Beyond getting very close to the desired frequency of 32.7680000... KHz, the RTC will probably require a value in the calibration register to further fine-tune the frequency for RTC.

If the crystal is running and you need to calibrate it, you may feed a precision 1s clock to a port pin and compare the uncalibrated crystal to this known tick. Take the difference and calculate the required adjustment.