[STM32] SPI Problemchen

[Max (Gast)]

Hallo zusammen,

ich habe ein kleines Problem mit SPI beim STM32H7 (als Master). Wie im 
Bild zu sehen scheint der letzte Clock-cycle irgendwie abgeschnitten, 
als würde der STM sofort beim Erreichen der letzten steigenden Flanke 
den Pin hochohmig schalten. Die untere Spur ist Clock, die obere MOSI. 
Ist das so normal? Die Gegenseite bekommt das letzte Bit jedenfalls 
nicht mit.

Initialisiert wird die Schnittstelle mit

  hspi2.Instance = SPI2;
  hspi2.Init.Mode = SPI_MODE_MASTER;
  hspi2.Init.Direction = SPI_DIRECTION_2LINES;
  hspi2.Init.DataSize = SPI_DATASIZE_32BIT;
  hspi2.Init.CLKPolarity = SPI_POLARITY_LOW;
  hspi2.Init.CLKPhase = SPI_PHASE_1EDGE;
  hspi2.Init.NSS = SPI_NSS_SOFT;
  hspi2.Init.BaudRatePrescaler = SPI_BAUDRATEPRESCALER_256;
  hspi2.Init.FirstBit = SPI_FIRSTBIT_MSB;
  hspi2.Init.TIMode = SPI_TIMODE_DISABLE;
  hspi2.Init.CRCCalculation = SPI_CRCCALCULATION_DISABLE;
  hspi2.Init.CRCPolynomial = 0x0;
  hspi2.Init.NSSPMode = SPI_NSS_PULSE_DISABLE;
  hspi2.Init.NSSPolarity = SPI_NSS_POLARITY_LOW;
  hspi2.Init.FifoThreshold = SPI_FIFO_THRESHOLD_01DATA;
  hspi2.Init.TxCRCInitializationPattern = SPI_CRC_INITIALIZATION_ALL_ZERO_PATTERN;
  hspi2.Init.RxCRCInitializationPattern = SPI_CRC_INITIALIZATION_ALL_ZERO_PATTERN;
  hspi2.Init.MasterSSIdleness = SPI_MASTER_SS_IDLENESS_06CYCLE;
  hspi2.Init.MasterInterDataIdleness = SPI_MASTER_INTERDATA_IDLENESS_06CYCLE;
  hspi2.Init.MasterReceiverAutoSusp = SPI_MASTER_RX_AUTOSUSP_DISABLE;
  hspi2.Init.MasterKeepIOState = SPI_MASTER_KEEP_IO_STATE_DISABLE;
  hspi2.Init.IOSwap = SPI_IO_SWAP_DISABLE;

[Walter T. (nicolas)]

Kommt nach dem Datum ein SPI_Disable() ? Dann wird der Treiber hochohmig 
(zumindest bei den STM32F4xx und den STM32F1xx).

[Max (Gast)]

Hallo Walter,

manuell habe ich kein SPI_Disable() oder so eingebaut. Ich schaue 
nachher mal ob die HAL das irgendwo automatisch macht.

[Max (Gast)]

Das war ein sehr guter Hinweis! HAL ruft tatsächlich bei 
HAL_SPI_TransmitReceive() automatisch __SPI_Disable() auf. Wie soll man 
die Funktion denn nutzen, wenn sie automatisch das letzte Bit quasi 
verschluckt? Habe ich da was grundlegendes falsch verstanden?

[Walter T. (nicolas)]

Das letzte Bit verschluckt sie nur, wenn der SPI-Modus nicht stimmt. 
Ansonsten macht sie nur den Bus nach fertiger Übertragung hochohmig.

Meines Wissens muß dann gegen die floatenden Pins anderweitig Abhilfe 
geschaffen werden.

[Rudolph R. (rudolph)]

Max schrieb:
> HAL ruft tatsächlich bei HAL_SPI_TransmitReceive() automatisch >__SPI_Disable() 
auf.

Das ist durchaus seltsam, ist das Verhalten konfigurierbar?

> Wie soll man die Funktion denn nutzen,
> wenn sie automatisch das letzte Bit quasi verschluckt?

Nun ja, Dein SPI läuft ja nur mit 5kHz, das ist unüblich langsam.
Möglich, dass der Programmierer der HAL Funktion nicht daran gedacht 
hat, dass der SPI so langsam laufen könnte und so kommt das Abschalten 
einfach ein paar Takte zu schnell.

Dreh das doch mal auf 1+ MHz hoch.
Alternativ kannst Du doch die HAL-Funktionen auch verändern.
Bau da ein paar NOPs ein oder wirf das Disable gleich ganz raus.

Oder verzichte komplett auf die HAL Funktionen.

[Max (Gast)]

Rudolph R. schrieb:
> Dreh das doch mal auf 1+ MHz hoch.

Das hat das Problem gelöst! =D
Ich hatte irgendwo bei unter 1MHz angefangen und dann immer weiter 
reduziert, weil ich dachte es sollte tendenziell stabiler sein wenn es 
langsamer läuft. Über ~1MHz klappt es jetzt gut. Vielen Dank euch beiden 
für die Tips!

[Jan (Gast)]

Es gibt doch bestimmt n Status Flag, die angibt ob die SPI fertig ist 
oder? Ggf. Auch als Bug Report bei st melden.

[STMKenner (Gast)]

Jan schrieb:
> n Status Flag

Ich kenn mich ja bei den STMs ganz gut aus aber das n Status Flag
hab ich noch nicht gesehen.

[nfet (Gast)]

Da deine Daten aber auf der steigenden Flanke gültig sind, sollte das so 
eigentlich auch kein Problem sein? Ist denn der Empfänger korrekt 
eingestellt?
Das senden ist für den master nach der steigenden Flanke ja 
abgeschlossen.

[Rudolph R. (rudolph)]

STMKenner schrieb:
> Ich kenn mich ja bei den STMs ganz gut aus aber das n Status Flag
> hab ich noch nicht gesehen.

Wir wäre es mit dem BSY Bit im SPI status Register?

Nicht, dass ich mich da überhaupt auskennen würde, ich habe jetzt nur 
mal ein wenig mit dem GD32VF103 rumgespielt (da heisst das TRANS).

Aber die drei Referenz-Manuals die ich für STM32 auf der Platte habe 
listen alle das BSY bit in den SPI status Registern.

Edit: okay der STM32H7 ist da ein wenig spezieller

[STMKenner (Gast)]

Rudolph R. schrieb:
> Aber die drei Referenz-Manuals die ich für STM32 auf der Platte habe
> listen alle das BSY bit in den SPI status Registern.

Dann zeig mir mal in den drei Referenz-Manuals das

"n Status Flag"

von dem Jan spricht.

[Rudolph R. (rudolph)]

Na, was könnte das "n" wohl in dem Kontext bedeuten?
Ich tippe schwer auf "nen" oder eben "ein"...

Er schrieb ja nicht, es gibt das n Status Bit, so schwer ist das doch 
gar nicht zu verstehen.

[Walter T. (nicolas)]

Rudolph R. schrieb:
> wäre es mit dem BSY Bit im SPI status Register?

Das wird zumindest in den F1- und F4-Errata-Sheets als "besser nicht 
benutzen" gekennzeichnet.

[Stefan F. (Gast)]

Walter T. schrieb:
> Meines Wissens muß dann gegen die floatenden Pins anderweitig Abhilfe
> geschaffen werden.

Ist schon blöd, wenn man mit der HAL Probleme lösen muss, die man ohne 
sie nicht hätte. Ähnliche Szenarien liest man hier fast jede Woche. Ich 
selbst hatte ja auch in den ersten drei Projekten drei HAL spezifische 
Probleme (eindeutig Bugs).

Mich bestätigen diese Berichte darin, dass man STM32 besser zuerst mal 
ohne die HAL programmieren lernen sollte. Später kann man sich dann die 
HAL mal anschauen, wenn man grob weiß, was man da tut. Dann kann auch 
besser erfassen, welchen Nutzen sie bringt.

[Jan (Gast)]

Rudolph R. schrieb:
> Na, was könnte das "n" wohl in dem Kontext bedeuten?
> Ich tippe schwer auf "nen" oder eben "ein"...

Sorry, korrekt. Hab vom Handy geschrieben, daher die kleine 
Vereinfachung.