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