Surprising power reduction mods for DS3231 RTC in ZS-042 module

[Peabody]

Well it was surprising to me anyway.  I ran across a video by Ed Mallon which says the DS3231 idles at a much lower current when powered from the chip's Vbat pin instead of its Vcc pin.  There's no explanation of why that should be the case, but I've confirmed it's true.



When nothing is happening on I2C, I measure 90uA on the Vcc line at 3.3V, or 125uA at 5V.  That's with the SDA, SCL, INTSQW and 32K pins all high, so none of that current is being sunk through the pullup resistors.  But if Vcc is not powered, the coin cell battery takes over, and the current there drops to 1.25uA, with a small blip every 10 seconds, which I assume is the temperature correction thing.  The thing is - everything still works normally, including the alarm interrupt and I2C.

Mallon takes advantage of this by literally lifting the Vcc pin (pin 2), and using the so-called "charging circuit" for power, which is already connected to the Vbat pin (pin 14),  The battery is still there too, but he cuts that trace and inserts a diode from the battery to pin 14 to protect the battery from what may be 5V charging current.  I've attached the original ZS-042 circuit, and Mallon's modified version.

This is all fine, but I have a problem with the reduced battery life the diode would produce if the device is going to spend any significant time on battery power.  And his mod seems a bit fiddly to me.  But if you never switch to battery power, even when sleeping, you get very low idle current, and that current is provided by the main project battery, not the coin cell, and in that case the battery diode drop wouldn't make any difference.

I've also attached an alternate mod circuit that doesn't require any pin lifting or added diodes, just cutting traces.  The Vcc header pin on the module would be powered from a GPIO pin, which would be raised only when you need to do something with the RTC.  At all other times, including when sleeping, the GPIO would be switched to output low, or to input mode with no pullup resistors.  You would also have to disable any pullup resistors that might be enabled on the processor's I2C lines.  And of course the charging  circuit would need to be disabled, as would be needed even with no mod at all.

If the alarm function on INTSQW is going to be used, then the connection of that pin to its pullup resistor would also need to be cut.  That's because the pullup resistor is connected to Vcc, which wouldn't be pulling up if the GPIO is not high.  So instead you would enable the processor's internal pullup resistor on the interrupt line. This would require cutting the trace from the top resistor of RP1 to the via right next to it.

The alternate mod would have the I2C heavy lifting current provided by the main project battery, but at all other times the coin cell would be powering the chip.  But of course that's only at 1.25uA, so the coin cell would still last a long time. And there would be no diode drop in the battery line.

The alternate mod would be particularly appropriate if the INTSQW pin is going to somehow power up the processor when the alarm triggers - you would almost certainly have to disconnect the pullup resistor anyway, and the RTC would be on the coin cell battery anyway when the processor is powered down.

I'd be interested in any comments on this including other alternatives for low power operation with this module.

[jbb]

I’m pretty sure the Vcc consumption is higher because it runs the IO interface and level sensors / comparators for the Vbat switch. The chip designers would have prioritised Vbat consumption.

Edit: sorry, just saw your comment that the I2C interface still works off Vbat. Cool.

Have you checked how much current the other I2C chip consumes? It looks like an ERPROM and they can vary a bit (especially if it’s a generic, check the data sheet from that specific manufacturer).

[Peabody]

The EEPROM chip on my ZS-042 is marked:

ATMTC086
24C32N
SU27 D

I don't know who the manufacturer is.  Assuming it's the 2.7V version, the original Atmel datasheet has the standby current at 0.5uA at 2.7V or 2.0uA at 5.5V.  So at 3.3V it looks like it would be about 1uA.  And that roughly matches Ed Mallon's statement in the video that he sees about 3uA when the Vcc header connects to Vbat (and to the 24C32N of course).  That would be close to the sum of my 1.25uA powering the DS3231 only, plus 1uA or so for the 24C32N.

So that leaves the 10-fold difference in current still largely unexplained.  But it doesn't really matter as long as we know how it behaves.

[Doctorandus_P]

I have not watched the video, but the numbers for current consumption you wrote down mostly agree with the datasheet.

I assume the rest of the chip is powered by stealing parasitic power from I2C lines if you disconnect Vcc.

[RoadRunner]

I think Datasheet of the part document this well. Datasheet also describe what internal modules are full/partially disabled when RTC operating over Vbat pin. 

[Peabody]

I have not watched the video, but the numbers for current consumption you wrote down mostly agree with the datasheet.

I assume the rest of the chip is powered by stealing parasitic power from I2C lines if you disconnect Vcc.

I guess what I didn't appreciate before is that it never really goes into idle mode if powered by Vcc, and that everything still works if powered by Vbat.  And that just isn't what you would expect.   But yes, that's pretty much what the datasheet says.  I just wish it also explained why.

All of my tests were done with the I2C lines disconneced.  So there was nothing to steal, parasitic or otherwise.  No, it's just that it idles at 1.25uA if powered from Vbat, but idles at 100 times that if powered from Vcc.  The beginning of the video says the same thing.

[Peabody]

I think Datasheet of the part document this well. Datasheet also describe what internal modules are full/partially disabled when RTC operating over Vbat pin.

I don't see that information in the Maxim datasheet.  Moreover, it seems that everything still works when powered from Vbat.  I2C works and the alarms work, and of course timekeeping works.  In the video, Ed Mallon uses the modified version for everything, and hasn't found any function that suffers as a result.  And he has the Vcc pin grounded.

[RoadRunner]

I think Datasheet of the part document this well. Datasheet also describe what internal modules are full/partially disabled when RTC operating over Vbat pin.

I don't see that information in the Maxim datasheet.  Moreover, it seems that everything still works when powered from Vbat.  I2C works and the alarms work, and of course timekeeping works.  In the video, Ed Mallon uses the modified version for everything, and hasn't found any function that suffers as a result.  And he has the Vcc pin grounded.

I have not looked at datasheet again to pinpoint where exactly it mentions. But i remember from last time using the part is , 32Khz output is by default disabled , but can be enabled if needed. And TCXO algorithm and temprature conversion runs,  I guess runs less often.
Though you finding are aligned with my experience but still, One additional note from my side regarding RTC you are using. It appears it is one of those Chinese modules, which cost less than the IC part its self. I did used hundreds of these modules in a noncritical application. I did find some the module to be faulty and some did consume lot more power then other.

[Peabody]

This concerns the alternate circuit in my original post with repect to using the ZS-042 with Arduinos such as the Uno, Nano and Pro Mini.

I've experimented some with the Arduino Wire.h library for I2C.  It appears that Wire.h enables the internal pullup resistors on SDA and SCL when you give the Wire.begin() instruction.  If you then drop the ZS-042 module's Vcc pin to ground, you will be drawing current through those pullup resistors, through the 4.7K pullup resistors on the module, to the Vcc rail, which is now at ground.  So before bringing Vcc low, you would want to disable the internal pullup resistors to minimize current flow.  That could be done with the Wire.end() instruction, which turns off I2C and disables the resistors on the port pins.  Or you could reverse the enabling of pullup resistors immediately after Wire.begin():

Wire.begin();
digitalWrite(SDA,LOW);
digitalWrite(SCL,LOW);

Also, as stated in the original post, when using the INTSQW pin to wake up the MCU, it's necessary to disable the pullup resistor on INTSQW on the ZS-042 module if you are going to bring the module's Vcc line low while sleeping.  Otherwise, INTSQW will never go high because it has in effect a pulldown resistor to ground when Vcc is low.  Instead, you would enable the internal pullup resistor on the MCU wakeup pin.   Attached is a picture showing the trace to cut (or you can cut the resistor pin if you can get to it) to disable the INTSQW pullup resistor.

[uski]

Can you check the entire power consumption of the system ? It is possible or even likely that power for the I2C bus is taken from the clamp diodes. As a result, if you measure just the power going into Vbat, you think you have less power used, but it is possible the difference is simply taken from the I2C bus.

[Peabody]

Can you check the entire power consumption of the system ? It is possible or even likely that power for the I2C bus is taken from the clamp diodes. As a result, if you measure just the power going into Vbat, you think you have less power used, but it is possible the difference is simply taken from the I2C bus.

I'm not sure what you're asking.  My current measurements were made with nothing connected to the I2C pins, so they can't be a source of current.  However, running on Vbat, with Vcc disconnected, I did a test connecting 33K resistors from SDA and SCL to the 3.3V rail of the breadboard, trying to simulate the effect of having internal pullup resistors enabled on those lines on the processor, and that caused a significant increase in the Vbat current, not a decrease.  Apparently current was feeding back through the 33K resistors to Vcc through the module's 4.7K pullup resistors, and was causing the DS3231 to at least partially come out of the low-current Vbat mode.  So as discussed in my previous post, if you're going to bring Vcc low, you also need to disable any internal pullup resistors on the I2C lines at the processor.

Of course this also means you have to power up Vcc to communicate over I2C because Vcc has to power the pullup resistors, or at least not be pulldown resistors.

As far as I can tell, the difference in current between Vbat and Vcc is real.  What we dont know is what the DS3231 is doing when running on Vcc that it isn't doing when running on Vbat.  The only thing that comes to mind is running the comparators for Vcc, Vbat and Vpf  (power failure) which might not need to on when Vcc is at ground.  But that's just a guess.