AVR TWI Bug?

[Christian (Gast)]

Hallo allerseits!

Ich kämpfe schon seit einigen Tagen mit dem AVR und seinem TWI.
Ich habe vor einigen Wochen günstig einen Tresor von Burg Wächter mit 
elektronischem Schloss erworben. Die PIN war unbekannt, aber der Tresor 
offen. Ich dachte "Challenge Accepted!". Nachdem ich die Rückwand der 
Innenseite der Tür entfernt habe fand ich eine Platine mit einem EEPROM 
der meiner Vermutung nach die PIN enthalten musste. Der EEPROM war in 
kürzester Zeit ausgelesen, aber die PIN war nicht eindeutig zu 
identifizieren. Plan B musste her! Ich nahm also einen ATMEGA8 um den 
EEPROM zu emulieren, den Inhalt hatte ich ja. Nach einiger Zeit 
funktionierte auch das Auslesen der Daten, allerdings nur mit dem ersten 
Schreib-Lesezyklus. Der AVR scheint nach der ersten Stop-Condition SDA 
auf low zu ziehen und bringt damit die Kommunikation durcheinander.
In Folge dessen habe ich einige probiert:
kurze Leitungen, lange Leitungen (länge egal), interne Pull-ups vom AVR, 
externe Pull-ups (Platine sollte allerdings schon die nötigen Pull-ups 
haben, aber in der Verzweiflung probiert man so einiges aus), ATMEGA8, 
ATMEGA32, AT90CAN128, zwei unterschiedliche Slave Implementierungen. 
Alle mit dem selben Ergebnis: Nach der ersten Stop-Condition zieht der 
AVR SDA gleich auf low. Auf dem Screenshot kann man das wunderbar 
erkennen (roter Kreis). Wird direkt der EEPROM, ein 24AA02 von 
Microchip, angescholossen bleibt SDA an entsprechender Stelle high.

Hat jemand schon ähnliche Erfahrungen mit dem AVR als TWI-Slave gemacht? 
Ich würd nicht sagen dass ich langsam sauer werde, aber ziemlich 
gefrustet!

LG, Christian

[Christian (Gast)]

Der zweite Screenshot ist doppelt.

[Winfried J. (Firma: Nisch-Aufzüge) (winne)]

beim letzten Byte statt "ACK"  "NACK" setzen

[Christian (Gast)]

Ja, das dachte ich mir auch. Daher habe ich nach Empfang der 
Stop-Condition TWEA explizit nicht gesetzt. Hat aber leider auch nichts 
geholfen. Zuletzt habe ich die TWI-Slave Implementierung von Atmel 
benutzt, die das ja prinzipiell 'eigentlich' richtig machen sollte.

[Jörg W. (dl8dtl) (Moderator)]

Christian schrieb:
> Hat jemand schon ähnliche Erfahrungen mit dem AVR als TWI-Slave gemacht?

Ich blicke auf die Schnelle nicht ganz durch, ob die Bedingungen gleich
sind oder nicht.  Auf jeden Fall habe ich einen ATmega128RFA1 schon mal
erfolgreich als Slave benutzt, um seinen internen Temperatursensor
auslesen zu lassen.

Code anbei.

[Peter D. (peda)]

Christian schrieb:
> Nach der ersten Stop-Condition zieht der
> AVR SDA gleich auf low. Auf dem Screenshot kann man das wunderbar
> erkennen (roter Kreis).

Also ich sehe da kein Stop. Das ist das ACK (9. Clock).
Und der Master macht ne längere Pause. Das darf er, im I2C gibt es keine 
Maximalzeiten.

[Christian (Gast)]

Es kann aber kein ACK sein, da sich SDA während der high Phase von SCK 
ändert. Ein ACK wäre ein low-Pegel über die gesamte Dauer einer 
Clock-Phase. Aber du hast recht es fehlt in der Tat das ACK/NACK. 
Offensichtlich spart sich der Controller dieses, warum auch immer, den 
EEPROM scheint es nicht zu interessieren, aber der ATMEGA ist damit 
überfordert. Ich schau mir das mal an. Da wird sich schon ein Workaround 
finden lassen.

Danke.