www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Ärger mit RTC 8563: Sporadischer Zeitschwund


Autor: Christian J. (elektroniker1968)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

vielleicht kann mir jemand helfen bevor ich die ganze Platine wieder 
auséinander reisse.

Zwei PIC teilen sich eine RTC und ein EEPROM. Einer misstem, der andere 
kommuniziert mit einer Basisstation. Sie sind gegeeinander verriegelt, 
damit keine Buskollision auftritt.

Es passiert nun, mindestens einmal am Tag, dass sich die RTC aus 
unerklärlichen Gründen auf 0:00:00 stellt, so als hätte man die Spannung 
abgeklemmt. Ich bin am Ende meiner Weisheit zudem sich der Fehler nicht 
reproduzieren lässt. Selbst eine RTC Überwachung habe ich schon 
programmiert, damit ich den letzten Zeitstempel zurückspielen kann, wenn 
sie sich resettet.

Hat da einer eine Idee?

(RTC ist mit 470uF gepuffert, liegt an 3,6V, I2C mit 10k Pull Up, RTC 
Taktausgang liegt an beiden uC Timer-Countern an mit je 10k) Abfrage 
alle 10s einmal.

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sind an den diversen ICs jeweils 100nF Kerkos dran?

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hübsches Bild, LOL.
Motorhaube auf, ein scharfer Blick hinein und er läuft wieder, sowas 
geht leider nur im Film.


Dein Fehler wird in der Software liegen.
Wenn 2 Master auf nen I2C-Slave zugreifen sollen, müssen sie Multimaster 
sein, d.h. einen Arbitrationsverlust und SCL-Stretching erkennen und 
behandeln können.
Ansonsten haut der eine in den anderen rein und der Slave macht 
natürlich Müll.


Peter

Autor: Christian J. (elektroniker1968)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Peter,

na, so ganz kompliziert ist das nicht: Eine Leitung verbindet beide uC, 
die mit 10k auf Plus liegt. Wenn 1 auf den Bus will schaut er ob diese 0 
oder 1 ist. Ist sie frei zieht er sie selbst runter und geht auf den 
Bus. Der anderemacht das gleiche und merkt: Aha, besetzt, ich darf 
nicht.
Kritisches Zeitfenster: 2-3uS vom schauen, bis allokieren, besser wäre 
fest verdrahtet, ok.  Die I2C leitungen werden passiv immer Hi-Z 
geschaltet.

Es gibt RTC die ein Write Protect Bit haben, diese leider nicht. Wieso 
sollte die sich resetten? Das tun sie doch nur wenn ihre Versorgung 
einbricht und die ist fix.

Um das zu testen kann ich ja mal uC 2 abziehen und ein paar Tage warten. 
PS: Die beste RTC die ich bisher hatte war die DS1306 von Dallas, mit 
den PCF gabs immer nur Ärger, die gehen umso falscher je schneller man 
abfragt.

Die beiden uC sind mit 100n versehen, alles andere nicht. Ok,  Richtig 
Strom zieht nur die IR Diode, ca 50mA Spitzen´und die ist gepuffert.

Gruss,
Christian

Autor: Christian J. (elektroniker1968)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
PS: Kannst Du mal erklären was kein stretching für Fehler erzeugen 
könnte? Meine beiden laufen auf 100khz. Der Compiler bietet Optionen an 
dieses Strechting zu unterstützen.

Autor: Otto (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Haben die RTC eine eigene, über Dioden entkoppelte Spannungsversorgung ?

Otto

Autor: Christian J. (elektroniker1968)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

sie liegt permanent an den Akkus, gepuffert mit 900uF. Keine Dioden 
mehr, da diese durch den Inrush Current zerschossen wurden.

Autor: Otto (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Christian,

da Du einen Zeitwert erhältst, der dem entspricht, den die RTC hat, wenn 
sie neu ist, ist meine Vermutung, dass Soannungseinbrüche zum Verlust 
der Information führen.

Du brauchst keine 900µF - die RTC zieht nur ein paar µA - in diversen 
Schaltungen - u. a. auch Lochrasteraufbauten - verwende ich eine über 2 
Dioden entkoppelte seperate Spannungsversorgung von 1,5V, welche von 
100nF gepuffert wird.

Da rusht dann auch nichts...

Hier hat es noch nie einen Zeitverlust gegeben.

"Zeitprobleme" durch fehlerhaften Zugriff führen i. A. zu unsinnigen 
Speicherinhalten.

Gruss Otto

Autor: Christian J. (elektroniker1968)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

wenn man eine Diode einsetzt, dann liegt der Vdd unterhalb dem Pegel der 
Datenleitungen. Das kann dazu führen, dass über die Clamp Dioden Strom 
fliesst. Müssen also Schottky sein. Was ich nicht verstehe ist, warum 
"fehlerhafter Zugriff" zu einem Verlust der Infos führen kann? Manche 
RTC sind dagegen abgeriegelt durch ein WP Bit, die leider nicht. Ich 
weiss allersdings nicht ob diese RTC den Clock wieder loslässt wenn sie 
intern zu tun hat und nicht etwa das Clock Signal streched.

Ich benutze die HAL Funktionen des CCS Compilers mit einer Software I2C. 
Das hat bisher immer gut funktioniert wenn ich nur ein EE dran hatte. 
Derzeit läuft der Wecker auf meinem Bürotisch bei abgeschalteten PICs, 
mal schauen wie er heute abend so aussieht.

Autor: Otto (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
nicht eine, sondern 2 Dioden (eine für die "normale" Versorgung und eine 
für "Backup" -> ODER-Schaltung) und es müssen nicht zwangsläufig 
Schottky sein, denn der Spannungsabfall ist bei dem minimalen Strom 
deutlich únter dem für Si-Dioden normal üblichen.

Autor: Christian J. (elektroniker1968)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Habe schon verstanden, so dass immer eine Batterie einspringen kann wenn 
der Pegel der anderen sinkt.

Was mache ich nun? Mein kleines Wunderwekrk wieder abreissen, alles auf 
einen PIC setzen? Den 2.ten habe ich ja nur, weil ich mit dem Platz des 
ersten nicht hinkam, war ausserdem ein Batselreiz mal zwei zu verwenden.
Oder jedem I2C Modul eigene leitungen spendieren, was ja bei Software 
I2C kein problem ist. Eine Backup Batterie brauche ich eigentlich nicht, 
die Akkus sind ja dauernd eingebaut. Wobei diese Fassungen hinsichtlich 
Kontakt grauenhaft sind, musste alle nachlöten...

Autor: Otto (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du musst Dein Wunderwerk nicht abreissen, um 2 Dioden zu integrieren - 
falls dies nicht die Ursache war, wäre eine weitere Möglichkeit, dass 
nur ein PIC Master ist und die RTC ausliest und dem anderen PIC die 
Information sendet....

Otto

Autor: Christian J. (elektroniker1968)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Otto,

wofür 2 Dioden? Ich habe 1 x Batterie, was sollte mir eine Diode zur RTC 
bringen? Das Konzept nutzt man doch nur, wenn man eine Backup Batterie 
hat und eine Hauptstromversorgung. Solange der Wecker Strom hat läuft 
er.

Was ich jetzt machen werde:

1. Den uC 2 abziehen und einen Tag warten was sich tut.

2. Die RTC ganz ohne uC laufen lassen.

3. Den uC 1 abziehen und nur uC 2 laufen lassen.

4. Benutzung einer Hardware I2C, der grosse PIC hat eine, die nutze ich 
aber nicht. Programmiere ich auch nicht slebst sondern nutze die HAL des 
Compilers.

Daraus müssten sich Rückschlüsse zíehen lassen wo der Fehler liegen 
könnte.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian J. wrote:

> na, so ganz kompliziert ist das nicht:

Wenn man es sauber machen will, dann geht das nur so. Multimaster geht 
allerdings schwer mit SW-I2C.


> Kritisches Zeitfenster: 2-3uS vom schauen, bis allokieren

Das reicht bei Softwarelösungen vollkommen aus.
Da ja viele Millionen Zyklen pro Sekunde ausgeführt werden, wird schnell 
selbst das Unwarscheinlichste eintreten.

Ich hatte kürzlich auch eine kritische Sektion von nur 2 Zyklen (=130ns 
bei 14MHz) alle 10ms und prompt wurde diese innerhalb weniger Minuten 
getroffen.
Ich konnte durch Vertauschung der 2 kritischen Zugriffe den Ablauf 
sicher machen und der Fehler war weg.

Warum wurde die kritische Sektion aber so schnell getroffen?

Der Grund war, daß eine andere CPU alle 200ms Daten sendete und 200ms 
ist ein Vielfaches von 10ms.
Nun laufen beide Quarze aber nicht exakt synchron und so erfolgte jeder 
Zugriff um Bruchteile eines Zyklus später. Die CPU mußte also 
unweigerlich in den kritischen Bereich reinlaufen.


Peter

Autor: Christian J. (elektroniker1968)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Peter,

danke für Deine Ausführungen, nur.... alle 10s passiert was von uC1 und 
alle 30s von uC2. Möglicherweise finde ich den Fehler nie und er 
verschwindet erst, wenn ich das Konzept geändert habe. Solche "Lösungen" 
hatte ich ein paar mal in meinen 10 Jahren als Entwickler als die 
internen Vorgänge der Chips nicht ermittelt werden konnten. Es kann ja 
auch niemand erklären warum eine PCFxxx (eine andere) umso falscher 
geht, je öfter man sie abfragt. Ist aber so und EMC sollte bei 100khz 
kein Thema sein. Die DS 1306 kann ich abfragen so viel ich will, bei der 
tickts immer richtig :-)

Ohne Datenlogger sehe ich da keine Chance.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian J. wrote:
> danke für Deine Ausführungen, nur.... alle 10s passiert was von uC1 und
> alle 30s von uC2.

Das klingt schonmal sehr schön. 30s ist ja ein Vielfaches von 10s und 
damit ist die Warscheinlichkeit sehr hoch, daß beide aufeinander 
prallen.


Du hast ja eine Handshakeleitung, aber diese nicht gleichberechtigt 
benutzen, sondern einer ist der Obermaster.
Der Obermaster zieht die Leitung auf Low, wenn er senden will. Dann 
wartet er ne Weile (~1ms) daß der Bus frei ist und erst dann sendet er.
Der Untermaster darf nur senden, wenn die Hadshakeleitung high ist. 
Sobald er ein Low erkennt, muß er sofort STOP senden, um den Bus 
freizugeben.


Peter

P.S.:
In der Codesammlung ist ne Bauanleitung für nen I2C-Sniffer.

Autor: Christian J. (elektroniker1968)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Peter,

wäre gleichberechtigt überhaupt möglich? Der zuerst da ist mahlt zuerst? 
Ich könnte die 1ms ja dort auch einbauen, um den kritischen Bereich zu 
kaschieren.

Nochmal gefragt: Was kann eine RTC dazu bewegen sich zu vergessen, wenn 
Müll auf dem Bus anliegt? Da läuft ´doch eine Statemachine drin,m die 
stur abarbeitet was kommt und die bei jeder start Condition resettet. 
Der Chip resettet laut Datenblatt seine internen Register NUR, wenn der 
Oscillator mal kurz stillsteht.

PS: Seit 1:35h läuft er durch mit nur uC1 im Sockel....

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vieleicht hast du das Problem das zwei konkurierend aktiv den Bus 
treiben --> Kurzschluß --> Spannungseinbruch --> Reset...
Ich weiß ja nicht wie du die CLK Leitung etc in deiner Softwarelösung 
handhabst...

Autor: Christian J. (elektroniker1968)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Compiler steht die Funktion bereit:

#use i2c(Parameterliste, Pins, Slow, Fast, Strech, Nostretch usw)

Ist Hardware da nutzt er sie, ist keine da emuliert er. Dazu muss der uC 
mit mindestens 4 Mhz betrieben werden wenn er I2C Zugriffe macht. Vorher 
muss ich den uC Takt definieren, damit er das Timing daraus ausrechnet.

und dazu

i2c_start()
i2c_write()
i2c_stop
i2c_read (mit ack)
i2c_read (ohne ack)

Da tut er schon seit rund 8 Jahren und ich habe eine Version von 2007.

Nehme jetzt mal eine Büroklammer und lege den Bus SCL und SDA dauerhaft 
auf LOW, mal schauen.... Kurzschluss: OSC1 und OSC2: Inhalte ok. 
Kurzschluss INT - GND: Inhalte ok. Kurzschluss Clockout - GND: Inhalte 
ok.

Komisch..... mit "roher Gewalt" lässt er sich also nicht dazu bringen.

Autor: Christian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nachwort:

Wieder daheim mal etwas experimentiert, beide uC mit 20ms Abstand auf 
den Bus zugreifen lassen, mit und ohne Kollisionskontrolle, jedoch nur 
Lesebefehle.

Ergebnis: Die RTC verliert wahllos die Daten, wenn es "kracht", mal 
früher mal später.

Ja, die Geheimnisse der Elektronik...... seufz.

Autor: Michael J. (jogibaer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Cristian,

tolle Mobilfunknummern auf deinem Foto ;-).


Jogibär

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian wrote:
> Ergebnis: Die RTC verliert wahllos die Daten, wenn es "kracht", mal
> früher mal später.

Also der eine fängt an zu senden.
Dann zufällig im Lese-/Schreibauswahlbit sendet der andere los (SDA = 0) 
und macht ne 0 draus, also schreiben.
Und schon liest Du den RTC nicht, sondern schreibst irgendnen Müll rein.
So einfach ist das.


Du brauchst entweder ne zusätzliche Handshakeleitung, damit wirklich nur 
einer zugreift oder HW-I2C als Multimaster.

HW-I2C erkennt, ob der Bus belegt ist, bzw. wenn beide gleichzeitig den 
Bus belegen, synchronisieren sie sich automatisch mit SCL-Stretching.
Und bei dem ersten unterschiedlichen Bit verliert einer die Arbitration 
und verabschiedet sich sofort. Dadurch sind die Daten des anderen 
ungestört.


Peter

Autor: Christian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Peter,

HW steht leider nicht zur Verfügung aber ich habe die "kritische Zeit" 
auf 6 Zyklen reduziert bei 200ns/Zylus. das ist nur eine Mikrosekunde 
und die bei 30s zu treffen, dazu gehört schon viel Pech.

So.... und jetzt erstmal ein Bier aufmachen.

FINAAAAAALLLLEEEEEEEEEEEEEE   !

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.