STM32 I2C Clockstretching slave transmit

[DisplayFreak (Gast)]

Hi,
ich versuche mittels Raspi (Master) einem STM32F031 (Slave) ein Bild zu 
senden, welches er dann auf einem Display, dass am SPI hängt, anzeigt.
Dazu muss ich vorher prüfen, ob das Display bereit ist Daten zu 
empfangen. Dafür habe ich ein Kommando eingerichtet (0x04). Sendet der 
Raspi jetzt 0x04 an den STM, so prüft dieser die Bereitschaft des 
Displays und meldet dann entweder ready (0x05) oder eben busy (0x06) 
zurück.
So weit die Theorie. Jetzt habe ich aber das Problem, das der STM durch 
Clockstretching den Bus blockiert wenn er nicht rechtzeitig antworten 
kann. Und da der Raspi kein stretching unterstützt bricht er die 
Übertragung ab. Also habe ich das Stretching deaktiviert. Und siehe da 
die Übertragung geht nicht mehr.
Der Raspi fragt den Status ab und bekommt als Antwort immer 0xFF. Diese 
Antwort habe ich aber in keinem Fall festgelegt.
Wieso kann der STM ohne Clockstretching scheinbar den Datenpin nicht 
mehr auf low ziehen??

Die wirklich einzige Änderung die ich vorgenommen habe ist folgende:
hi2c1.Init.NoStretchMode = I2C_NOSTRETCH_DISABLE;
->
hi2c1.Init.NoStretchMode = I2C_NOSTRETCH_ENABLE;

[Klaus (Gast)]

DisplayFreak schrieb:
> Und da der Raspi kein stretching unterstützt

Der unterstützt schon stretching. Aber es gibt einen Harwarebug (im 
Chip), durch den er unter ganz bestimmten Umständen, nicht erkennt, daß 
der Slave die Clock verlängert. Das wiederum führt zu merkwürdigen 
Fehlern in den Programmen der höheren Schichten, die das nicht erkennen 
können. Ein Workaround ist, stretching nicht zuzulassen.

MfG Klaus

[DisplayFreak (Gast)]

Klaus schrieb:
> Ein Workaround ist, stretching nicht zuzulassen.

Eben das versuche ich ja. Nur ist der STM aus irgendeinem Grund nicht in 
der Lage mittels Slave Transmit daten zu senden. Er sendet immer 0xFF, 
was für mich so aussieht, als könne er SDA nicht auf low ziehen.

Mit aktiviertem Clockstretching kann er korrekt senden, der Raspi mag 
das aber nicht immer und so kommt es ab und an zu Fehlern.

[Guido Körber (Gast)]

Dann bleibt wohl keine andere Option, als den STM32 Code so weit zu 
tunen, dass er ohne Clockstretching läuft. IIC-Interrupt auf höchste 
Priorität setzen und dann schlanken Code generieren.
Die HAL-Library ist dazu nicht geeignet…

[Bernd K. (prof7bit)]

Oder I²C-Master auf dem Raspi mit Bitbanging selber implementieren.

[Gerd E. (robberknight)]

Hast Du mal mit dem Oszi oder Logicanalyzer geschaut wie lang das Clock 
stretching in der Praxis überhaupt ist?

[DisplayFreak (Gast)]

Es gibt ein clockstretching beim ersten Takt nachdem die I2C Adresse 
übertragen wurde. Das ist aber wirklich minimal. Statt 8µs low - 8µs 
high ist es hier 10µs low und 6µs high.
Ich dachte der STM ist an der Stelle evt. zu langsam für das was 
zwischendrin in der HAL routine läuft. Also hab ich den Systemtakt von 
8MHz auf 48MHz angehoben. Das bringt aber gar keinen Effekt.