Take the 2-minute tour ×
Electrical Engineering Stack Exchange is a question and answer site for electronics and electrical engineering professionals, students, and enthusiasts. It's 100% free, no registration required.

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?

share|improve this question
    
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? –  Dave Tweed Jan 14 '13 at 21:47
    
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. –  mjh2007 Jan 14 '13 at 21:57
1  
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? –  supercat Jan 14 '13 at 22:21
1  
Just a guess but it could be you don't have enough decoupling caps or current available for the write current. Also try putting your scope on the supply line to see if you're getting dips or excessive ripple. –  PeterJ Jan 15 '13 at 4:28
    
Checked the supply line no dips or ripple in the power supply. –  mjh2007 Feb 11 '13 at 16:20
show 1 more comment

1 Answer

up vote 4 down vote accepted

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.

share|improve this answer
    
Wow. You found a silicon bug. That's pretty spectacular. –  Connor Wolf Apr 8 '13 at 20:28
    
Did they at least send you a T-Shirt? Don't forget to accept your great answer! –  Scott Seidman Aug 23 '13 at 14:57
    
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. –  supercat Aug 23 '13 at 22:03
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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