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.
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.
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.
Eine eigene Frage?
Dieser Thread ist über 12 Jahre alt.
Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.
