RTC bleibt bei Batterie-Versorgung stehen, behält aber die Uhrzeit

[brechbunkt (Gast)]

Hallo,

ich verwende den RTC-chip bq4802Y von TI.
http://www.ti.com/product/bq4802ly/description

Ich hatte ihn vor 2 Jahren in Betrieb genommen und bin mir sicher, dass 
alles funktionierte. Er wird zusätzlich über eine Batterie (CR2032) 
versorgt, die ich nun bereits erneuert habe.

Es ist so, dass er die Zeit nur noch zählt, wenn die Versorgung Vcc 
anliegt. Ohne Vcc und mit Versorgung per Batterie an BC bleibt die Zeit 
stehen und wird nicht weiter gezählt. Das komische ist, er behält die 
Uhrzeit und vergisst sie nicht. Mit Batterie schwingt der 32k-Quarz also 
anscheinend nicht mehr. Ziehe ich die Batterie ab, ist auch die Uhrzeit 
wie zu erwarten auf Null gesetzt.

Leider habe ich nun absolut keine Idee mehr an welcher Stelle ich noch 
nach den Fehler suchen könnte und hoffe um einen Tipp von euch.


Hier hatte jemand (möglicher weise) ein ähnliches Problem, leider aber 
ohne Antworten (meine CR2032 hat aber noch 3,3V):
Beitrag "DS1307 uhrzeit steht mit Bufferbatterie"

[Georg G. (df2au)]

"Uhr steht bei Batteriebetrieb" oder "Uhr läuft bei Batteriebetrieb" 
muss man programmieren. Dafür gibt es ein Bit.

[Ützelbrützel (Gast)]

brechbunkt schrieb:
> ich verwende den RTC-chip bq4802Y von TI.
> http://www.ti.com/product/bq4802ly/description

Das Datenblatt im Link hat folgenden Satz auf Seite 12:
STOP= 1 to turn the RTC on and 0 stops the RTC in battery-backup mode

[c-hater (Gast)]

brechbunkt schrieb:

> Es ist so, dass er die Zeit nur noch zählt, wenn die Versorgung Vcc
> anliegt. Ohne Vcc und mit Versorgung per Batterie an BC bleibt die Zeit
> stehen und wird nicht weiter gezählt. Das komische ist, er behält die
> Uhrzeit und vergisst sie nicht.

Das ist überhaupt nicht komisch oder irgendwie bemerkenswert, sondern im 
Gegenteil völlig normales und erwartbares RTC-Verhalten.

Die Batterie reicht zum Datenerhalt der SRAM-Zellen, aber nicht mehr zum 
Betrieb des getakteten Systems, denn das benötigt in Spitzen drei bis 
vier Größenordnungen mehr Strom als der reine Datenerhalt. Absolut 
normales CMOS-Verhalten, ganz genau wie im Lehrbuch.

> Leider habe ich nun absolut keine Idee mehr an welcher Stelle ich noch
> nach den Fehler suchen könnte und hoffe um einen Tipp von euch.

Batterie wechseln! Was gibt's denn da überhaupt zu überlegen? Jeder 
normaldenkende Mensch, sogar ohne jegliche Elektronik-Kenntnisse macht 
genau das als Allererstes! (Und in diesem Fall sogar einzig Richtiges..)

[tmomas (Gast)]

c-hater schrieb:
> Batterie wechseln!

Hat er doch schon gemacht, siehe Ausgangsposting.

[c-hater (Gast)]

tmomas schrieb:

>> Batterie wechseln!
>
> Hat er doch schon gemacht, siehe Ausgangsposting.

Ich meinte natürlich: Gegen eine funktionierende Batterie tauschen. 
Oft (aber leider längst nicht immer) ist das einfach eine neue 
Batterie.

Auch und gerade bei Batterien gibt es unwahrscheinlich viel Schrott am 
Markt...

[Erich (Gast)]

>Auch und gerade bei Batterien gibt es
>unwahrscheinlich viel Schrott am Markt...

Das kann ich nur bestätigen.
Erst neulich ein "Schnäppchen" von 2 Stück 9-Volt-Blocks zurückgetragen 
in den Laden, der Kurzschlußstrom lag bei 0,012 A und bei Belastung mit 
470 Ohm brach die Spannung ruckzuck auf unter 2 Volt. Leerlaufspannung 
lag aber bei einer knapp über, bei der zweiten knapp unter 9 Volt.

Zum Thema: Eine CR2032 hat ein Datenblatt. Z.B. hier 
http://data.energizer.com/PDFs/cr2032.pdf
Demnach darf selbst mit einer Puls-Last von 100 Ohm die Spannung erst 
mit Verzögerung einbrechen.
Ich denke mal, ein Lastwiderstand von 1 kOhm testweise rangehalten wird 
recht schnell die guten und die Murksbatterien auseinandersortieren.
Eine Leerlaufspannung allein sagt nichts aus.

Gruss