PIC and RTC DS1307 problem - hardware vs software ?

[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 ) , 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

[jorge]

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!

[Steve_88]

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

[jorge]

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?!

[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.

[pedja089]

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

[jorge]

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

[Charles Linquis]

The cap we use is actually a .47 uF ceramic

TDK P/N C3216X8R1H474K