I purchased several of the type of RTC module being discussed - mine have no temp sensor soldered in the corner (at U1), came with an LIR2032 (3.6V Li-Ion rechargeable button cell), and were silkscreened "Tiny RTC I2C modules" (yes, plural). Since I'd ordered them for cheap (US$1.25 each, shipped) and the seller had declared them without batteries, I was quite thrilled not only to have received units with batteries, but to find that they were rechargeable. As already mentioned by others, D1 should be removed if you're using these with conventional (non-rechargeable) CR2032 batteries.
I was thrilled until I went to test an arbitrary one from the batch. I soldered on a 4-pin header (didn't need clock out, battery monitor, or the temp sensor that wasn't present anyway), obtained libraries, and promptly found that I couldn't comm with the device. Got another library, that successfully comm'd - I could read the NVRAM (and if I dumped 256 bytes instead of just 56, I'd also see the stored time values near the end of the block). If I set the time, it'd write to the NVRAM, but the clock would NEVER UPDATE. I removed the battery, checked it and found the voltage was low but rising. I figured there was some sort of short, but there was no low resistances between the battery holder contacts, so I presumed after something was driven powered up, it was latching Vcc to GND or such. With Vcc (no batt) I checked the oscillator using a scope, and found it wasn't running - there was Vcc present, but no oscillation. De-soldered the crystal (which as others have noted, did not have its casing soldered to the immobiliser pad) and replaced it with a 1206 size SMD crystal of the same frequency (I have a binload of SPI RTC units and 32K crystals for other implementations). Still no luck. Note that the case pad has continuity to GND -- it is not merely an island.
In examining the module closer, with the battery removed from its holder, the positive clip (the contact to the side of the battery rather than on the face), had a prong near the base which was too far inwards - such that when the battery was slipped in, that prong would be contacting the face of the battery just inside the "seam". I carefully bent that outwards, inserted the battery, and connected the module to my test rig. Wouldn't you know it, but the oscillator was doing its job, and the RTC would keep time.
That clip issue explains why the battery was shorting out and why the battery was recovering voltage after I removed it from the device. Anyone experiencing an apparent short (esp when not even connected to your project), and not measuring expected battery voltage across the two circa 1.3mm through holes (one between the ICs and the other "above" R6) should check the battery contacts and ensure the side clip isn't bent inwards as mine was.
Note also that some RTC librares in their constructor/initializer set a flag indicating whether they successfully commed with an RTC module. So it you start up and the RTC isn't seen, it'll run an internal RTC implementation (so long as the host AVR is running), and NEVER COMM WITH THE RTC MODULE even if you get it connected properly after that - you'd have to reboot the uC. This was a PITA while dealing with an RTC that wasn't working right, because from all outward appearances, the RTC library WAS working. That made the problem look more like the RTC worked, but wasn't running from battery when the uC reset -- except that I could fully remove the RTC, and the darned library would still be keeping time (which is what clued me into it using an internal fallback for timekeeping). I temporarily instrumented the library code with a few debug statements ("Using realtime" and "Using bogotime") depending upon whether the RTC was actually found, and added the ability to reset the library (moved the initialization code into a reset function, and had the initializer call the reset function) - this because I can't use new or destroy in the crippled bastardization of C++ used in Arduino.
I haven't performed long-term testing of the module just yet (one test would be to read time periodically and waypoint it against the millis() of the uC), but overnight it kept time well enough that I know the module functions.
I subsequently found another seller on Ali Express listing the same module (declared as including the LIR2032 battery) for US$0.95. SHIPPED. I can't buy just the clock chip for that, nevermind the 32Kbit I2C EEPROM (which I have employed directly in circuits before) or the rechargeable battery.
The AT24C32 module functioned just fine (even when the battery contact was a problem, since the flash module doesn't rely on battery) - I could write values say 16 bytes in sequence (i.e. not crossing pages) with the base address being stored into those locations, then come back and read and display the lot and would get the expected result, which confirmed that I had the full 4K byte addressable space and there wasn't addressing wrap. I didn't happen to try to go beyond the stated capacity to force addressing failures. As a side note, because it is a serial EEPROM, you could desolder it and resplace it with a different capacity device if you needed to - or even desolder it from this PCB because you don't need it, and use it in a different project entirely.
Of course, the AVR processors have EEPROM storage as well. If you're scratching your head about what to use the EEPROM for, not that you can store device serialization and calibration data in them - you could "characterize" the RTC against a more reliable time source and write the drift data into the EEPROM (so many sec per day), and tweak the RTC library to automatically shift the clock readings (and store the time of the last correction to the RTC RAM).
Not on this device, but on the AVR projects themselves, I store a unique serial identifier in the EEPROM so that when I send data from the device (usu. via radio), that unique identifier is in there for the receiver to correlate the data to the transmitter device (many to one).
In diagnosing the nature of the device failure, it did not help that there are several for-crap libraries out there, and that some "play" RTC if they don't successfully comm with the device (instead of returning some sort of status).
Note that before isolating and fixing the battery clip, I had run an I2C scan which found the two devices at I2C IDs 0x68 (RTC) and 0x50 (EEPROM).
)
