I'm using a DS3232M that works great for keeping track of the time until I try to write to the SRAM on the chip. When I use the SRAM it slows the updates of the seconds register or stops them all together. I'm writing 18 bytes to the SRAM once per second and the data is not overwriting the timekeeping registers, but it does seem to be preventing the timekeeping registers from updating. As a side note the 1 Hz output pin is outputting a 1 Hz square wave with a 50% duty cycle when I'm not writing to the SRAM, but when I start writing to the SRAM the duty cycle drops to 33%. Why can't I write to the on board SRAM and keep good time?

  • \$\begingroup\$ Are you absolutely sure you're not accidentally setting bit 7 in register 13h (SWRST)? Can you see whether OSF (bit 7 in register 0Fh) is getting set? \$\endgroup\$
    – Dave Tweed
    Jan 14, 2013 at 21:47
  • \$\begingroup\$ Yes. I've tried reading out the entire SRAM contents including the timekeeping registers and all of them have reasonable values in them. The seconds register just doesn't update. \$\endgroup\$
    – mjh2007
    Jan 14, 2013 at 21:57
  • 1
    \$\begingroup\$ Do you have a scope, or what are you using to look at the output pin? If you write to the SRAM once every 2100 ms or so (just use a simple delay loop--the timing isn't precise, so long as it's a little over two seconds), and output a pulse on some pin somewhere each time you do the SRAM write, and also watch the clock and bump another pin each second, how do the SRAM writes interact with the 1Hz output pin and the increments of the clock? \$\endgroup\$
    – supercat
    Jan 14, 2013 at 22:21
  • \$\begingroup\$ Checked the supply line no dips or ripple in the power supply. \$\endgroup\$
    – mjh2007
    Feb 11, 2013 at 16:20
  • \$\begingroup\$ On a second circuit board it doesn't look as though the clock output lines are affected, however the timekeeping registers do not update when writing to the SRAM once a second. \$\endgroup\$
    – mjh2007
    Feb 11, 2013 at 16:22

1 Answer 1


Received this response from Maxim technical support:

After further investigation, we concur that there is a chip problem.

If you begin a write to SRAM at an even address boundary (18h, 20h, 28h, etc.) the internal RTC counter chain is improperly being reset. This reset action is visible if SQW happens to be high when you wrote to the memory.

SRAM locations 14h-17h do not appear to have this anamoly.

Short-term work-arounds:
1) Avoid writing to SRAM locations 18h-FFh
2) Write to SRAM prior to setting the RTC

We will fix the chip. Thank you for bring this to our attention.

Maxim has published this errata covering the issue.

  • \$\begingroup\$ Wow. You found a silicon bug. That's pretty spectacular. \$\endgroup\$ Apr 8, 2013 at 20:28
  • \$\begingroup\$ Did they at least send you a T-Shirt? Don't forget to accept your great answer! \$\endgroup\$ Aug 23, 2013 at 14:57
  • \$\begingroup\$ I often find myself wondering why companies seem to have such trouble making non-goofy RTC chips? It should be simple to make a chip with a fully-exposed 48-bit free-running counter that can be forced to zero but not otherwise set, along with a couple 32-bit compare registers which trigger a wakeup pulse, and a few bytes of memory to hold a time offset. That would seem simpler than existing chips, but allow more precise timings and be easier to use. \$\endgroup\$
    – supercat
    Aug 23, 2013 at 22:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.