STM32 I2C Clock bleibt low

[Peter P. (Gast)]

Hallo Leute,
ich habe ein kleines Problem. Ich versuche gerade eine Simple I2C 
Übertragung hinzubekommen, die auch manchmal funktioniert. Kurze 
Geschichte dazu. Montag habe ich meinen MPU6050 ausgepackt und 
angefangen etwas damit zu experimentieren. Nachdem ich es geschafft 
hatte, habe ich alles wieder abgebaut und wollte es denn gestern ein 
paar Kollegen vorführen. Nun ging garnichts mehr. Nach etlichen 
Versuchen schaffe ich es denn mal eine Verbindung zu Stande zu bringen. 
Was ich nicht ganz verstehe ist ,dass wenn ich den Controller resette 
SCL und SDA auf High sind. Nach einer Adressierung des Slaves, auf die 
keine Antwort folgt, bleibt sie aber low. In den Fällen, in denen de 
Übertragung klappt ist das aber nicht so. Jemand eine Idee?

[LTC1043 (Gast)]

STM32 und I2C sind so eine Sache... Jedenfalls bei den STM32F1xx

Im Errata Sheet zu den F1xx sind ca. 5 Seiten dazu beschrieben.

Welchen STM32 verwendest du?

Von STM32 gibt es ein Application Note mit optimierten Routinen für I2C. 
Mit diesen sollte es jedefalls klappen. Such mal nach:

"AN2824: STM32F10xxx I²C optimized examples"



Cheers

[Peter P. (Gast)]

Ich verwende einen F4. Ich werde mir die AN2824 mal anschauen.

[holger (Gast)]

>Ich verwende einen F4. Ich werde mir die AN2824 mal anschauen.

Wozu? Die ist für den F1.

[Peter P. (Gast)]

OK jetzt wird es mysteriös. Nachdem ich mir die CPAL von ST angeschaut 
habe, habe ich einfach mal ein Beispiel daraus etwas angepasst und 
musste feststellen, dass auch das nicht funktioniert. Der Slave sendet 
einfach keinen ACK. Der Unterschied zu meinen Routinen war ediglich, 
dass die CPAL die Fehler abfängt und den Bus neu initialisiert und es 
anschließend nochmal versucht. Ich habe aber etwas anderes seltsames 
festgestellt ?!? Wenn man sich das beigefügte Bild anschaut. Ist 
deutlich zu erkennen, dass kurz vorm Start einer Kommunikation SCL und 
SDA rutergezogen werden. Vermutlich ist der jeweilige Slave davon 
ziemlich irritiert und fühlt sich nicht wirklich angesprochen.
Woher kommt das?

[Sebastian W. (sebastian_w29)]

Das sieht in der Tat seltsam aus. Können das Überreste einer vorherigen 
Kommunikation sein? Tritt das direkt am Anfang auf?

[Peter P. (Gast)]

das ist direkt nach dem reset. also der erste kommunikationsversuch

[Sebastian W. (sebastian_w29)]

Vielleicht ein glitch im I2C-Initcode? Versuch doch mal zwischen 
I2C-Init und der ersten Kommunikation etwas zu warten...

Was für Pullup-Widerstände benutzt du?

[Peter P. (Gast)]

Sebastian W. schrieb:
> Vielleicht ein glitch im I2C-Initcode? Versuch doch mal zwischen
> I2C-Init und der ersten Kommunikation etwas zu warten...
>
> Was für Pullup-Widerstände benutzt du?

Jo der ein Glitch in der init. wenn ich warte ist der abstand 
entsprechend größer. funktionieren tut es trotzdem nicht besser. als 
pullup nehme ich 10k. habe aber auch schon 4k7 und 3k3 getestet.

[Sebastian W. (sebastian_w29)]

Auf wieviel Volt ziehst du denn hoch? Mein Raspberry Pi zum Beispiel 
zieht SDA und SCL mit jeweils 1.8kΩ auf 3.3V, und Kommunikation mit 
MPU-6050 funktioniert bei mir problemlos.

Ich hatte das Phänomen der hängenden Leitungen auch mal, da war aber die 
Software eines Attiny als I2C-Slave dran schuld.

Vielleicht solltest du, wenn das wieder passiert, erst mal den MPU-6050 
abklemmen um zu garantieren das es wirklich der uC ist, der die 
Leitungen auf GND zieht.