What is coarse trim mode on the MCP7940 - page 31 - Page 1
Forum section: electronics / projects

author: alank2
author_rank: Super Contributor
timestamp: June 24, 2020, 02:05:25 am
content: http://ww1.microchip.com/downloads/en/DeviceDoc/20005010H.pdfIt 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.

author: Ian.M
author_rank: Super Contributor
timestamp: June 24, 2020, 07:33:30 am
content: 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.

author: alank2
author_rank: Super Contributor
timestamp: July 18, 2020, 06:14:39 pm
content: 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.

author: Ian.M
author_rank: Super Contributor
timestamp: July 18, 2020, 06:29:44 pm
content: 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

author: mck1117
author_rank: Contributor
timestamp: July 18, 2020, 07:43:52 pm
content: 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.

author: alank2
author_rank: Super Contributor
timestamp: July 19, 2020, 12:52:52 am
content: Code:if (c1=='4'){s2=0x44;s2=0x7f;if (!i2c_Command(0xde, 0, 0x7, 0, 2, s2))uart_puts("FAIL\r\n");Delay_ms(200);s2=0x43;s2=0;if (!i2c_Command(0xde, 0, 0x7, 0, 2, s2))uart_puts("FAIL\r\n");}elseif (c1=='5'){s2=0x44;s2=0xc0;if (!i2c_Command(0xde, 0, 0x7, 0, 2, s2))uart_puts("FAIL\r\n");Delay_ms(200);s2=0x43;s2=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.

author: kjw
author_rank: Newbie
timestamp: March 19, 2025, 03:08:38 pm
content: I found this thread via an Internet search and would like to thank alank2 for the coarse skew idea to correct the RTC time to get sub-second accuracy. I've beenplaying with clocks recentlyand would like to add a second one and sync off the first. It's strangely easy to notice when a pair of clocks with a second hand are half a second out. Eventually I would have played with the skew but this saved me a lot of time.For the max 127 skew the MCP7940N (datasheet page 26) corrects at 64Hz not 128Hz which explains the maths puzzle below.QuoteThe datasheet recommends a rather elaborate process for setting the time involving ceasing the oscillations. I'm not sure if anyone follows this?QuoteI have one remaining mystery for rhe MCP7940N, I saw a POR trim value of 127 rather than than 0. I now set it explicitly.