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.
Angehängte Dateien:
-
IMG_0224__640_x_480_.jpg
58 KB
Sind an den diversen ICs jeweils 100nF Kerkos dran?
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
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
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.
Haben die RTC eine eigene, über Dioden entkoppelte Spannungsversorgung ? Otto
Hallo, sie liegt permanent an den Akkus, gepuffert mit 900uF. Keine Dioden mehr, da diese durch den Inrush Current zerschossen wurden.
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
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.
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.
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...
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
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.
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
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.
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.
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....
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...
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.
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.
Hallo Cristian, tolle Mobilfunknummern auf deinem Foto ;-). Jogibär
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
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 !
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.