Moin, etwa alle 6-10 Wochen hängt sich mein "Wetterfrosch" auf dem u.a. ein STM32F1xxx ein 1Mbit EEPROM von Atmel mit Daten beschreibt, weil das E2P (E2PROM) nicht mehr reagiert. Nur Strom aus/ein hilft da noch. Die Statemachine des E2P arbeitet zusammen mit der I2C Prime Cell eines STM32F1xx. Diese ist nicht ganz fehlerfrei, wie man dem Errata Sheet und einigen Foren entnehmen kann aber sie funktioniert, wenn man zb auf DMA verzichtet. https://github.com/jeelabs/embello/issues/76 Die Ursache für das Hängen liegt aber nicht in der Prime Cell, denn diese kann durch ein Bit komplett resettet werden. Bei mir hängt tatsächlich das E2P. Wie geprüft? An einem AVR mit Bit-Banging I2C passiert es genauso, eine Frage der Zeit, Tage, Wochen, irgendwann kommt die Meldung, dass das E2P gar nicht mehr reagiert. EMV, Blitz, Gewitter, irgendwas eben. Ist es daher ratsam, so ein kleines E2P zb mit einem Port Pin zu versorgen? Braucht nur wenige mA, packt der uC locker. Als "Power-On-Reset" ? Bisher nur mit Atmel I2C EEPROM geprüft, bei Microchip kommt das aber auch wohl vor. Die Empfehlung "Software I2C" ist zwar nett, die man oft liest aber die I2C Hardware ist ja nicht dazu da, dass man sie nicht benutzt und sie arbeitet zudem autonom, braucht keine CPU Zeit. gruss, Christian I2C : Weniger Leitungen - Mehr Probleme!
Christian J. schrieb: > Ist es daher ratsam, so ein kleines E2P zb mit einem Port Pin zu > versorgen? Ja, das ist generell bei jeder I²C Peripherie ratsam, wo ein manueller Reset inakzeptabel ist.
Stefanus F. schrieb: > Christian J. schrieb: >> Ist es daher ratsam, so ein kleines E2P zb mit einem Port Pin zu >> versorgen? > > Ja, das ist generell bei jeder I²C Peripherie ratsam, wo ein manueller > Reset inakzeptabel ist. Bei der DS3231 RTC vermutlich weniger, bei der ist bisher nix passiert und die arbeitet seit 2 Jahren an der Wohnzimmerwand mit. Am gleichen I2C Buss, gleicher uC. Auch bei Gyro Sensoren noch nie Probleme gehabt und die werden 400khz ohne Pause abgefragt, 24/7 die Woche. Max 2-3cm Leitungslänge, alles dicht an dicht.
Was stabil läuft braucht natürlich keinen Workaround. An der Wohnzimmerwand kann man notfalls auch mal Hand anlegen. An einem Roboter auf dem Mars wird das schwieriger.
Ist Dir beim STM32 da schon mal was aufgefallen? F1xxx oder F407 ? Sollen wir die Software mal abgleichen? War ne Menge Arbeit die zu schreiben, vor allem wegen der Fehlerabfragen.... streng nach Datenblatt.
Ich hatte auch schonmal Probleme mit einem I²C EEPROM, aber da lag es an der I²C Peripherie im Controller (Renesas H8). Die hat ab und zu einen Takt zuviel ausgeben und dann hat das EEPROM darauf gewartet dass noch weitere 7 Takte für das nächste Byte kommen. Die Peripherie im Controller hat sich dann auch aufgehangen weil das EEPROM die Datenleitung blockiert hat. Die radikale Lösung war dann die I²C Peripherie abzuschalten und 7 Takte über die GPIO Pins zu erzeugen. Dann konnte das Modul im µC wieder gestartet werden.
Bei einer Anwendung mache ich einfach "Clocking Through the Problem" aus AN-686: https://www.analog.com/media/en/technical-documentation/application-notes/54305147357414AN686_0.pdf Gruss Chregu
Christian M. schrieb: > Bei einer Anwendung mache ich einfach "Clocking Through the Problem" aus > AN-686: Kenn ich, hilft aber auch nix, schon ausprobiert. Gibts auch von Microchip so eine AN, 9 Clocks Reset oder wie sie heisst.
Christian J. schrieb: > , weil das E2P > (E2PROM) nicht mehr reagiert. Ich glaube das auch nicht. Die Ursache ist woanders! Habe ein paar AT24CM02 im Einsatz. Seit Monaten stabil.
Solution 2: Adding a Reset Pin to an I2 Another method will reset the I2 C slave. One function never seen on an I2 C slave is a reset pin. To remedy this type of problem, a reset function is added via additional hardware: an analog switch. The analog switch needs several attributes to perform the reset function properly. The ADG749 fills the requirements. Ein Transistor würde es auch tun denke ich, PNP oder NPN, ginge beides. Verliert das EE die Masse zieht es sich nach VCC über die Pull Ups. Müsste auch resetten.
In der Regel ist ein Bushänger ein Programmfehler. Ich habe diverse I2C jahrelang laufen, ohne Hänger. Ein beliebter Fehler ist, vor dem letzten Byte lesen nicht das NACK zu setzen. Das NACK sagt dem EEPROM, daß er den Bus freigeben soll. Ansonsten kollidiert das STOP mit dem nächsten Datenbit und der Bus hängt, wenn es 0 ist. Christian J. schrieb: > Die Empfehlung "Software I2C" ist zwar nett Zumindest um den EEPROM zu resetten, ist sie erforderlich. Man taktet damit bis zu 9-mal den SCK und prüft jedesmal, ob SDA = 1 ist. Erst dann kann der Master wieder ein START senden.
Christian J. schrieb: > Kenn ich, hilft aber auch nix, schon ausprobiert. Gibts auch von > Microchip so eine AN, 9 Clocks Reset oder wie sie heisst. Dann hast Du was falsch gemacht. Das funktioniert immer. Der EEPROM hat nur ne Statemaschine, die kann sich nicht aufhängen. VCC zu schalten, ist ne blöde Idee, denn dann wird der EEPROM rückwärts über die beiden Pullups versorgt. Die müßte man also mit abschalten.
:
Bearbeitet durch User
Arduino Fanboy D. schrieb: > Die Ursache ist woanders! - "Meine Hardware ist über jeden Zweifel erhaben" - "Ich weiss dass der Controller eine Macke in der Hardware hat, aber ich werde sie um keinen Preis umgehen."
Peter D. schrieb: > Der EEPROM hat > nur ne Statemaschine, die kann sich nicht aufhängen. Peter D. schrieb: > Zumindest um den EEPROM zu resetten, ist sie erforderlich. Das ist für mich widersprüchlich. Entweder sie (die Statemaschine) kann sich nicht aufhängen, dann kann man sie durch "normales" Behandeln/Kommandieren weiterbringen, oder sie kann sich aufhängen, und der Reset ist der einzige Ausweg. In meinem Verständnis vom I2C Bus muss eine Stop-Condition die auf den Bus gegeben wird, jeglichen Slave von einer Aktivität am Bus abbringen.
Meine Phantasie schrieb: > Das ist für mich widersprüchlich. Entweder sie (die Statemaschine) > kann sich nicht aufhängen, dann kann man sie durch "normales" > Behandeln/Kommandieren weiterbringen, oder sie kann sich aufhängen Sie hängt sich ja nicht auf, der Master wurde nur falsch programmiert. Jedes ACK vom Master setzt den Slave für das folgende Byte in den Datensendemodus. Die Statemaschine funktioniert also einwandfrei. Meine Phantasie schrieb: > In meinem Verständnis vom I2C Bus muss eine Stop-Condition > die auf den Bus gegeben wird, jeglichen Slave von einer > Aktivität am Bus abbringen. Dann hast Du die I2C-Spezifikation nicht verstanden. Für ein STOP muß der Master auf SDA eine 0->1 Flanke legen. Er muß also vorher mit NACK dem Slave mitteilen, daß er ein STOP senden will. Denn riechen kann der Slave das ja nicht.
Das Stop Signal kann nicht erzeugt werden, solange der Slave ein Low-Bit auf den Bus legt.
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.