I2C Acknowledge fehlt / wird nicht erkannt

[Christoph H. (emblin_ch)]

Hallo zusammen,

beim Anschluss eines Sensors an ein bestehendes Sensor-System via I2C 
habe ich leider aktuell das Problem, dass ich nach Senden der 
slave-address kein Acknowledge vom Sensor (slave) bekomme, bzw. das ACK 
nicht erkannt wird.

Bevor ich weiter aushole mal eine grundlegende Frage zu dem 
Oszi-Screenshot den ich angehängt habe:

Während dem 9ten Takt hält der Slave SDA auf low, bei fallender Flanke 
lässt der Slave quasi zeitgleich wieder los und SDA zieht wieder auf 
high. Ich würde das definitiv als ACK interpretieren, die Decodierung 
meines Oszis interpretiert das allerdings als NAK und auch 
softwareseitig (ein anderer Sensor funktioniert bereits über I2C) wird 
das ACK nicht als solches erkannt...

Bin leider noch Einsteiger was I2C angeht, kann mir da jemand 
weiterhelfen? Ist das nun ein ACK und wenn ja, warum könnte es nicht als 
solches erkannt werden?

Vielen Dank und beste Grüße

[Marc V. (Firma: Vescomp) (logarithmus)]

Christoph H. schrieb:
> Bin leider noch Einsteiger was I2C angeht, kann mir da jemand
> weiterhelfen? Ist das nun ein ACK und wenn ja, warum könnte es nicht als
> solches erkannt werden?

 Ich lese das als 0b10110100 - und SDA wechselt während SCL high ist,
 ergibt für mich eine (etwas zweifelhafte) STOP condition.
 Vielleicht den Clock etwas runterschrauben ?

[Christoph H. (emblin_ch)]

Ok, kann man das noch als Wechsel von SDA "während" SCL auf high ist 
sehen? Die eigentliche STOP-condition, die ich aufgrund des nicht 
erhaltenen ACK sende, kommt dann ja erst am Schluss. Habe in einem 
Troubleshooting Guide von TI ein identisches Abbild eines ACK gefunden, 
das meinem entspricht und offensichtlich so sein soll.  Den Takt nach 
unten oder oben anzupassen hab ich schon probiert, das hat aber bisher 
nicht geholfen.

[Marc V. (Firma: Vescomp) (logarithmus)]

Christoph H. schrieb:
> Ok, kann man das noch als Wechsel von SDA "während" SCL auf high ist
> sehen? Die eigentliche STOP-condition, die ich aufgrund des nicht
> erhaltenen ACK sende, kommt dann ja erst am Schluss. Habe in einem
> Troubleshooting Guide von TI ein identisches Abbild eines ACK gefunden,
> das meinem entspricht und offensichtlich so sein soll.  Den Takt nach
> unten oder oben anzupassen hab ich schon probiert, das hat aber bisher
> nicht geholfen.

 Ich hab deinen Screenshot mal bearbeitet, so sollte es ( meiner Meinung
 nach ) aussehen.
 Das einzige, was mir dazu einfällt ist, dass der CLOCK zu schnell ist
 und wechselt bevor der Sensor SDA loslässt. Damit ist aber automatisch
 ein ungültiges ACK empfangen.

 EDIT:
 Nach der Sensoradresse ein bisschen länger warten (mit der STOP
 condition) könnte auch helfen.

[Christoph H. (emblin_ch)]

Marc V. schrieb:
>
>  Ich hab deinen Screenshot mal bearbeitet, so sollte es ( meiner Meinung
>  nach ) aussehen.
>  Das einzige, was mir dazu einfällt ist, dass der CLOCK zu schnell ist
>  und wechselt bevor der Sensor SDA loslässt. Damit ist aber automatisch
>  ein ungültiges ACK empfangen.
>

Danke schonmal, hab soetwas ähnliches vermutet. Der Slave scheint für 
das ACK also die Leitung auf low zu legen, aber zu früh wieder 
loszulassen. Scheint mir dann ein Timing-Problem zu sein, werde mal an 
ein paar Parametern drehen und sehen was passiert.

>  EDIT:
>  Nach der Sensoradresse ein bisschen länger warten (mit der STOP
>  condition) könnte auch helfen.

Die STOP Kondition hatte ich testweise auch schon einfach mal 
rausgenommen (danach soll letztendlich dann noch mehr auf der Leitung 
passieren), was leider auch nicht half.

Trotzdem vielen Dank schonmal, sobald ich am Montag wieder ein Oszi zur 
Hand hab werde ich mir die Timing-Parameter (SDA hold time, etc.) 
vorknöpfen.

Wenn noch jemand eine zündende Idee hat freue ich mich trotzdem ;)

[Clemens L. (c_l)]

Marc V. schrieb:
> Ich hab deinen Screenshot mal bearbeitet, so sollte es ( meiner Meinung
> nach ) aussehen.

Das ist nicht notwendig.

Bei Datenbits darf sich SDA nur während der Low-Phase von SCL ändern, 
und wird bei der steigenden Flanke von SCL gelesen.

Wenn der Master Daten sendet, dann kann er SDA in der Mitte der 
Low-Phase von SCL ändern.

Wenn der Slave Daten sendet (hier: das 0-Bit für ACK), dann kann er 
nicht genau vorhersagen, wann der Master seine Clock-Flanken sendet. 
Deshalb ändert er SDA sofort nach der fallenden Clock-Flanke.
In diesem Fall zieht der Slave SDA auf 0 sofort nach der fallenden 
Clock-Flanke des R/W-Bits, und lässt SDA los sofort nach der fallenden 
Clock-Flanke des ACK-Bits. Das ist beides korrekt, und das Oszi 
interpretiert dies anscheinend falsch.

Christoph, wie sieht denn das ACK einer funktionierenden Transaktion auf 
dem Oszi aus?

[Bernd K. (prof7bit)]

Das Oszillogramm in Post 1 ist vollkommen OK. Der Slave sendet ACK, 
genauso wie er soll, am Timing ist auch nichts auszusetzen. Der Fehler 
muss woanders liegen.

[Marc V. (Firma: Vescomp) (logarithmus)]

Bernd K. schrieb:
> Das Oszillogramm in Post 1 ist vollkommen OK. Der Slave sendet ACK,
> genauso wie er soll, am Timing ist auch nichts auszusetzen. Der Fehler
> muss woanders liegen.
Clemens L. schrieb:
> Das ist nicht notwendig.

 Wieso ist das Oszillogram für Euch beide OK ?
 Es wird weder von Programm noch von Oszi als richtig gesehen, Oszi hat
 das bestimmt aufgrund Timing so interpretiert und sein Programm macht
 das wahrscheinlich mit HW-Dekodierung, da muss ganz einfach SDA vor
 der fallenden Flanke von SCL gewechselt haben.

 Anbei ein Bild wie es aussehen soll.

Christoph H. schrieb:
> Ist das nun ein ACK und wenn ja, warum könnte es nicht als
> solches erkannt werden?

 Es ist kein ACK, dein uC guckt sich keine Screenshots an, sondern macht
 das in Hardware.
 Du kannst aber versuchen, es zu ignorieren und trotzdem Daten vom
 Sensor anfordern.
 Mal sehen was dabei rauskommt.

[Bernd K. (prof7bit)]

Marc V. schrieb:
> Es ist kein ACK

Doch, das ist ein sauberes ACK. Wie aus dem Bilderbuch.

Ich vermute einen Fehler in der Software seines Masters (falsche 
Benutzung der I²C-Hardware, falsche Interpretation ihrer Status-Bits) 
und wenn der Decoder im Oszi das nicht als ACK erkennt dann vermute ich 
eine Fehlbedienung des Oszi.

[Clemens L. (c_l)]

Marc V. schrieb:
> da muss ganz einfach SDA vor der fallenden Flanke von SCL
> gewechselt haben.

Ich bezweifle, dass der Slave das zufälligerweise wenige Nanosekunden 
vor der fallenden Flanke gemacht hat.

Aber wahrscheinlich ist das Problem eh woanders.

[Marc V. (Firma: Vescomp) (logarithmus)]

Bernd K. schrieb:
> Doch, das ist ein sauberes ACK. Wie aus dem Bilderbuch.

 Sicher, du brauchst nur noch sein Oszi und seinen uC davon zu
 überzeugen.

> Ich vermute einen Fehler in der Software seines Masters (falsche
> Benutzung der I²C-Hardware, falsche Interpretation ihrer Status-Bits)
> und wenn der Decoder im Oszi das nicht als ACK erkennt dann vermute ich
> eine Fehlbedienung des Oszi.

 Ja, alle haben einen Fehler, ausser dir.
 Troll dich irgendwo anders rum.

Clemens L. schrieb:
> Ich bezweifle, dass der Slave das zufälligerweise wenige Nanosekunden
> vor der fallenden Flanke gemacht hat.

 Ih würde es auch bezweifeln, aber dass uC und Oszi das als kein ACK
 interpretieren, überzeugt mich vom Gegenteil.
 Vor allem, da der TO sagt, dass ein anderer Sensor einwandfrei am
 selben Bus funktioniert.

[Clemens L. (c_l)]

Marc V. schrieb:
> dass uC und Oszi das als kein ACK interpretieren, überzeugt mich vom
> Gegenteil.

Dann müsste es aber nicht als NACK, sondern als STOP interpretiert 
werden.

[Christoph H. (emblin_ch)]

Clemens L. schrieb:
>Christoph, wie sieht denn das ACK einer funktionierenden Transaktion auf
>dem Oszi aus?

Ich habe das Oszi erst morgen wieder zur Hand, dann werde ich das mal 
überprüfen. Meine aber im Gedächtnis zu haben, dass bei der 
funktionierenden Kommunikation mit dem anderen Sensor die SDA länger auf 
low liegt.

Marc Vesely schrieb:
>Es ist kein ACK, dein uC guckt sich keine Screenshots an, sondern macht
>das in Hardware.
>Du kannst aber versuchen, es zu ignorieren und trotzdem Daten vom
>Sensor anfordern.

Das habe ich bereits erfolglos getestet (beim Auslesenversuch eins 
Status-Registers erhielt ich dann einen unerwünschten Wert 0xff). Werde 
diesen Ansatz aber trotzdem morgen nochmal überprüfen.

Bernd K. schrieb:
>Ich vermute einen Fehler in der Software seines Masters (falsche
>Benutzung der I²C-Hardware, falsche Interpretation ihrer Status-Bits)
>und wenn der Decoder im Oszi das nicht als ACK erkennt dann vermute ich
>eine Fehlbedienung des Oszi.

Die I2C Übertragung eines anderen Sensors funktioniert mit der Software 
einwandfrei. Am Controller (Freescale Kinetis KL) lassen sich beim 
Debuggen die relevanten Status-Register ja auslesen --> Das 'Receive ACK 
Bit' springt auf 'no acknowledge signal detected'.
Eine Fehlbedienung des Oszi mit I2C-Trigger wäre ich geneigt 
auszuschließen. Das sowohl Oszi als auch uC das nicht als ACK sehen 
finde ich schon verdächtig.

Clemens L. schrieb:
>Ich bezweifle, dass der Slave das zufälligerweise wenige Nanosekunden
>vor der fallenden Flanke gemacht hat.
>
>Aber wahrscheinlich ist das Problem eh woanders.

Kann es so sein, dass SDA nun doch nicht sofort nach der fallenden SCL 
Flanke auf high zieht, sondern zufälligerweise doch schon kurz vorher? 
Ich werde versuchen, das mit einer neuen Messung zeitlich besser 
aufzulösen.

[Bernd K. (prof7bit)]

Marc V. schrieb:
>> Ich vermute einen Fehler in der Software seines Masters (falsche
>> Benutzung der I²C-Hardware, falsche Interpretation ihrer Status-Bits)
>> und wenn der Decoder im Oszi das nicht als ACK erkennt dann vermute ich
>> eine Fehlbedienung des Oszi.
>
>  Ja, alle haben einen Fehler, ausser dir.
>  Troll dich irgendwo anders rum.

Bullshit. Der OP hat offensichtlich irgendwo einen Fehler gemacht sonst 
würde es funktionieren und er würde nicht hier fragen müssen. Jedoch ist 
im geposteten Bild auch beim besten Willen nicht der leiseste Hauch 
eines Hinweises auf fehlerhaftes Signal oder fehlerhaftes Timing 
herauszulesen, das einzige was zu bemängeln wäre wäre daß er den Rand 
abgeschnitten hat so daß man weder Zeit noch Pegel noch Nulllinie sehen 
kann.

Wenn das Bild also zu seinem Signal gehört um das es hier geht und die 
Pegel stimmen dann hätte sein Oszi bei korrekter Verwendung das ACK 
erkennen müssen.

Wenn er jedoch den falschen Screenshot gepostet oder das falsche Signal 
gemessen hat dann ist die Diskussion eh überflüssig.

Wenn sein Oszi angeblich das nicht dekodieren kann soll er mal den 
Screenshot davon (vom Nichterkennen) schicken ohne vorher die Ränder 
abzuschneiden. Solange das nicht geschieht unterstelle ich dem 
Fragesteller daß er irgendwas falsch gemacht hat und darüberhinaus 
unterstelle ich dem Hersteller dieses Sensors daß dieser 
höchstwahrscheinlich einwandfrei funktioniert.

Wie Du darauf kommst der I²C-Stack im Sensor sei fehlerhaft (ohne 
erkennbare Hinweise darauf) und der OP habe alles richtig gemacht 
(ebenfalls ohne Nachweis) bleibt für uns alle hier schleierhaft.

[Dennis X. (Gast)]

Bernd K. schrieb:
> Doch, das ist ein sauberes ACK. Wie aus dem Bilderbuch.

Das dachte ich mir ganz am Anfang auch. Ist etwas verwirrend mit dem 
Titel. Das ACK ist hier nicht das Problem.

@TO: Mach bitte mal ein paar Angaben zur Hardware. Wer ist Master, 
welcher Slave. Taktgeschwindigkeit, Versorgungsspannung und Pull-Ups. 
Hatte sowas ähnliches mit dem Start mal gehabt.

[Bernd K. (prof7bit)]

Christoph H. schrieb:
> Eine Fehlbedienung des Oszi mit I2C-Trigger wäre ich geneigt
> auszuschließen. Das sowohl Oszi als auch uC das nicht als ACK sehen
> finde ich schon verdächtig.

Dann hast Du den falschen Screenshot gepostet, denn der den Du gepostet 
hast zeigt einen vollkommen korrekten Verlauf mit korrektem Timing (mit 
Ausnahme der Pegel, die kann man nicht beurteilen weil Du in dem Bild 
die Ränder mit den Achsenbeschriftungen abgeschnitten hast).

[Marc V. (Firma: Vescomp) (logarithmus)]

Clemens L. schrieb:
> Dann müsste es aber nicht als NACK, sondern als STOP interpretiert
> werden.

 Ich habe schon gestern geschrieben, dass dies wahrscheinlich als
 STOP interpretiert wird.

Bernd K. schrieb:
> Wie Du darauf kommst der I²C-Stack im Sensor sei fehlerhaft (ohne
> erkennbare Hinweise darauf) und der OP habe alles richtig gemacht

 Ich habe weder geschrieben, dass der "I²C-Stack im Sensor fehlerhaft
 sei", noch hat der OP da etwas richtig oder falsch gemacht - sowohl
 der Oszi als auch der uC weigern sich, das als ACK anzuerkennen.

> (ebenfalls ohne Nachweis) bleibt für uns alle hier schleierhaft.

 Und warum du da für alle sprichst, ist mir erst recht schleierhaft.

 Da du anscheinend nicht mal die Grundkenntnisse von I2C besitzst,
 hier nochmal ganz kurz:

 Ein bit wird beim I2C erst nach der fallenden Flanke von SCL als
 gültig betrachtet. Das gilt auch für ACK bzw. NACK.
 Solange SCL High ist, werden nur START und STOP erkannt und es
 wird dementsprechend dekodiert.

 Hätte der Sensor bis zur fallenden Flanke von SCL gewartet und
 erst dann SDA losgelassen, wäre das auch als ACK dekodiert.
 Der Sensor muss aber die SDA vor der fallenden Flanke von SCL
 losgelassen haben, somit wird das als STOP interpretiert, was ja
 noch keinen Fehler darstellt, aber damit wird automatisch ACK als
 nicht abgeschlossen und somit ungültig dekodiert.

 Ich hoffe, dass du nach dieser Erklärung (sowie nach fleissigem
 lesen von Fachliteratur über funktionsweise der I2C) etwas klarer
 siehst.

[Bernd K. (prof7bit)]

Marc V. schrieb:
> Da du anscheinend nicht mal die Grundkenntnisse von I2C besitzst,
>  hier nochmal ganz kurz:

Schreibt der der mir was über I²C erzählen will, ich lach mich schlapp. 
Du solltest nicht so dicke Nägel reinhauen, insbesondere da DU es bist 
dem hier jegliche Kenntnisse zu fehlen scheinen.

> Hätte der Sensor bis zur fallenden Flanke von SCL gewartet

Das hat er wenn Du mal die Brille aufsetzen möchtest. Schon wieder 
behauptest Du der Sensor sei defekt. Das ist er aber nicht. An dem ACK 
ist nichts auszusetzen wie man deutlich sehen kann.

Ich behaupte stattdessen der Threaderöffner hat irgendwo anders einen 
Fehler gemacht (über den man mangels geposteter Information nur 
spekulieren kann), sonst wäre er nicht wie er selbst offen zugibt ein 
Neuling in Sachen I²C und es würde stattdessen funktionieren.

[Dennis X. (Gast)]

Bernd K. schrieb:
> Ich behaupte stattdessen der Threaderöffner hat irgendwo einen Fehler
> gemacht, sonst wäre er nicht wie er selbst offen zugibt ein Neuling in
> Sachen I²C.

Und dazu bitte vor jedem weiteren Beitrag mal kurz ein Stand zur 
Hardware. JA okay, irgendwas passt da nicht. Sieht komisch aus, 
funktioniert nicht... Wie auch immer.

[Marc V. (Firma: Vescomp) (logarithmus)]

Bernd K. schrieb:
>> Hätte der Sensor bis zur fallenden Flanke von SCL gewartet
>
> Das hat er wenn Du mal die Brille aufsetzen möchtest. Schon wieder
> behauptest Du der Sensor sei defekt. Das ist er aber nicht.

 Ich behaupte gar nichts, ich versuche nur eine logische Ursache für
 solche Meldungen zu finden.
 Wie schon weiter oben empfohlen, sich erstmal über I2C informieren,
 entsprechende Fachliteratur durchlesen, versuchen zu verstehen wie
 das alles überhaupt funktioniert und erst dann wiederkommen -
 schätze, du wirst nicht mehr als 5 Jahre dafür brauchen.

> An dem ACK ist nichts auszusetzen wie man deutlich sehen kann.

 So deutlich sehe ich das natürlich nicht, bin aber natürlich auf
 deine Erklärung gespannt. Woran siehst du das so deutlich ?

[Christoph H. (emblin_ch)]

Bernd K. schrieb:
> Wenn sein Oszi angeblich das nicht dekodieren kann soll er mal den
> Screenshot davon (vom Nichterkennen) schicken ohne vorher die Ränder
> abzuschneiden.

Das etwas in die Jahre gekommene Oszi bietet mir leider keine andere 
Speichermöglichkeit, abgeschnitten habe ich da nix. Das ist bei dem Ding 
leider nicht anders möglich.

Wie auch immer, das ACK wird mitlerweile vom Oszi als solches erkannt. 
Bevor jemand meint loslegen zu müssen: Durchatmen, shit happens, 
weiterlesen. Anbei mal die markante Stelle zeitlich aufgelöst. Ein 
sauberes ACK, aber mit ca. 500 ns nach der fallenden SCL-Flanke aus 
nachfolgenden Gründen kritisch.

Bernd K. schrieb:
> Solange das nicht geschieht unterstelle ich dem
> Fragesteller daß er irgendwas falsch gemacht hat und darüberhinaus
> unterstelle ich dem Hersteller dieses Sensors daß dieser
> höchstwahrscheinlich einwandfrei funktioniert.

Ich betone und belege gerne, dass hier softwareseitig alles einwandfrei 
ist und bisher an anderer Stelle wunderbar funktioniert.

Problem solved --> Der Sensor ist lt. Datenblatt für eine 
Übertragungsrate von 10-400 kHz spezifiziert. Ich arbeite mit einem 
Low-Power-Controller bei ca. 20 kHz, der die vergleichsweise kurze hold 
time von 500 ns bisher nicht mitgemacht hat. Der Sensor ist ein Sample, 
wette die haben den bei so niedrigen Frequenzen garnicht getestet. 
Frequenz nach oben korrigieren hilft tatsächlich. Das habe ich zwar am 
Wochenende schon probiert, bin beim Debuggen aber immer wieder aufs 
gleiche gekommen.

--> Während des Debuggen funktioniert es also nicht, muss mal 
recherchieren inwiefern der Debugger auf den bus clock des uC Einfluss 
nimmt.
--> im 'Normalbetrieb' kann ich am Oszi eindeutig ablesen, dass die 
Kommunikation jetzt läuft. Da am Wochenende kein Oszi zur Hand war, 
konnte ich das erst heute feststellen.

Erstmal Dank für die Anreize. Hoffe die Gemüter beruhigen sich hier mal 
etwas, bin hier um sachlich zu diskutieren. Da Helfen solche Sticheleien 
nicht weiter...