PIC and RTC DS1307 problem - hardware vs software ?

Hi everyone ( specially Melabs PBP PRO´s :rolleyes: )

i ve almost a two years old project that suffers from specific a RTC problem that i ve been unable to workaround .. All the RTC program routines and PIC code are working ok and this only happens once in a while. Capacitors on power leads ( 10uf) and system gets power from a standard SMD LM7805 with 100uf !! capacitors.
Standard DS1307 to PIC ( from manufacturer app note) schematics used.

The problem is that from time to time (without any specific reason – noise I guess… ) the dallas RTC DS1307 get´s all it ´s internal data corrupted and i ve to program it again with valid clock and date settings.
Fist I manage to insert an auto-routine that when detect that no valid data was inside the RTC anymore it would program it with the manufacture date and alert the user to set date/time again asap.
This would be fine, but creates another problem….until the user sets the current clock&date again, all the data after the this “auto-date” solution must be cross reference to the last valid RTC reading to extrapolate the actual date of the recordings of all the probes values… ( otherwise all the new values are referenced / starting based in the manufactured auto start date)

Last note: the DS1307 battery is assembled and in good condition all the times.


So, my question(s) are:

-i know that the DS1307 can suffer from similar problems in noisy conditions or when a bad write command is given and gets interrupted ( which doesn’t seem to be the case), but can I ve any hardware solution or a cleaver software workaround to this ?

- Any of you PRO´s had any similar problem with the DS1307 RTC and/or have any “advice” in terms of schematics?

Thanks in advance for any help !:-)

Any advice or information would be really good.

Regards,
Jorge

Hi Jorge,

Do you have more than one of these units made? If so is the same problem happening to each of them or only the one unit? Do you have any capacitors on the power leads? .1uF AND 10uF?

I personally haven't used this particular RTC but do use the DS1337. I've had 80 of them out in the field and aside from gaining/losing time over a two year period, there hasn't been any problems. I keep three of them at home and only leave them running on a 2032 battery. Then a week or two before the DST changes I power them up and check on the time and it has been fairly good. I cycle the main power on and off several times whenever I can just looking for problems like you mention but haven't encountered anything yet.

Care to share the schematic and some code?

BobK

I use the DS1307. Power on/off will corrupt register if connect/disconnect is too noisy causing the DS1307 to go no/off battery too rapidly. Use a clean toggle power switch. Worked for me.

Jorge,

I use the DS1307 and this problem already occurred with me in the past. My project is the POV Clock by Pimentel from community competition (look in this site). In my case was the current colapse, then I needed to increase my power (12 to 13.5v) because I was using a fet wired in the coil (transformer with air nucleus and it needed more volts to work fine. I don't know if when your circuit loose the data is because your hardware is consuming more current...but with me it occurred!
Other thing that may be the BROWNOUT RESET config. Is ON or OFF? Try OFF !

Pimentel

thanks for all the advices :) !

i guess my problem is really in the powersupply that makes DS1307 reset and looses all the settings (even with the 3v coin cell battery :confused: ) , but i was hoping some software magic to workaround this.

Just a doubt, why should the BROWNOUT RESET setting make it more reliable in noise related problems ?!?
thanks again for all answers!

I had this issue long ago with many DS1307's. I found a Dallas app note that suggests a large negative going spike on the supply rail will corrupt the clock. I verified with a scope that upon power up my supply was indeed going negative by five or ten volts. I put a shottky across the 5 volt line to clamp the negative spike and have not had a re occurrence of the corruption in many years. See the last page of the attached app note.

Quote:

---

Originally Posted by Steve_88

I had this issue long ago with many DS1307's. I found a Dallas app note that suggests a large negative going spike on the supply rail will corrupt the clock. I verified with a scope that upon power up my supply was indeed going negative by five or ten volts. I put a shottky across the 5 volt line to clamp the negative spike and have not had a re occurrence of the corruption in many years. See the last page of the attached app note.

---

Thanks a lot Steve_88 !. I will try it.
I never thought of that because i have a power supply with a transformer with 12v and 9v regulators for relays and other electronics and only after i have another interconnected board with 7805 regulator powering the PIC , MAX 232 , RTC and so on ...also i ve smd BAS19 diodes protecting eveything for wrong assembling.
Since i ve no communications with an external PC or similar , i didn’t realize i could be getting negative spikes :rolleyes:

by the way, where did you put the shottky precisely ? ...I am afraid about the ~0.3 voltage drop i will be getting from it in some components.

Thanks !!!

Quote:

---

Originally Posted by jorge

thanks for all the advices :) !

i guess my problem is really in the powersupply that makes DS1307 reset and looses all the settings (even with the 3v coin cell battery :confused: ) , but i was hoping some software magic to workaround this.

Just a doubt, why should the BROWNOUT RESET setting make it more reliable in noise related problems ?!?
thanks again for all answers!

---

I think that your circuit reset the PIC when the noise occurs! For example, if the VDD down it can reset the PIC , by something with current consume, a rele, a servo, step motor, or a noise by power as an oscilation on Vout...With me occured this problem when was using a servo. Then I change the BOR to off and solved my problem...then I suggested it to you. I think that would be more robust to the noises, therefore reset I could be occurring when pic is in communicating with RTC.

It is a part of datasheet of 16f877A...
12.7 Brown-out Reset (BOR)
The configuration bit, BODEN, can enable or disable
the Brown-out Reset circuit. If VDD falls below VBOR
(parameter D005, about 4V) for longer than TBOR
(parameter #35, about 100μS), the brown-out situation
will reset the device. If VDD falls below VBOR for less
than TBOR, a RESET may not occur.
Once the brown-out occurs, the device will remain in
Brown-out Reset until VDD rises above VBOR. The
Power-up Timer then keeps the device in RESET for
TPWRT (parameter #33, about 72mS). If VDD should fall
below VBOR during TPWRT, the Brown-out Reset process
will restart when VDD rises above VBOR with the
Power-up Timer Reset. The Power-up Timer is always
enabled when the Brown-out Reset circuit is enabled,
regardless of the state of the PWRT configuration bit.

Good luck

Pimentel

Thanks Pimentel :- ) !

But maybe i was not clear. I know what is the Brown-out Reset in the PIC and i use it.
I tried some time ago, and turning off or on didn’t seem to make any difference.
Unfortunately I still was getting these weird garbage data in RTC from time to time …
BTW I am using a 18F4520 ( back in the old times with the 16F84 or even the 16F877 things were much more simple ;- )

I thought that there were some hidden features in the DS1307 regarding the BOR also ;-) ….
I also tried to make some kind of smart routine that recorded the RTC data in the PIC EEPROM each minute, and when detect the RTC data was corrupt and would program it with last valid info I had in the PIC EEPROM…the problem is that ~5 years from now I would probably kill my eeprom with all those write cycles ;-)

Anyway, I am starting to think that Steve88 info is really what is happening with me .
Maybe negative spikes, ( GND reference) / electrical noise is not well filtered .
I will test it and update this topic as soon I ve more news.

Thanks everyone!

Good luck, let us know of it helps. A clue for me was that the clock only reset after removing/applying power.

Unfortunately it still happens…
and also sometimes it freezes time in some modules, the main controller still working ok but the clock info freezes on the LCD (this is not fault of the main PIC18F as the other routines and peripheral are working ok).

I am beginning to hate these DS1307 chips …
The strange thing is that this only happen in some units, and I am not able replicate the problem in the lab.

Anyone had problems with time being freeze in the RTC for no reason?!

I had a similar issue several years ago with a 1307. I can't explain exactly what the problem was, but putting a 1uF very low-leakage cap across the battery solved the problem. An added benefit was that - if you were quick, you could change the battery without clearing the clock. The chip will run on the capacitor alone for 10-20 seconds. The cap has to be low-leakage, otherwise it will drain the battery.

That problems can cause static electricity, or arcing in relays etc. You should put 100nF 10nF and 1nF capacitor, close to power pins.

Quote:

---

Originally Posted by Charles Linquis

I had a similar issue several years ago with a 1307. I can't explain exactly what the problem was, but putting a 1uF very low-leakage cap across the battery solved the problem. An added benefit was that - if you were quick, you could change the battery without clearing the clock. The chip will run on the capacitor alone for 10-20 seconds. The cap has to be low-leakage, otherwise it will drain the battery.

---

I cant find a cap like the one you said - 1uF very low-leakage cap-
i tried at Farnell, digikey and so on...but if you could provide me a direct link or even a full spec of one would be great..otherwise i am afraid of it draining the battery ! :(

Also i already have lots of caps both in the power supply , lots of 100nf on the pcb board, the standard ones on LM7805 , and so on..
My biggest problem is that i cannot simulate it , and as so i cant provide a valid software workaround to the RTC stop/ it just freezes time without any reason.
( note: i ve already replaced the board and the DS1307, check the value of all the resistors ( 10K ) , check and changed the RTC OSC, redesign PCB in terms of ground and power lines, check solders, and so on....felling lost now)

thanks for your help.

note:
Darrel , MisterE , & other PRO´s: any miracle software workaround you can think for this -the freeze time on the RTC ? Maybe using the PIC EEprom and an pic check stall time function...i am just worried that this way i will kill my EEPRom sooner or later
I already have a auto set date/time when it has garbage settings inside but not when it simply stops without a reason.
Damm i hate these DS1307 things :(

The cap we use is actually a .47 uF ceramic

TDK P/N C3216X8R1H474K