I2C unvollständige Datenübertragung

[Antje W. (antje_w)]

Hallo :)

Ich versuche derzeit einen Beschleunigungssensor (FXOS8700CQ) via I2C 
auszulesen (Mikrocontroller: FRDM KL25Z Entwicklungsboard). Das Ganze 
funktioniert im Prinzip auch ganz gut, allerdings hat der Sensor wohl 
Probleme mit der Datenausgabe, denn er schafft es innerhalb der 
Datenübertragung manchmal nicht, die Acknowledge zu senden. Der Pegel 
auf den Leitungen bleibt dann zwischen 2 unvollständigen Übertragungen 
auf low.

Am Code kann es eigentlich nicht liegen, da andere I2C-Komponenten damit 
einwandfrei funktionieren. Das Problem tritt auch nicht nur bei einem 
Sensor, sondern gleich dreien auf.

Anbei ein Screen vom Oszi (gelb - Takt , blau - Daten)

Hat zufällig schon jemand so ein Problem gehabt?

Gruß, Antje

[Stefan F. (Gast)]

> Der Pegel auf den Leitungen bleibt dann zwischen 2 unvollständigen
> Übertragungen auf low.

Acknowledge=Low !

Warum bleibt die Taktleitung auf Low hängen, obwohl die Datenleitung auf 
Low steht, also ein Acknowledge zeigt?

Irgendjemand hält die Taktleitung "fest". Finde heraus, ob der Master 
oder der Slave dafür verantwortlich ist. Wenn du kleine Widerstaände 
(z.B. 100 Ohm) in Reihe zu SCL und SDA schaltest, kannst du am 
Spannungsabfall erkennen, welche Seite die Leitungen auf Low zieht.

[Antje W. (antje_w)]

Die Acknowledge ist doch nur dann wenn der Slave im 9. Bit die 
Datenleitung für einen Takt auf logic low zieht.

Das ist wahrscheinlich der springende Punkt ... irgendwer hält da die 
Leitungen fest ....

Danke für den Tipp, ich werd direkt mal, 100 Ohm in die SCL und SDA 
Leitungen einbringen und dann die Oszibilder zeigen.

[Antje W. (antje_w)]

Ich hab jetzt einfach in die Takt- und Datenleitung Widerstände 
eingebracht und einmal vor und hinter dem Widerstand die Spannung 
gemessen -> kein Unterschied

----o--------o---- 3.3V
    |        |
   | |4.7k  | |4.7k
   | |      | |
    |        |     _ _
----o--------|----|_ _|----SCL
             |     _ _ 
-------------o----|_ _|----SDA
                   100

Ich vermute aber, da ja auch der Takt fest ist, ist der uC schuld an dem 
Debakel.


--
"ASCII-Art" bitte in [ pre ] [ /pre ] -Tags einschließen.

-rufus

[Rufus Τ. F. (rufus)]

Antje W. schrieb:
> Ich vermute aber, da ja auch der Takt fest ist, ist der uC schuld an dem
> Debakel.

Muss er nicht sein, rein theoretisch kann auch ein I2C-Slave die 
Taktleitung auf low halten, das heißt dann "clock stretching".

[Stefan F. (Gast)]

An deinem Oszilloskop Bild kann ich nicht erkennen, auf welcher Seite 
der Widerstände die Spannung höher ist.

[Antje W. (antje_w)]

Ich leider auch nicht :/

[Matthias S. (Firma: matzetronics) (mschoeldgen)]

Die Nadelimpulse, die da zwischendurch zu sehen sind, erscheinen mir 
nicht koscher. Es sieht im ersten Oszillogramm so aus, als wäre der 9. 
CLK Puls des Masters sehr kurz - zu kurz für ein sauberes ACK des 
Slaves.
CLK nicht erkannt - Slave legt ACK auf den Bus bis zum St. 
Nimmerleinstag.
Versuchsweise könntest du die I²C Rate mal senken.

[Antje W. (antje_w)]

Die I2C-Rate liegt bereits bei 100Hz (also dem slow mode)

Wenn ich weniger als die Koordinaten einzeln auslese also nur 2 Byte 
anstelle von 6, dann funktioniert die Datenübertragung an sich schon ... 
der Sensor gibt dann aber egal bei welchem Register ich beginne immer 
das gleiche aus.
Möglicherweise liegt der Fehler ja im Autoinkrement des Sensors.

Registeraufbau des Sensors
0x00 Status
0x01 X MSB
0x02 X LSB
0x03 Y MSB
0x04 Y LSB
0x05 Z MSB
0x06 Z LSB

Ich hab jetzt nochmal jeweils 5 Register in folge ausgelesen. Bild 1 
zeigt den Start bei 0x00, Bild 2 bei 0x01 ... also für mich sieht das 
identisch aus.

[Klaus (Gast)]

Antje W. schrieb:
> also für mich sieht das identisch aus.

Ich kann bei dieser Einstellung der Zeitbasis eher garnichts sehen. Auf 
SDA deutet sich ein kräftiger Crosstalk von SCL an. Um da aber wirklich 
etwas zu erkennen, ist aber die Abtastung zu grob.

Matthias Sch. schrieb:
> Es sieht im ersten Oszillogramm so aus, als wäre der 9.
> CLK Puls des Masters sehr kurz - zu kurz für ein sauberes ACK des
> Slaves.

Auch das kann man nur ahnen, wäre aber mit einem kleinen Dreh am 
Horizontalknopf leicht zu ändern.

Bevor man die HW nicht wirklich verifiziert hat, ist es müßig, in der SW 
rumzustochern.

MfG Klaus

[asdf (Gast)]

Rufus Τ. Firefly schrieb:
> Muss er nicht sein, rein theoretisch kann auch ein I2C-Slave die
> Taktleitung auf low halten, das heißt dann "clock stretching".

Kann man in diesem Fall wohl ausschließen, das Datenblatt sagt:

"This part does not use clock stretching."

[Antje W. (antje_w)]

"Die I2C-Rate liegt bereits bei 100Hz (also dem slow mode)"

Ich meinte natürlich 100kHz

Wenn ich das richtig sehe, dann ist der Ack-Zyklus nicht vollständig 
durchgeführt.

Für ein Ack muss der Slave während des 9. Taktes (SCL high) die 
Datenleitung auf low ziehen und dann muss SCL wieder auf low gehen damit 
der Slave das Datensignal freigeben kann ... genau diese Freigabe von 
SDA geschieht nicht. Da SDA nicht frei gegeben wird kann der MCU/Master 
SCL nicht wieder auf high setzen (Daten empfangen, Stop-Bedingung 
senden)

Ich frage mich nur, warum meine Sensoren das erst ab 6 bzw 7 bytes 
(beginnend von 0x00) machen

[Antje W. (antje_w)]

Ich hab den Fehler jetzt beheben können. Es lag daran, dass meine 
SCL-Frequenz offenbar zu niedrig war (~93kHz) bei ca. der doppelten 
Frequenz (~187kHz) sind 7 Byte kein Problem mehr

Ich finde es erstaunlich, dass es offenbare auch zu niedrige Frequenzen 
für einige I2C-Komponenten gibt.

[Cyblord -. (cyblord)]

Antje W. schrieb:
> Ich hab den Fehler jetzt beheben können. Es lag daran, dass meine
> SCL-Frequenz offenbar zu niedrig war (~93kHz) bei ca. der doppelten
> Frequenz (~187kHz) sind 7 Byte kein Problem mehr
>
> Ich finde es erstaunlich, dass es offenbare auch zu niedrige Frequenzen
> für einige I2C-Komponenten gibt.

Ich finde es erstaunlich dass du wirklich glaubst das es daran liegt.

Ich würde die echte Ursache des Fehlers suchen.

[Stefan F. (Gast)]

Zu niedrige Taktraten kann es laut I2C Spezifikation gar nicht geben. 
Mir sind allerdings A/D Wandler bekannt, die in einem gewissen 
Frequenzbereich sinnvolle Ergebnisse liefern.

Da der Slave kein Clock-Stretching macht, kann die Fehlerursache meiner 
Meinung nach nur im Programmcode des Masters liegen.

Schonmal an einen Stack-Überlauf gedacht? Vielleit tritt der auf, wenn 
die langsame Übertragung durch einen Interrupt gestört wird, dessen ISR 
zusätzlich Speicher belegt.