Sensoren blockieren I2C Bus

[Klebwax]

ich habe eine Frage zum I2C Bus.
Da ja viele Sensoren mit diesem Bus ausgestattet sind, habe ich hier gepostet.

.....

Jetzt kommt meine Frage:
Muss nach einer Stop Condition nicht der Bus generell vom Slave freigegeben werden ?
Und warum verhalten sich nur einige Chips derart und dann auch nur im Read Modus ?

Deine Beobachtungen sind völlig richtig. Hier ein paar Erklärungen. Im Write-Mode ist SDA immer (Ausnahme ACK) unter Kontrolle des Masters. Beim Read hat aber der Slave die Kontrolle über SDA. Da gibt es dann Situationen, bei denen der Master gar keinen Stop erzeugen kann, der Slave hält SDA auf low. Manchmal reicht es, solange Takte auf SCL auszugeben, bis SDA frei (high durch den Pullup) ist und dann einen STOP zu erzeugen. Spätestens nach 8 (9?) Takten ist das erreicht, die Übertragung eines Bytes abgeschlossen. Es ist also am einfachsten, immer 8 Takte zu erzeugen und dann einen STOP.

Wie kommt man in die Situation mit dem klemmenden Bus? Zuallerst beim Debuggen. Mitten in der Übertragung wird gestoppt, der Master resettet, bevor ein STOP erzeugt hat etc. Es ist also hilfreich, am Anfang der Initialisierung des I2C Controlers SCL 8 mal zu takten und dann ein STOP zu generieren.

Der nächste Fall ist eine Adresse mit READ ohne zu lesen. Manche Slaves übernehmen die Kontrolle über SDA beim READ gleich nach dem ACK. Wenn sie dann eine 0 liefern wollen, kann der Master kein STOP erzeugen und der Bus klemmt. Daher sollte man einen I2C Bus nur mit einem WRITE scannen.

Eine weitere Situation entsteht, wenn man das letzte Byte eines READS nicht mit einem NAK quitiert. Auch das bringt manche Slaves dazu, den Bus zu blockieren.

Die Fälle lassen sich aber in der Software leicht vermeiden.

MfG Klebwax

[Siro]

Hab erstmal vielen Dank für deine Informationen Klebwax

Okay, dann sind also meine Messungen richtig und das Verhalten ist tatsächlich etwas unterschiedliche bei den Chips.
Dann werde ich generell mit einem Write "scannen"

Beim Debuggen hab ich auch schon so einige Chips aus der Ruhe bringen können, ja das ist oft kritisch....

Eine weitere Situation entsteht, wenn man das letzte Byte eines READS nicht mit einem NAK quitiert. Auch das bringt manche Slaves dazu, den Bus zu blockieren.

Genau das ist mir schon passiert. Ich hatte ein EEPROM am Bus und das lief Jahrelang einwandfrei,
dann habe ich es ausgetauscht von einem anderen Hersteller und plötzlich lief es nicht mehr richtig.

Beim letzten Byte lesen hatte ich kein NACK gesendet und das "alte" EEPROM hatte damit kein Problem und hat sich anscheinend wieder
mit dem STOP synchronisiert. Das neue EEPROM jedoch wollte unbedingt ein NACK haben.

Siro