I2C Eeprom: Buskollisionen nach einem schnellen Reset

[AL (Gast)]

Hallo zusammen,

wenn ich den Controller mitte einer Kommunikation mit dem (I2C) Eeprom 
unterbreche und resete (z.B. während dem Debuggen, oder auch mit einem 
schnellen spanungsreset), antwortet der Eeprom nicht mehr und bekomme 
nur Buskollisionen!
Erst wenn ich die ganze platine von der Versorgung trenne und kurz warte 
dann ist alles wieder ok.
Ich glaube der EEprom bleibt mitte in der Kommunikation, ignoriert die 
neuen Start-Befehle udn bekomme die Buskollisionen,kann das stimmen?

[Olaf (Gast)]

> Ich glaube der EEprom bleibt mitte in der Kommunikation, ignoriert die
> neuen Start-Befehle udn bekomme die Buskollisionen,kann das stimmen?

Ja das kann stimmen. Wackel bei deine I2C-Initialisierung mal mit SCL.
Kann sein das die Statemachine im EEPROM dann wieder aufsetzt.

Olaf

[TK (Gast)]

Normalerweise müßte das Ganze mit einem STOP zu beheben sein. Wenn ein 
Device ein STOP erkennt, sollte es den aktuellen Vorgang abbrechen.

Gruß
TK

[hubert (Gast)]

Ich erinnere mich dunkel an eine Diskussion zum selben Thema, die bei 
der I2C Treiberentwicklung für Linux geführt wurde. Wenn ich mich 
richtig erinnere war das so:
Wenn ein Lesevorgang durchgeführt wird, darf man nicht mitten im 
Datenwort aufhören die Taktleitung SCL zu takten, da das Byte noch halb 
im Ausgangsregister drinsteckt. Dieses Byte muß in jedem Fall erstmal 
fertig ausgegeben werden bevor eine Stop-Condition kommen kann. Das 
EEPROM selber hat ja keinen Reset-Pin. Da kommt nur irgendwann mal ein 
Timeout zustande.
Wenn Du also mitten im Lesevorgang abbrichst kannst Du:
1. Eine Zeitlang warten (-> Datasheet)
oder 2. Power-Reset machen
oder 3. nach der Unterbrechung die SCL-Leitung noch eine Zeitlang takten 
um die restlichen Bits noch rauszuschütteln.

[hubert (Gast)]

PS.: Mit dem Timeout bin ich mir am wenigsten sicher...

[AL (Gast)]

das mit dem Timeout finde ich nirgendwo im Datenblatt!

[Peter D. (peda)]

Nach dem Reset weiß Dein AVR-TWI ja nicht, daß der EEPROM noch Daten 
sendet und in welchen Takt er gerade ist.
Das TWI kann die Blockierung daher nicht aufheben und wird ständig 
Fehler melden.

Du mußt Dir daher eine Software-I2C Funktion schreiben, die solange 
versucht STOP zu senden, bis es klappt. Wenn es nicht klappt, ne 
SCL-Flanke und weiter versuchen. Im Worst Case braucht es 9 Versuche.
Ich hab gerade leider nur ne 8051-Assembler Funktion gefunden:

;----------------------  send stop ---------------------------------------
;Input:  CY = 0: no previous error
;Output: CY = CY OR 1: Error, SDA or SCL still low
;SDA: X -> 1
;SCL: 0 -> 1
SI2CSTO:
  clr ssda
  mi2cdelay cycle_4us - 1
  setb sscl
  mi2cdelay cycle_4_7us - 3
  orl c, /sscl    ;test sscl
  setb ssda
  nop      ;time to go high
  orl c, /ssda    ;test ssda
  ret
;----------------------  reset the I2C bus -------------------------------
;Output: CY = 1 Error, reset failed
;SDA: X -> 1
;SCL: X -> 1
SI2CRES:
  mov r2, #9    ;try it 9 times
?si2crs1:
  clr c
  clr sscl        ;generate clock pulse
  call si2csto    ;try sending stop
  jnc ?si2crs2
  djnz r2, ?si2crs1
?si2crs2:
  ret

Das Prinzip sollte aber daraus ersichtlich sein.


Peter

[Olaf (Gast)]

> das mit dem Timeout finde ich nirgendwo im Datenblatt!

Ich glaub auch nicht das es einen Timeout gibt. Zwei Gruende:

1. Wo soll das zeitbestimmende Glied sein? Es gibt weder einen
   Kondensator, noch einen Takt der gezaehlt werden koennte.

2. Wie lang sollte die Zeit sein? Egal was man darauf antworten
   wuerde, es gibt immer eine Zeit die fuer eine Anwendung zu
   lang und fuer eine Andere zu kurz ist.

Ich denke daher in den Teile wird lediglich eine Statemachine drin sein 
die als Basis die SCL-Takte zaehlt. Von daher erscheint es mir am 
vernuenftigsten einfach ein paar Takte rauzuschicken wenn es ein Problem 
gibt.

Olaf

[Jörg S. (joerg-s)]

In der Regel steht in den Datenblätter was von SCL Clock Min:0Hz 
Max:400kHz
D.h. ein 0Hz Clock ist auch noch erlaubt, Ergo: Kein Timeout.