DS3231 or DS1307 clock loses time: backup battery and coin cell type

If the clock resets when power is removed, the backup battery is missing, flat or the wrong type.

What the message means

The module keeps the time from its own coin cell when the main supply is off. Without a good cell it starts again from a default date.

Fix it in this order

  1. Fit a fresh CR2032 coin cell the right way round.
  2. Measure the cell. A cell well under 3 V is worn out.
  3. Some modules have a charging circuit meant for a rechargeable cell. Use the cell type the module was made for.
  4. Set the time once from your sketch, then remove that line so it does not reset at each start.
  5. Check the I2C address and wiring if the module is not found.

Why it happens

The clock chip counts time on its own, using the main supply while it is present and the coin cell when it is not. With no cell, or one that is flat, the count stops when the main power goes and the chip starts from a default date at the next power-up.

Modules are sold with different cell types and some have a charging circuit meant for a rechargeable cell, so check the markings on your module before you fit a cell. A cell that measures well under its nominal voltage is worn out.

If you see this, do this

You seeDo this
Resets at each power offBattery.
Not found at allI2C wiring.

I2C scan, NTP time on ESP32.

Last reviewed: November 2026. These are the usual causes and the order that finds them fastest. Test on your own board; clones and cables differ.

Why this happens

The DS3231 and the DS1307 contain a counter for seconds, minutes, hours and the date. While the main supply is present, the counter runs from it. When the supply is removed, a backup pin takes over, normally from a coin cell on the module. Without a working cell, the registers lose their content, and at the next power-up the chip starts from a default date.

Accuracy differs between the two chips. The DS3231 contains its own temperature-compensated oscillator, and its datasheet gives about 2 parts per million over 0 to 40 degrees C, which is roughly a minute per year (31,536,000 s x 0.000002 = 63 s). The DS1307 depends on an external crystal and drifts more. Some cheap modules include a charging circuit meant for a rechargeable cell, and fitting a non-rechargeable CR2032 into one is a known concern, so read the module markings.

How to confirm the cause

  • Measure the cell with a multimeter. A CR2032 below about 2.5 V should be replaced, and a fresh one reads near 3 V.
  • Check the holder contacts. A cell that is loose or fitted upside down gives no backup.
  • Run a scanner and look for address 0x68. Note that many motion sensors also use 0x68, so two devices can collide on one bus.
  • Print the lostPower() result from the library at start-up. True after a power cycle with the cell fitted means the cell or its contact is not doing its job.
  • Set the time, remove all power for a minute, restore it, and read the time again. It should have advanced by about a minute.

Worked example

Setting the time only when the chip reports that it lost power, so uploads do not keep resetting it to the compile time:

#include <RTClib.h>
RTC_DS3231 rtc;

void setup() {
  Serial.begin(115200);
  if (!rtc.begin()) { Serial.println("RTC not found"); while (1) {} }
  if (rtc.lostPower()) {
    rtc.adjust(DateTime(F(__DATE__), F(__TIME__)));  // compile time, a little behind real time
  }
}

Common mistakes

  • Calling rtc.adjust() on every start, which resets the time each time you upload.
  • Using a cell of the wrong type for the module.
  • Removing the cell as a test while the main power is also off.
  • Forgetting daylight saving or time zone when comparing with a phone.
  • Assuming that a DS1307 is as accurate as a DS3231.

If this did not fix it

  • Address conflict: two I2C devices at 0x68 give strange results. Change one or use another bus.
  • Weak I2C wiring or pull-ups. Shorten the leads and check connections.
  • Fake or damaged chips on very cheap modules; compare drift with a known good clock.