Go Down

Topic: ZS-042 DS3231 RTC module (Read 84301 times) previous topic - next topic


May 06, 2017, 03:48 pm Last Edit: May 06, 2017, 03:55 pm by mangelozzi
Hi Guys,

The battery is supposed to be a back up for when power is removed.
The problem with most of the suggestions above, is then you are only running on the battery the whole time, which will last for less than 8 years.

Ideally you want to run the circuit off the external Vcc if it is present, or run the circuit off the battery if the external voltage goes away.

What we do not want is the battery being charged by Vcc.
We also do not want the battery supplying current to the external circuit when Vcc goes away, because this will discharge it quickly.

All these condition can be met by adding another diode (Dadd) as shown by the attached image.


So if that battery is a rechargeable, how will it be charged?

The whole point of the original circuit is to keep a rechargeable battery charged. And if you don't want that to happen, removing the original diode is a lot easier than adding something.

Also, your circuit probably keeps the full circuit powered (in this case the rtc and the eeprom) which will reduce the 'battery life'.
If you understand an example, use it.
If you don't understand an example, don't use it.

Electronics engineer by trade, software engineer by profession. Trying to get back into electronics after 15 years absence.


Jun 17, 2017, 04:06 am Last Edit: Jun 17, 2017, 03:22 pm by cjcj
I realize this post is a little old, but just a quick question.  In post #2 "dunio" suggested to use a 5.5V 0.47F supercapacitor.

Maybe just adding a supercap in place of the CR2032 is the best long term simplest solution.  I can see these on ebay selling 5PCS for US $1.50.

Is this a good solution and if so, any idea how long the cap would last when the 5V supply to the module is disconnected?



After reading the whole post on the matter, I decided to play it safe disabling the charging circuit by removing the 200ohms resistor, but when I put the RTC back on the system, it did not work, the LED its on indicating power but the RTC does not communicate with the arduino.

Everything works correctly replacing the RTC for a non-modified one.

I then soldered the resistor back on and the system works again.

Does anyone have the RTC working without the 200ohms?

Any other ideas?


I removed the diode; the effect is the same.
If you understand an example, use it.
If you don't understand an example, don't use it.

Electronics engineer by trade, software engineer by profession. Trying to get back into electronics after 15 years absence.


I've been working with these ZS modules for quite a while, and have compiled an extensive post about them:


Near the end of the post you can find photos of boards which combine pin-powering and the diode mod described by mangelozzi.

There are also links to heypete's de-capping & drift testing on these RTC.


After reading the four pages of this, it seems there are unanswered questions.  There are four real areas of concern: use and features of the DS3231M; use and features of the 24C32; the appropriate use of the on-board battery, and how the ZS-042 board connects all these things together.

First, if you want to use the board to its fullest capabilities, you need to read the data sheet for each of the components, including the battery.

I'll let you read those yourselves, but I'll point out a few features that may peak your interest.

Lets start at the DS3231M:  It does some neat stuff, when configured appropriately. It has much of the same functionality is your simple clock/alarm on your bedside table.

 -  Reports time on 12/24 hour format, includes seconds, minutes, hours, day, date, month, and year, with leap year adjustments.  Basically, a perpetual calendar until the year 2100.

 -  It keeps time accurate to only gain or lose 0.432 seconds/day.

 -  It can keep track of two alarms, which will trigger the interrupt pin (SQW), when configured appropriately.

 -  When not wanting to use interrupts, the SQW pin can output a 1 Hz square wave.  This could certainly be used as an edge-based interrupt back to your controller, if the calendar and absolute time mean less to you than an relative time signal.  If I did the math right (+/- 5 ppm), its the same accuracy, +/- 0.432 seconds per day.

 - When the EN32KHZ bit is set in the status register, the 32K pin on the header pins (J1/CON6 from the schematic attached to post #1) has a 32.768 MHz square wave output.  This can be interesting to use as a CLK source for other logic, or as in input to a counter/divider to get a timebase of your liking.  This output works when powered either by the Battery or by VCC, so be careful when using it, as it could reduce your battery life.  This output frequency has a +/- 2.5% accuracy.

-  The RST is not brought out to a pad or pin on the board, but can be used as a software-controlled, debounced reset switch, if your were to bodge-wire this out from the IC.  Refer to the datasheet for implementation and specifics.

 -  Internal to the DS3231M itself, there is no "reverse-charging" performed on the VBAT line.  This allows them to maintain their UL recognition.  This way, the DS3231 can be used with any type of VBAT source between 2.3v and 5.5v.  Unfortunately, as described by the many other posts, a "charging" circuit was included on the ZS-042 board.  More on that in a bit.

 -  There are a lot of options for powering the DS3231M, though the ZS-042 has been wired up to one options: dual supply.  This means that the DS3231M's power module manages the powering of operations based on the voltage levels of VCC and VBAT.  There is an internal voltage within the DS3231M of about 2.575 volts.  When  VCC < 2.575 but VCC > VBAT, the device is powered by VCC.  When VCC < 2.575 and VCC < VBAT, then the device is powered by VBAT.  You can turn off functions like external waveforms and, if timekeeping is not important, even the internal oscillator, to conserve battery life.

 -  VBAT attachment - memory within the DS3231M is susceptible to corruption if the battery voltage becomes unstable.  This typically happens when removing or inserting the battery.  The datasheet states to either change the battery when VCC is providing the power, or to use a 0.1nf-1nf capacitor on the VBAT line, to keep switch-bounce-type noise from happening when changing the battery.

 -  One the first application of power, either VCC or VBAT, when a valid I2C address is written to the DS3231M, the time and date registers are reset to 01/01/0001 00:00:00.

 -  I2C Interface -  Based on the Data Sheet so far, it seems that the I2C address for the DS3231M is configurable over the I2C interface.  That sounds a little chicken-and-egg'ish to me.  Upon further review, the DS3231M is hardcoded to I2C address D0h (D1h for reading).

 -  The DS3231M maintains two registers with time information: an unaddressed time register, and the timekeeping registers from address 00h - 06h.  On an I2C Start command, or an address wraparound to 00h, the current time is written to the addressable time registers.  This keeps the time information from changing during the read operation.  Alarm information is kept in registers 07h-0Ah and 0Bh-0Dh for Alarm1 and Alarm2 respectively.  The Control and Status registers for configuring the operations of the DS3231M are held at 0Fh and 10h, respectively.

 -  Alarms are set by writing appropriate time values into the alarm registers.  The alarm mask bits control the repeating nature of the alarm (every second, when seconds match, when minutes and seconds match, etc, up to day or date, hour, minute, seconds match).  If the INTCN control register is set appropriately, then the SQW pin will act as a trigger for a hardware interrupt to your implemented microcontroller of choice.  Note: the SQW pin must either be set to 1Hz square wave output, or alarm interrupt mode.  I guess you could switch it back and forth in software, but the rest of your hardware wouldn't know if you were 'alarming' or 1Hz clocking without other logic or code.

 -  Control Registers:
   -  !EOSC - Enables oscillator when set to 0.  When set to one, the oscillator will stop when power transitions to the battery.  It saves the battery, but you WILL lose time, and time registers will not be updated.  I'd only use this if saving the VBAT power was more important than keeping time.

   -  BBSQW - If you have selected to output a 1Hz square wave on the SQW pin rather than using it as an alarm interrupt, this bit controls whether the square wave will be generated when power transitions to the VBAT.  This will depend what is more important to you in your design, battery power conservation or the 1Hz signal.

   -  CONV - this bit requests a user initiated temperature conversion to insure timekeeping is accurate.  It happens once a second when powered by VCC, and will not happen more frequently than that, but happens only once every 10 seconds when powered by VBAT, or more frequently when the user sets this bit.

   -  INTCN - clear this bit to get a the 1Hz output on the SQW pin.  Set this bit to get alarm interrupts presented to the SQW pin.  Note: the alarm registers can be polled regularly to see if the alarms have triggered, so you don't HAVE to use the hardware interrupt if you don't want to.

  - A2IE/A1IE - these bits enable or disable the alarm interrupts, but only are in effect when INTCN is set for Alarm interrupts.

 - Status Registers -
   -  OSF - status on whether the oscillator was stopped at some time.  Its set to 1 when the oscillator stops, so you'll have to initialize it when the date is known to be accurate, like after setting it.

   -  EN32KHz - Enables or disables the 32KHz signal on the 32K pin.  If set, it would only be present of the oscillator is running.

   -  BSY - temperature conversion and time register copy is currently being performed.  Use as you will, but mostly in internal function.  Possibly use in conjunction with the CONV request.

   -  A2F/A1F - alarm flags show if the alarm registers have matched the time registers. These flags can be polled as an alternative to the interrupt function of the SQW pin.  You have to initialize and reset these bits in order to monitor the next events.

   -  An aging offset register can be used to add a user-defined adjustment to the time base.

   -  Temperature registers can be read, and have a 0.25C resolution, so you can actually use this to get some temperature information.. maybe ambient temperature of the area around your circuit can be implicitly guessed, if you have a good idea about the power dissipation of your board, air flow, etc.

 - Outputs:  All outputs of the DS3231M are Open Drain FETs, but be aware that the ZS-042 implements 4.7k pullup resistors on everything.  This includes the I2C bus and 32K and SQW lines.  If you were very power-conscience, you could probably drop the current draw of the I/O lines by half by using 10K resistors instead.  Be aware that the I/O lines are only documented to sink 5-10 mA, and 1mA is already being consumed by the pullup resistor current.

I think that's about it from the DS3231M perspective.
This is the first half of the post.


This is the second half of the post.

The 24C32 Serial EEPROM is a separate unit placed on the ZS-042 board.  The DS3231M has no reference or use of it directly.  It is connected to the same I2C bus, so the user can utilize it in any manner, related to the RTC or not.  Its arranged as 4096 8-bit memory, randomly or sequentially accessed.  It uses a paging strategy where it accepts an initial address and does an internal increment for subsequent access, allowing serial reads or writes without ending the I2C communications session.  Accessing the total address space of 4k requires 12 address lines.  For multi-byte and page read/write operations, the 7 most significant bits are the page address, and the 5 least significant bits are incremented internally, such that up to 32 bytes can be read sequentially.  Be aware that the auto-increment will roll over to the base address of you continue sequential operations.

Other than these points, the operations should be straight forward, and described well in the serial eeprom library used for your code.

The I2C address for the 24C32 is A0h for writing (A1h for reading) by default, though you can adjust the lower three bits (not including the read/write bit) to address up to 8 of these on the same I2C bus.

Be aware, that although the DS3231M RTC talks I2C af 400kHz (Fast mode) and is backward compatible to standard mode, the 24C32 Serial EEPROM is only supported in Fast mode when operating at 5v.

So.. The last and most discussed portion of the board is the Lithium (non rechargable) or LiPo (rechargable) battery.

First, remember that the DS3231 RTC and 24C32 EEPROM ICs do nothing to manage the charging of the battery.  The manufacturer included a rudimentary and potentially dangerous charging circuit that may or may not work, based upon the circumstances.

Lets look at each of these scenarios, using the worst case possibilities:

5v - CR2032 :
 -  The maximum operating voltage of the ZS-042 is 5.5v, so lets use that.
 -  The CR2032 new, from a HongKong datasheet, has a maximum voltage of 3.4v.
 -  The end of life of the CR2032, where the internal resistance begins to elbow skyward, is 2.0 v.
 -  The 5.5v VCC to a new CR2032 through the 200 ohm and forward-biased silicon diode, assuming no internal resistance of the battery initially, gives us a 1.4v drop across a 200 ohm resistor, yielding a maximum charge current of 7mA.
 -  When the battery gets near discharged to 2.0v, it gets worse.  5.5v - 2.0v - 0.7v = 2.8v across a 200 ohm resistor = 14 mA.
 -  Here it gets interesting.  The datasheet for the Omnergy CR2032 I was looking at listed a maximum reverse current of 10ma, and showed a very similar diode/resistor situation as implemented, minus a diode to protect from providing current to a drooping VCC.  An Energizer CR2032 listed a maximum reverse current of 1 uA.  I think a lot has to do with the chemical manufacturing processes.  In any case, to err on the side of safety, do not operate a charging circuit in this scenario.  Pull the diode, or resistor, or change to a different battery.

2.7v - CR2032:
 -  Though I considered using 3.3v here, the lowest VCC supported by both the RTC and the Serial EEPROM is 2.7v.  Otherwise, same setup as above.
 -  2.7v VCC with a new CR2032 of max 3.4v, reverse-biases the diode, effectively rendering the charging circuit useless.
 -  2.7v VCC with an almost dead 2.0v CR2032, would almost forward-bias the diode.  Lets be conservative, and say 0.1v made it through the diode, the reverse current on the battery would be 0.5 mA.  Still not supported by some battery manufacturers.  Again, its best to disable the charging circuit.

5.5v - LIR2032 - 3.6v:
 -  One of the simpler LIR2032 datasheets I found listed a CC (constant current) and CV (constant voltage) value for charging.  Unfortunately, the on-board charging circuit is neither of those.  Though lets compare it with the nominal values listed.  The datasheet shows 17ma CC and 4.2v CV.  5.5v - 3.6v - 0.7v = 1.2v across a 200 ohm resistor.  This battery datasheet also lists the charge state internal battery resistance of < 600milliohms, so negligible compared to our 200 ohm.  That puts us at a current of 6mA.  Well below the nominal value.  As the voltage raises on the battery while being charged, the current will reduce.  At the 4.2v recommended charge voltage, a continued current of 3mA will flow.  This is probably where an intelligent LiPo charger would cut off.

5.0v VCC - LIR2032 - 3.6v
The same scenario as above, but the charge current would fall off at a lower voltage, improving the scenario.  3.5ma would charge the battery until it hit 4.2v, at which time, .1v across a 200 ohm resistor would allow .5 mA.  This is probably more acceptable.

2.7v VCC - LIR2032 - 3.6v
In this case, the charge-circuit diode is reversed-biased.  The battery would only be charged when it dropped to approximately 2.0v, and then only by half a milliamp until the diode became reversed biased again as reached just over 2.0v.  In both these cases, the charging circuit is effectively disabled.

The result:  The ZS-042 board does not implement a recommended charging circuit for the LIR2032, but in most cases, the existing charge circuit is probably not dangerous, though will probably reduce the effective lifetime of the installed battery.  Installation of a CR2032 in the board is not advised without disabling the charging circuit, in one manner or another.

Disclaimer:  This is only my analysis for my own purposes, posted for others to use or not, as they see fit.


Thank you gwidion for your detailed analysis of the components on this ZS-042 board, very much appreciated.
I have had a number of these and have been aware of the design issue with this board and have come back here to read your notes with view to working out exactly what I need to do to this board to have it 'safe' as well as 'reliable' for use in a test system I am developing. I have boards with both the LIR2032 and the CR2032 batteries.

IN the first instance I will simply remover the diode, if that will be enough to remove charge and any potential over charge of installed battery.

Again, thanks - Paul from down under  :)
Paul - VK7KPA


Thank you gwidion, I remove the diode since I read the same conclusion on the Cave Pearl Project blog.
The other informations a re very useful, I believe maybe that you post should be evidenced.


I am facing the problem, when I switch off arduino power supply and switch, the clock starts as per the sketch and I dont see it save anything. I tested removing the power supply to the rtc positive terminal ,the display paused and when I placed the power supply it continued showing the current, which means it is saving data; but how come it is not saving when complete power off.

Pls help.


I am facing the problem, when I switch off arduino power supply and switch, the clock starts as per the sketch and I dont see it save anything. I tested removing the power supply to the rtc positive terminal ,the display paused and when I placed the power supply it continued showing the current, which means it is saving data; but how come it is not saving when complete power off.

Pls help.
Hi, I too face this issue, did you find the answer. pls reply



Post your code.
If you understand an example, use it.
If you don't understand an example, don't use it.

Electronics engineer by trade, software engineer by profession. Trying to get back into electronics after 15 years absence.

Go Up