What is coarse trim mode on the MCP7940 - page 31

[alank2]

http://ww1.microchip.com/downloads/en/DeviceDoc/20005010H.pdf

It describes this mode on page 31 - but I am at a loss for how it is of any good.  Normal trimming allows for an adjustment of +/- 129 ppm.  This coarse trim mode seems to apply the trim much more often than the once per minute adjustment - it instead does the adjustment 128 times per second instead.  128*60 is 7680 times the effect out of coarse mode.  I get that one can watch the signal change immediately when you change the trim value, but with the adjustment being so coarse, how could it possibly help you to know what the proper trim value is.  Maybe I am missing how this works.

[Ian.M]

Coarse trim mode is useless to the end user, but would be critically important for factory test.  Its capable of a factor of two speed-up or of slowing timekeeping virtually to a standstill, so enables the trim functionality to be checked in far less time on the test jig.

[alank2]

So I think I found a use for the coarse trim mode - it turns out that trying to set the time on this RTC is practically impossible to do accurately unless I am missing something.  You are supposed to stop the oscillator, set the time, then restart the oscillator, but the oscillator may take anywhere from 0.2-1+ seconds to start up so trying to get it to match time to the second is not going to happen.  I ended up usin the coarse trim mode to adjust the running clock 100mS at a time by setting it to either twice the normal clock or half the normal clock, then waiting 200 milliseconds, then turning it back off.  You can basically push a running clock up or down with this method.

[Ian.M]

Neat, and good lateral thinking on your part.  Can you post that part of your code for the community benefit?  It would also be good to cross-post it to the appropriate subforum over at Microchip.com

[mck1117]

Yep, that's for time synchronization without a discontinuity of resetting the clock.  Incidentally, that's how all real computers do it too: instead of instantly setting the clock to the correct time, they adjust the clock's rate by up to maybe 10%, controlled with a PI or P controller.  Think about clock synchronization like a PLL: the phase of the reference clock and the controlled clock are compared, and the speed of the controlled clock adjusted to match.  If there's a big jump in time, you might need to run really fast or slow, hence the need for the coarse adjust mode.

[alank2]

Code: [Select]

if (c1=='4')
                                     {
                                       s2[0]=0x44;
                                       s2[1]=0x7f;
                                       if (!i2c_Command(0xde, 0, 0x7, 0, 2, s2))
                                         uart_puts("FAIL\r\n");

                                       Delay_ms(200);

                                       s2[0]=0x43;
                                       s2[1]=0;
                                       if (!i2c_Command(0xde, 0, 0x7, 0, 2, s2))
                                         uart_puts("FAIL\r\n");
                                     }
                                   else
                                   if (c1=='5')
                                     {
                                       s2[0]=0x44;
                                       s2[1]=0xc0;
                                       if (!i2c_Command(0xde, 0, 0x7, 0, 2, s2))
                                         uart_puts("FAIL\r\n");

                                       Delay_ms(200);

                                       s2[0]=0x43;
                                       s2[1]=0;
                                       if (!i2c_Command(0xde, 0, 0x7, 0, 2, s2))
                                         uart_puts("FAIL\r\n");

                                     }
The thought here is that 200ms at a half or double speed clock will affect the clock by 100ms.  I use this inside a loop constantly reading the time and outputting it when it changes (when the second turns over).  I can then compare that to time.gov and push it ahead of behind.

Something I don't fully understand is the way the coarse trim operates though.  The 0x7f above in coarse mode should subtract 254 clocks 128 times per second - which should give 256 clocks instead of 32768 clocks - I thought this would bring the clock to a near stand still, but it changes the 64 Hz signal to 32.12 Hz instead.

The other that I settled on using was 0xc0, which is 0x40 with the 0x80 bit set.  So this would be 0x40 * 2 = 128 clocks to add 128 times a second.  32768 + 16384 would be 49152 clocks per second, or a 50% speedup, but yet it is a 100% speed up when I measure it at 128 Hz.

Maybe I am not following the coarse trim part of the data sheet.