TWI liefert bei Adressierung NACK

[Bucki E. (buckied)]

Hallo liebe Forengemeinde,

ich habe leider ein kleines Problem den I2C-Bus bzw. das TWI des 
Atmega32U4 in Betrieb zu nehmen. Ich habe bisher alles Standardmäßig 
geschrieben und nutze zur Auswertung zusätzlich noch einen TTL/Seriell 
Wandler um mir den Zwischenstatus anzeigen zu lassen.

Mein Problem ist nun, dass die TWI nur beim Power Up der kompletten 
Schaltung bei der Adressierung ein ACK des Slaves bringt. Sobald ich 
aber (momentan wird der Slave einfach periodisch angesprochen um die 
Adressierung erstmal richtig zu bekommen) den Slave erneut anspreche, 
also direkt ab Abfrage Nr. 2 liefert er nur noch ein NACK. Kann mir 
eventuell Jemand sagen an was das liegen könnte? Oder ist das sogar 
normal so, wenn man dem Slave keinen Befehl schickt?

Noch kurz zur Info: uC ist ein Atmega32U4 (Arduino Micro, schreibe aber 
"normal" in Atmel Studio ohne die Arduino IDE), Slave ist der SL030 RFID 
Card Reader mit Standard-Adresse 1010000b und ich führe einfach 
periodisch den I2C Start aus (also Start --> Adressierung + SLA+W ACK 
erhalten? -->weiter bis return 0 --> direkt I2C Stopp ohne weitere 
Befehle zu schicken) und stoppe die Kommunikation direkt danach wieder.

Ich hoffe das hat das Problem gut genug umschrieben.


Grüße,
BuckiED

[TK (Gast)]

Hallo,
ich habe selbst noch nie mit TWI gearbeitet - daher erst mal die Frage 
nach einem Oszi Bild vom IIC-Bus für den GUT- und den SCHLECHT-Fall. 
Damit kann man bestimmt erkennen, woran es liegen könnte.
Weiterhin mögen manche Bausteine keine "leeren" Abfragen mit START-STOP 
Kombination, oder in Deinem Fall kann es sein, dass der Baustein auf 
eine Anfrage mit Schreibzugriff auch einen weiteren Datenwert erwartet?
Es hängt doch nicht etwa noch ein IIC Slave am Bus (z.B. ein EEPROM wg 
der Device-Address von 0xA0)?

Gruß
TK

[Bucki E. (buckied)]

Ich habe mal zwei Bilder beigefügt. Bild 1 zeigt die erfolgreiche 
Kommunikation mit Bestätigung durch ACK und Bild 2 zeigt die 
"Dauerschleife" der NACK's nach dem Power Up und dem ersten 
erfolgreichen Adressieren.

Das befürchte ich momentan auch, obwohl ich es mir nicht erklären kann. 
Nach einem klaren Stopp müsste man den Baustein doch wieder ganz normal 
adressieren können oder nicht?

Sonst hängt nichts weiter am Bus, nur der Atmega und der SL030.

Grüße
BuckiED

[Wolfgang (Gast)]

Bucki E. schrieb:
> Ich habe mal zwei Bilder beigefügt.

Kläre vielleicht erstmal, wieso dein SDA-Pegel so durch die Gegend 
driftet.

[Bucki E. (buckied)]

Das lag nur an der Oszi Einstellung, irgendwie hat mein Tastkopf bei x10 
nen Klatsch... habs nun auf 1x gestellt und ein sauberes Signal 
bekommen. Jedoch bin ich bei meinem eigentlichen Problem noch nicht 
wirklich weiter. :/

[N2 (Gast)]

Hi,

I2C kann schon gemein sein:

* Es gibt Softwareimplementierungen auf uC, die machen, was sie wollen. 
Der beste Kanidat war mal ein Touch I2C Slave Controller (eigentlich nur 
ein AVR mit Firmware I2C per Bit Banging), der hat auch geantwortet auf 
seine Adresse, wenn die im Datenstrom vorkam, obwohl er gar nicht das 
adressierte Device war :-)

* Es gibt nicht standardkonforme Hardwareimplementierungen, wie bei dem 
Master, wo Clock Stretching mal halt nicht implementiert war oder wo 
sich die State Machine des Slave eben nicht (warum auch immer) über ein 
STOP zurücksetzt

* Und es gibt natürlich auch die standartkonformen Teile, bei denen 
alles implementiert ist und auch funktioniert

Aber momentan würde ich sagen, dem SL030 geht es nicht so gut, da ich 
vermute, Du versorgst das Teil vom Atmega mit 5V (Deine IO Spannung ist 
ja 5V) ? Oder hast Du einen 3V3 LDO ?
Der SL030 hat zwar 5V tolerante IOs, aber die Versorgung darf nicht mehr 
als 3,6V sein.

Ansonsten gibt der State Machine? im SL030 nach dem Stopp mal noch 10 
Clock Zyklen zu tun (also SDA auf High und SCL 10 mal takten). Danach 
sollte sich die State Machine? wieder einkriegen.

Gruß N2

[TK (Gast)]

Hallo,
zuerst mal ist der Hinweis mit den 3V3 schon mal gut. Daher sollten die
Pull-Ups auf die 3V3 Seite um dann den SL030 auch mit 3V3 Pegeln 
anzusteuern.
Wenn TWI sauber in Hardware implementiert ist, dann wird auch nur ein 
"open Drain" angesteuert - aber der Atmel könnte Probleme mit 3V3 am SDA 
während des Einlesens bekommen (andere Baustelle).

Aber ich vermute mal, dass der SL030 keine leere Anweisung mag. Im 
Datenblatt steht auch was drin, dass er ein NACK ausgibt, während 
STATE-BUSY. Ich kenne selbst Sensoren, die mir für exakt 1s ein NACK 
gegeben haben, weil sie interne Wandlungen ausgeführt haben (hat lange 
gedauert, bis ich darauf gekommen bin) - egal, versuch doch mal eine 
vollständige Anweisung zu senden (also mit LEN und COMMAND)

Ansonsten sieht die Übertragung auf den 1.Blick gut aus.

Gruß
TK

[Bucki E. (buckied)]

Danke für eure Antworten!

Leider hat sich wenig getan. :/ Nun habe ich "erfolgreich" das Senden 
der Länge+Befehl erledigt, jedoch wieder nur im ersten Durchgang. Ich 
bekomme jedes mal ein ACK, sobald ich aber in der Master Receiver Mode 
wechseln möchte und nach einer repeated Start Condition das Read-Bit 
anhänge bekomme ich direkt ein NACK vom Sensor.. ich weis nicht so recht 
wie ich weitermachen soll...

Grüße,
BuckiED

[Curby23523 N. (Gast)]

Im Datenblatt zum SL030 steht aber nichts von einem RepeatStart. Siehe 
Seite 7.

Dort steht entweder man schreibt oder man liest. Und immer schön einen 
Stop erzeugen. So verstehe ich es. Das Wort "repeat" kommt nicht einmal 
im Datenblatt vor.

[Bucki E. (buckied)]

Da hast du recht, das ist vor allem etwas was mich verwundert. Aber ist 
es für den Atmega nicht notwendig den Modus zu wechseln, damit er dem 
Slave die Kontrolle über den Bus überlässt?
Es ist ja nicht möglich nur SLA+R zu schicken und darauf Length+Command 
zu schreiben, da der Master in dem Modus ja nichts außer ein ACK auf den 
Bus geben kann oder missverstehe ich da etwas grundlegend?

Grüße,
BuckiED

[Jim Beam (Gast)]

Mag der vielleicht keinen REPEATED-START?
Mal mit regulärem STOP + NEUEM-START versuchen?

Und hast Du das ganze auch mal mit ultra-niedriger Clockrate probiert,
um Timing-Überforderung des Slave auszuschliessen?

[Curby23523 N. (Gast)]

Bucki E. schrieb:
> Da hast du recht, das ist vor allem etwas was mich verwundert. Aber ist
> es für den Atmega nicht notwendig den Modus zu wechseln, damit er dem
> Slave die Kontrolle über den Bus überlässt?

DU bist der Master. DU gibts die CLk aus ;). Immer.
Der Slave sendet höchzstens Daten auf SDA, aber DU machst die Clock.

Modus? Was für ein Modus? Du beendest deinen Schreibvorgang und danach 
kannst du z.B. einen Lesevorgang durchführen. Es gibt da keinen "Modus". 
Siehe Seite 7 vom Datenblatt.

Ich vermute dir fehlen noch ein paar Grundlagen vom I²C.

[Bucki E. (buckied)]

Okay, ich habs jetzt mal in die Richtung probiert und da kommt sogar was 
an, jetzt ist wohl glaube ich noch mein Problem, dass ich nicht weiß, 
wie ich als Master einen ACK nach auslesen des Registers liefern kann. 
Könnt ihr mir dahingehend noch weiterhelfen? :)
(Momentan kommt eben nach jedem "auslesen" das gleiche an, da ich ja 
noch kein ACK geschickt habe, verstehe ich das richtig?)

Ist das auslesen denn überhaupt richtig geschrieben?

unsigned char I2C_Daten_Lesen(void)
{
  TWCR = (1<<TWINT)|(1<<TWEN);
  while(!(TWCR&(1<<TWINT)));
  return TWDR;
}

Grüße,
BuckiED

[Bucki E. (buckied)]

Da liegst du leider richtig Curby, ich mache das erste mal was mit I2C 
(was natürlich nichts rechtfertigen soll). Aber laut ATmega Datenblatt 
hatte ich es eben so verstanden, dass man nach dem Transmitter Mode (wo 
man eben Befehle verschicken kann) in den Receiver Mode wechseln muss, 
aber da lag ich ja anscheinend falsch.

Grüße,
BuckiED