DS3231SN RTC forced CONVersion process - Page 1
Forum section: electronics / projects

author: Peabody
author_rank: Super Contributor
timestamp: April 28, 2023, 02:53:00 am
content: 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?

author: tooki
author_rank: Super Contributor
timestamp: April 28, 2023, 12:35:40 pm
content: The datasheet says this:QuoteQuoteQuoteQuoteIf 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.

author: Peabody
author_rank: Super Contributor
timestamp: April 28, 2023, 01:42:00 pm
content: 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.

author: tooki
author_rank: Super Contributor
timestamp: April 28, 2023, 02:20:36 pm
content: 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.

author: Peabody
author_rank: Super Contributor
timestamp: April 28, 2023, 09:53:57 pm
content: 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:/*This sketch sets D8 high while the DS3231 BSY bit is high. It canbe used to detect whether a chip marked DS3231SN is in fact aDS3231M. The SN will take D8 high once every 64 seconds, whereasthe M will take it high once per second if powered by Vcc, or onceevery 10 seconds if running on the coin cell.In addition, there is an option to attempt to increase the square waveoutput from 1Hz to 1KHz by adjusting the RS1 bit. The SN will makethat change, but the M will stay at 1Hz.At 1Hz, a two-channel scope can be used to see the relationship of theBSY period to the beginning of a second (the square wave goes low at thebeginning of each second).*/#include <Wire.h>byte BSY;byte Control, Status; // RTC registersvoid setup() {pinMode(8,OUTPUT);Wire.begin();delay(2000);Wire.beginTransmission(0x68); // read Control and Status registersWire.write(0x0E); // and clear alarm enables and flagsWire.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, A1FStatus = Wire.read() & 0b01110100;updateReg(0x0E); // update ControlupdateReg(0x0F); // update StatusControl &= 0b11111011; // enable squarewave 1Hz or 1KHzupdateReg(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 alarm1else if(addr == 0x0F) Wire.write(Status); // clear alarm flagsWire.endTransmission();}

author: iMo
author_rank: Super Contributor
timestamp: April 29, 2023, 08:14:22 am
content: 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.

author: tooki
author_rank: Super Contributor
timestamp: April 29, 2023, 10:53:25 am
content: Quote from: iMo on April 29, 2023, 08:14:22 amYou 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.)

author: iMo
author_rank: Super Contributor
timestamp: April 29, 2023, 11:43:07 am
content: Thus - to be precise - the outputs could be 32768Hz, 8192Hz, 4096Hz, 1024Hz, 1Hz based on the type..No such outputs like 32kHz and 1kHz..

author: tooki
author_rank: Super Contributor
timestamp: April 29, 2023, 01:14:37 pm
content: 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.

author: Peabody
author_rank: Super Contributor
timestamp: April 29, 2023, 02:21:19 pm
content: 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=671154997502It'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.

author: tooki
author_rank: Super Contributor
timestamp: April 29, 2023, 04:46:22 pm
content: Quote from: Peabody on April 29, 2023, 02:21:19 pmGood 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.

author: Peabody
author_rank: Super Contributor
timestamp: April 29, 2023, 09:24:06 pm
content: 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.