DS3231SN RTC forced CONVersion process

[Peabody]

I'm working on a project that uses a GPS PPS signal to adjust the RTC's Aging register to the best value, at least at the current temperature, and thus bring accuracy down to the 0.1ppm area.  The process requires adjusting the Aging register value from time to time.  The datasheet says that I should do a forced temperature conversion so the change will take effect immediately.  But it also says I should do that only when the BSY bit shows the RTC is not already doing its own conversion.

But the only way to determine thst is to read the Status register to see if BSY is set.  And it seems possible that the RTC could initiate its own conversion immediately after reading Status,  so by the time I write to the Control register to initiate the conversion, I would be walking over an onging conversion.

Does anybody know what actually happens if you set CONV when BSY is already set?  The datasheet doesn't say.  Does it just start the conversion over again, or abort it, or mess it up. or what?

[tooki]

The datasheet says this:

Temperature Conversion Time t_CONV 125ms typ, 200ms max

Bit 5: Convert Temperature (CONV). Setting this bit to 1 forces the temperature sensor to convert the temperature into digital code and execute the TCXO algorithm to update the capacitance array to the oscillator. This can only happen when a conversion is not already in progress. The user should check the status bit BSY before forcing the controller to start a new TCXO execution. A user-initiated temperature conversion does not affect the internal 64-second update cycle.
A user-initiated temperature conversion does not affect the BSY bit for approximately 2ms. The CONV bit remains at a 1 from the time it is written until the conversion is finished, at which time both CONV and BSY go to 0. The CONV bit should be used when monitoring the status of a user-initiated conversion.

Bit 2: Busy (BSY). This bit indicates the device is busy executing TCXO functions. It goes to logic 1 when the conversion signal to the temperature sensor is asserted and then is cleared when the device is in the 1-minute idle state.

Temperature Registers (11h–12h)
Temperature is represented as a 10-bit code with a resolution of 0.25°C and is accessible at location 11h and 12h. The temperature is encoded in two’s complement format. The upper 8 bits, the integer portion, are at loca- tion 11h and the lower 2 bits, the fractional portion, are in the upper nibble at location 12h. For example, 00011001 01b = +25.25°C. Upon power reset, the registers are set to a default temperature of 0°C and the controller starts a temperature conversion. The temperature is read on initial application of VCC or I2C access on VBAT and once every 64 seconds afterwards. The temperature registers are updated after each user-initiated conversion and on every 64-second conversion. The temperature registers are read-only.

If it really mattered, you could poll the BSY bit furiously until you find it is H, then wait a few seconds, since you know it won’t be busy for another 64 seconds. But it also sounds like it’s deterministic enough that you could know when it started counting, and then know exactly when it’s going to do it again.

[Peabody]

Yes, I read all of that in the datasheeet several times.  It still doesn't say what happens if you intiate a conversion when BSY is high. I don't think you can prevent that by checking BSY.  You have two I2C conversations between checking BSY and intiating a conversion - one to transmit the Status byte value to the MCU, and another to transmit the new Control value to the RTC.  During that time BSY can go high.  Well, maybe the automatic conversion process always takes place at the beginning of a second.  Then the 1Hz square wave could indicate whether it's safe to convert - it goes low at the beginning of each second.  I found an app note that says the conversion process takes 200ms.  I'd kinda like to avoid having to track it over 64 seconds if I can avoid it.

[tooki]

I literally quoted the conversion time, it’s right in the datasheet.

Yes, it would be nice if they said what happens if you ignore the rule, and better guidance on how to avoid that.

But my point is, this: it looks like the conversion wait is deterministic, so if you keep track of the elapsed time, then you know whether a conversion is imminent. Basically, the 64s counter starts when the thing is first powered up. (i.e. when it thinks the time is 00:00:00.)

Suppose you power it up (so it’s “blank”). Then right before you write the current time (let’s say 14:00:00) to it, you read out the saved time and it says 00:00:23 (so 23s have elapsed since power up.) You now know that the next automatic conversion will be at 14:00:41. (14:00:00 + 64s - 23s). And then again at 14:01:45, 14:02:49, and so on. That gives you a huge window of time.

If you don’t know when it powered up, then you poll the heck out of the BSY until it is high, and you’ve got your reference datum. You don’t need to do that again, just once.

In all cases, the 64s elapsed time should be checked by reading it from the RTC, not from your MCU’s system clock that might drift.


As for when the conversion takes place during the second: well wouldn’t that be pretty easy to test? Power it up, don’t set the time, and at 00:01:03, poll the time and BSY registers furiously, and correlate the time changeover to the BSY state.

[Peabody]

I wrote an Arduino (328P) sketch that puts the RTC in square wave output mode, and reads the BSY bit repeatedly and has D8 follow the state of that bit.  The square wave goes low at the beginning of a second.  So a two-channel scope shows the relationship of D8 to the square wave, and will show where in the second the conversion occurs.  Guess what I found.  My RTC, clearly marked DS3231SN, is in fact a DS3231M, which does its conversion every second.  So there's no need for me to trigger a conversion for this chip at all.  If I ever get a real SN part, I can run the code on it and see what happens.  Or if someone has one, they're welcome to run it too.  By the way, the other way you know you have an M is that it only does a 1Hz square wave.  You can do whatever you want with the RS1 and RS2 bits, but you still only get 1Hz on an M.

Code: [Select]

/*
This sketch sets D8 high while the DS3231 BSY bit is high. It can
be used to detect whether a chip marked DS3231SN is in fact a
DS3231M.  The SN will take D8 high once every 64 seconds, whereas
the M will take it high once per second if powered by Vcc, or once
every 10 seconds if running on the coin cell. 

In addition, there is an option to attempt to increase the square wave
output from 1Hz to 1KHz by adjusting the RS1 bit.  The SN will make
that change, but the M will stay at 1Hz.

At 1Hz, a two-channel scope can be used to see the relationship of the
BSY period to the beginning of a second (the square wave goes low at the
beginning of each second).
*/

#include <Wire.h>
byte BSY;
byte Control, Status;  // RTC registers

void setup() {
  pinMode(8,OUTPUT);
  Wire.begin();
  delay(2000);
  Wire.beginTransmission(0x68);           // read Control and Status registers
  Wire.write(0x0E);                       //   and clear alarm enables and flags
  Wire.endTransmission();
  Wire.requestFrom(0x68, 2);

     // Clear /EOSC, RS2, RS1, A2E, A1E. Set BBSQW, INTCN. (SQW freq = 1Hz)
  Control = (Wire.read() & 0b01100100) | 0b01000100;

     // Clear /EOSC, RS2, A2E, A1E. Set BBSQW, RS1, INTCN. (SQW freq = 1KHz)
//  Control = (Wire.read() & 0b01101100) | 0b01001100;

     // Clear OSF, EN32k, A2F, A1F
  Status = Wire.read() & 0b01110100;

  updateReg(0x0E);                        // update Control
  updateReg(0x0F);                        // update Status

  Control &= 0b11111011;                  // enable squarewave 1Hz or 1KHz
  updateReg(0x0E);

}

void loop() {
  Wire.beginTransmission(0x68);
  Wire.write(0x0F);
  Wire.endTransmission();
  Wire.requestFrom(0x68, 1);
  BSY = Wire.read() & 4;
  if (BSY) digitalWrite (8,HIGH);
  else digitalWrite (8,LOW);
}

void updateReg(byte addr) {
  Wire.beginTransmission(0x68);
  Wire.write(addr);
  if(addr == 0x0E) Wire.write(Control);        // enable alarm1
  else if(addr == 0x0F) Wire.write(Status);    // clear alarm flags
  Wire.endTransmission();
}

[iMo]

Based on the datasheets (DS3231/DS3231M) there is not such an output like "1kHz".
With both there is a 32kHz output based on "EN32kHz" bit setting.

[tooki]

Based on the datasheets (DS3231/DS3231M) there is not such an output like "1kHz".
With both there is a 32kHz output based on "EN32kHz" bit setting.

You are confusing the 32KHz output with the square wave output, which are separate.

Both SN and M have the 32KHz output. The M’s square wave output supports 1Hz only. The SN’s square wave output supports 1Hz, 1024Hz, 4096Hz, and 8192Hz. (See page 13 of the SN’s datasheet.)

[iMo]

Thus - to be precise - the outputs could be 32768Hz, 8192Hz, 4096Hz, 1024Hz, 1Hz based on the type..
No such outputs like 32kHz and 1kHz.. 

[tooki]

That's neither here nor there. The point is that if the square wave output pin refuses to output anything other than 1Hz, then it's not an SN, but an M.

[Peabody]

My other "SN" part turns out to be an SN part.   Well, it may not be a Maxim part,  but it behaves like an SN.  Which is surprising because it's one I just bought on Ebay for $3.39 plus shipping.  I would have thought it would be the most likely to be fake.

https://www.ebay.com/itm/401482226870?var=671154997502

It's the little round module, with no "charging" circuit, no LED, and no pullup on INT/SQW.  But the coin cell holder is for a CR1220.   

Anyway, the BSY bit does indeed go high every 64 seconds.  And it does that when the square wave goes high, which is right in the middle of the current second.  So if you do a forced conversion when the square wave goes low, there should be no need to check the BSY status.

[tooki]

Anyway, the BSY bit does indeed go high every 64 seconds.  And it does that when the square wave goes high, which is right in the middle of the current second.  So if you do a forced conversion when the square wave goes low, there should be no need to check the BSY status.

Good to know! But how are you certain the square wave goes high in the middle of the second? That seems like an odd time to do it. There's no timing diagram for the square wave output, so I assume you did this experimentally?


All the same, if you just keep track of when powerup was, as I described, then you don't have to mess around with the square wave, either, since you might not be using it. You didn't really respond to any of that comment of mine (the one just before your Arduino code), though I put a bit of effort/thought into it.

[Peabody]

I determined it using a two-channel scope.  I continuously sampled the Control register to determine the state of BSY, and made the output on D8 the same as the state of BSY.  Channel 1 was on D8.  Then channel 2 is just the square wave output.  I had previously determined that for both the SN and the M the square wave goes low at the beginning of a second.  I power cycled a few times, and it was always the same.  (This SN didn't have a coin cell installed.)

I'm sorry I didn't comment on your solution to keep track of seconds since powerup.  Of course you are correct that it does a conversion every 64 seconds, so if you keep track of that, you would have a wide window when a manual conversion would work.  But what I'm doing now is finding the number of clock cycles between the square wave going low and the PPS output of a GPS module going high, and doing that over an extended time, with the millis interrupt turned off.  I don't want I2C traffic to interfere with the measurements, and I have the 1Hz square wave triggering an interrupt anyway, so I just think for this case it's better to work with the part of the second when a conversion will work.

It still would be nice to know whether the world comes to an end if a manual conversion walks over a scheduled one, but we would probably have to find the guy who designed the part to get that answer.