Hallo, ich bin gerade dabei etwas mit I2C zu machen und habe etwas Probleme. Die Software verhält sich sehr merkwürdig, spruckt irgendwelche Fehler aus wie "Arbitartion lost" und "Controller timed out". Als ich mir mit nem Logick Analyzer das Signal angesehen habe, stellt ich fest, dass einen Moment (einige Abfragen) bevor alles gegen die Wand fährt Fehler im I2C-Protokoll zu sein scheinen. Ich habe zwei Bilder angehängt, Ack.png beschreibt den Fall wie der Befehl, der an den Slave gesendet wird aussehen sollte. Nack zeigt den Fall, wenn der Slave die Anfrage mit einem Nack ablehnt, was sein gutes Recht ist. Jedoch folgt danach kein Stop und der nächste Start wird - zumindest von PulseView - als Repeated Start interpretiert. Zählt man die Takte in beiden Fällen, fällt auf, dass im Falle des Nack einer weniger ist. Auch interessant ist: Ist alles abgeschmiert und nichts passiert mehr und ich ziehe die CLK Leitung einmal manuell auf low geht alles weiter als wäre nichts gewesen. Sprich irgendwem - ich vermute fast dem Host - fehlt ein Takt, um weiter zu machen. Aber wieso fehlt dem ein Takt, der erzeugt die doch selbst??? Hat irgendjemand eine Idee woher das kommen kann? Bei dem Host handelt es sich um einen ARM DM3730 mit Linux, der Slave ist ein Touch-Controller. Ich würge direkt im Kernel an einem Treiber dafür rum. MfG
Wenn ich mich nicht verzählt habe, liegt der Fehler nciht am Slave, dass der ein NAK sendet: er kriegt erst gar keine Gelegenheit dazu, weil, wie du richtig erkannt hast, der 9te Clock fehlt. ich kann mich aber täuschen...
Öhh also die Steigende Flanke des CLK für den NACK ist ja noch da und der Slave lässt ja auch die Datenleitung los wodurch ein NACK erkannt wird. Wenn man die beiden Signale vergleicht unterscheiden sie sich das erste mal dort, wo der Slave die Datenleitung nicht auf low zieht, wie es sein sollte. Das löst ein NACK aus. Ich habe inzwischen herausgefunden, dass es am ARM Prozessor/Linux liegt, dass darauf kein STOP kommt. Es gibt zahlreiche Bugfixes dafür im Netz, jedoch funktioniert das bei mir irgendwie alles nicht.
Jürgen schrieb: > Öhh also die Steigende Flanke des CLK für den NACK ist ja noch da und > der Slave lässt ja auch die Datenleitung los wodurch ein NACK erkannt > wird. Wenn man die beiden Signale vergleicht unterscheiden sie sich das > erste mal dort, wo der Slave die Datenleitung nicht auf low zieht, wie > es sein sollte. Das löst ein NACK aus. Du hast recht, sorry, ich hab mich verzählt.
Joa denke das Thema hat sich erledigt... liegt wohl an der (schlechten) Hardware... Vielen Dank!
Jürgen schrieb: > liegt wohl an der (schlechten) > Hardware... Trotzdem liegt ein Fehler in der Master-Lib vor, nach jedem NACK muß ein STOP gesendet werden! Und als Master-Receiver darf sogar nur nach einem NACK ein STOP gesendet werden.
Das ist, soweit ich das gelesen habe nicht richtig. Nach einem Nack kann auch ein Repeated Start kommen. Und in Linux ist das in der API vorgesehen, daher wird ein Stop nach einem Nack nicht automatisch gesendet.
Jürgen schrieb: > Nach einem Nack kann auch ein Repeated Start kommen. Das wiederum ist richtig :-) Der Unterschied zwischen einem START und einem REPEATED START ist ja eben, dass vor dem REPEATED START kein STOP vom Master kommt, er also den Bus nicht freigibt.
Jürgen schrieb: > Das ist, soweit ich das gelesen habe nicht richtig. Nach einem Nack kann > auch ein Repeated Start kommen. Das wird von den meisten Slaves toleriert, entspricht aber nicht der original I2C Spezifikation von Philips. Eine Repeat Start ist nur erlaubt, um die Datenrichtung umzuschalten, z.B. bei eine EEPROM von Setzen der Adresse auf Lesen. Natürlich erfolgt dann das Repeat Start immer auf ein ACK. In den Philips Dokumenten wirst Du kein Repeat Start auf NACK finden. Nach NACK wird immer ein STOP gefordert. Z.B. nach dem EEPROM-Schreiben für das Busy-Polling.
:
Bearbeitet durch User
Peter Dannegger schrieb: > In den Philips Dokumenten wirst Du kein Repeat Start auf NACK finden. Zitat aus http://www.nxp.com/documents/user_manual/UM10204.pdf (I²C-bus Specification, Rev. 6 — 4 April 2014 ich denke das ist die I²C-Referenz) When SDA remains HIGH during this ninth clock pulse, this is defined as the Not Acknowledge signal. The master can then generate either a STOP condition to abort the transfer, or a repeated START condition to start a new transfer.
Michael Reinelt schrieb: > Peter Dannegger schrieb: >> In den Philips Dokumenten wirst Du kein Repeat Start auf NACK finden. > > Zitat aus http://www.nxp.com/documents/user_manual/UM10204.pdf (I²C-bus > Specification, Rev. 6 — 4 April 2014 ich denke das ist *die* > I²C-Referenz) > > When SDA remains HIGH during this ninth clock pulse, this is defined as > the Not Acknowledge signal. The master can then generate either a STOP > condition to abort the transfer, or a repeated START condition to start > a new transfer. Das steht bereits auch in der Version 2.1 vom Januar 2000. Ist also keineswegs neu. Ältere Version liegen mir nicht vor. Die SMBUS Spezifikation 2.0 unterscheidet übrigens sich in diesem Punkt: A repeated START is a START condition on the SMBus used to switch from write mode to read mode in a combined format protocol (e.g. Byte Read). The repeated START always follows an Acknowledge, and it always indicates that an address phase is beginning. D.h. bei SMBUS ist repeated START auf Peters Scenario eingeschränkt.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.