STM32 I2C Clockstretching slave transmit

Gast #5560683
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;
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
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.
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…
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.

Antwort schreiben

Eine eigene Frage? Dieser Thread ist über 8 Jahre alt. Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.

Neuen Thread starten

Eine Lösung, Ergänzung oder Rückmeldung zu diesem Thread? Dann antworte hier.

Formatierung
  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] – Link zu einem Artikel
  • Verweis auf einen anderen Beitrag: Rechtsklick auf dessen Beitrags-ID (#8078628), „Adresse kopieren“, in den Text einfügen

Mehr zur Formatierung

Längeren Sourcecode als Anhang, nicht in den Text. JPG nur für Fotos und Scans; Zeichnungen und Screenshots als PNG oder GIF. Siehe Bildformate.

Schon registriert? Anmelden

Wird nicht angezeigt. Wir schicken dir einen Link; sobald du damit bestätigst, erscheint dein Beitrag.

Mit dem Abschicken legst du einen kostenlosen Account an und erkennst die Nutzungsbedingungen und die Datenschutzerklärung an.