[STM32] SPI Problemchen

Max Gast 04.01.2020 17:00 #6094777

Lesenswert?

•

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;

Angehängte Dateien:

20200104_163906.jpg (220 KB)

Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden

Walter T. (nicolas) 04.01.2020 18:14 #6094889

Lesenswert?

•

▲
▼

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

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Max Gast 04.01.2020 19:09 #6094968

Lesenswert?

•

▲
▼

Hallo Walter,

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

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Max Gast 04.01.2020 20:49 #6095067

Lesenswert?

•

▲
▼

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?

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Walter T. (nicolas) 04.01.2020 21:36 #6095126

Lesenswert?

•

▲
▼

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.

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Rudolph R. (rudolph) 04.01.2020 22:08 #6095158

Lesenswert?

•

▲
▼

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.

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Max Gast 05.01.2020 11:43 #6095524

Lesenswert?

•

▲
▼

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!

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Jan Gast 05.01.2020 15:46 #6095843

Lesenswert?

•

▲
▼

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

Antwort Zitieren Bearbeiten Löschen Beitrag melden

STMKenner Gast 05.01.2020 15:51 #6095852

Lesenswert?

•

▲
▼

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.

Antwort Zitieren Bearbeiten Löschen Beitrag melden

nfet Gast 05.01.2020 16:08 #6095865

Lesenswert?

•

▲
▼

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.

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Rudolph R. (rudolph) 05.01.2020 16:24 #6095882

Lesenswert?

•

▲
▼

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

Antwort Zitieren Bearbeiten Löschen Beitrag melden

STMKenner Gast 05.01.2020 16:29 #6095888

Lesenswert?

•

▲
▼

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.

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Rudolph R. (rudolph) 05.01.2020 16:39 #6095901

Lesenswert?

•

▲
▼

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.

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Walter T. (nicolas) 05.01.2020 16:51 #6095925

Lesenswert?

•

▲
▼

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.

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Stefan F. Gast 05.01.2020 16:56 #6095931

Lesenswert?

•

▲
▼

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.

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Jan Gast 05.01.2020 17:19 #6095964

Lesenswert?

•

▲
▼

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.

Antwort Zitieren Bearbeiten Löschen Beitrag melden

[STM32] SPI Problemchen

Antwort schreiben