STM32 HAL_SPI_TransmitReceive: Warum wird transmitData geändert?

[Holger T. (holger1979)]

Hallo,

wenn ich beim STM32F2 mit der Funktion HAL_SPI_TransmitReceive() Daten 
versende, dann ist transmitData anschließend nicht mehr mit den Daten 
versehen, die vorher drin standen, sondern die sind leer oder aber 
vereinzelt sind andere Werte vorhanden.

Was hat es damit auf sich? Warum wird hier überhaupt der Puffer geleert 
und warum steht manchmal ein Wert drin?

Vielen Dank und viele Grüße!

[Jojo S. (Gast)]

Die Antwort steht doch schon im Funktionsnamen...

[Arsch N. (arschnelson)]

Wieso benutzt du HAL_SPI_TransmitReceive()? Willst du senden oder 
empfangen?

[Dr. Pinguin (Gast)]

Arsch N. schrieb:
> Wieso benutzt du HAL_SPI_TransmitReceive()? Willst du senden oder
> empfangen?

Was könnte er mit "wenn ich beim STM32F2 mit der Funktion 
HAL_SPI_TransmitReceive() Daten versende" wohl gemeint haben?


Aber Hauptsache, mal irgendwelchen Blödsinn posten....

[Ingo L. (corrtexx)]

Holger T. schrieb:
> wenn ich beim STM32F2 mit der Funktion HAL_SPI_TransmitReceive() Daten
> versende, dann ist transmitData anschließend nicht mehr mit den Daten
> versehen, die vorher drin standen, sondern die sind leer oder aber
> vereinzelt sind andere Werte vorhanden.
Wie funktioniert SPI? Da stelle ma uns ma ganz blöde:
Du packst etwas in das "SPI-Register". Dann drückst du auf "Senden". In 
dem Moment sendest du deine Daten und empfängst gleichzeitig die Daten 
vom Slave.

Guckst du:
https://www.mikrocontroller.net/articles/Serial_Peripheral_Interface

@Arsch Nelson
Du solltest auch gleich mal lesen ;)

[Stefan K. (stefan64)]

Für alle, die hier posten, ohne die HAL_SPI_TransmitReceive auch nur 
einmal gesehen zu haben:

/**
  * @brief  Transmit and Receive an amount of data in blocking mode 
  * @param  hspi: pointer to a SPI_HandleTypeDef structure that contains
  *                the configuration information for SPI module.
  * @param  pTxData: pointer to transmission data buffer
  * @param  pRxData: pointer to reception data buffer to be
  * @param  Size: amount of data to be sent
  * @param  Timeout: Timeout duration
  * @retval HAL status
  */
HAL_StatusTypeDef HAL_SPI_TransmitReceive(SPI_HandleTypeDef *hspi, uint8_t *pTxData, uint8_t *pRxData, uint16_t Size, uint32_t Timeout)

Für Transmit und Receive sind 2 GETRENNTE Buffer vorhanden.

@TS:
Mit welchen Parametern rufst Du HAL_SPI_TransmitReceive() auf? Ist 
dichergestellt, dass beide Buffer groß genug sind? Wie wurde hspi 
initialisiert? 8 oder 16 Bit Zugriff?

Gruß, Stefan

[Holger T. (holger1979)]

Hallo Stefan K,

als Parameter verwende ich zwei Strukts, welche jeweils ein Bytefeld 
enthalten.

Als ersten Parameter: &hspi3
Als zweiten Parameter: transmit.data
Als dritten Parameter: receive.data
Als vierten Parameter: size

Demnach sollte es stimmen.

Masterseite verwendet HAL_SPI_TransmitReceive()
und Slave verwendet HAL_SPI_TransmitReceive_IT()

Nach der Übertragung steht in beiden Receivepuffern die erwartete 
Nachricht.
Lediglich der Transmitpuffer des Masters ist dann entweder leer oder 
aber enthält einzelne Werte, die auch mal von 0 abweichen.

Die Datenbreite habe ich als 8 Bit gewählt.
Die Felder sind jeweils 16 Byte groß. Sowohl Senden als auch Empfangen.

Als Bestätigung sende ich ein einzelnes Byte zurück per
HAL_SPI_Transmit und HAL_SPI_Receive. So wie es aussieht, kommt dann der 
HAL_Treiber damit nicht zurecht und ändert dann die Transmitadresse, die 
ich beim HAL_SPI_TransmitReceive zuvor verwendet habe.

Ein Ersetzen aller Transmit und Receive durch TransmitReceive beseitigt 
den Fehler.

Ist anscheinend ein Bug in den HAL-Treibern

[W.S. (Gast)]

Holger T. schrieb:
> als Parameter verwende ich zwei Strukts, welche jeweils ein Bytefeld
> enthalten.

Ich geb dir einen guten Rat: Schmeiß die gesamte ST-Lib von deinem 
Rechner, lies das refMan damit du die HW verstehen lernst und mache dir 
deine eigenen Treiber für die Peripherie, die du gebrauchen willst.

W.S.

[Jojo S. (Gast)]

Holger T. schrieb:
> Ist anscheinend ein Bug in den HAL-Treibern

da wäre ich skeptisch.

> HAL_SPI_Transmit und HAL_SPI_Receive. So wie es aussieht, kommt dann der
> HAL_Treiber damit nicht zurecht und ändert dann die Transmitadresse, die
> ich beim HAL_SPI_TransmitReceive zuvor verwendet habe.

Die Quellen von HAL_SPI_Transmit() kann man ja ansehen (oder sogar 
debuggen). Darin sehe ich zumindest keine Schreibzugriffe auf den 
TxBuffer. Der übergebene Pointer für den TxBuffer wird in 
hspi->pTxBuffPtr zwischengespeichert und der steht dann (dereferenziert) 
immer rechts vom Gleichheitszeichen, es wird also nur lesend auf den 
Buffer zugegriffen.
Da bleibt der Verdacht das der TxBuffer durch eine andere Funktion 
(Receive mit zu kleiner buffsize?) kaputtgeschrieben wird.

[Holger T. (holger1979)]

Hallo,

bei der Verwendung von HAL_SPI_Receive_IT wird auch automatisch 
HAL_SPI_TransmitReceive_IT aufgerufen.

Hier wird zumindest beim Empfangen genau das als Dummy gesendet, was im 
Empfangspuffer vor dem aufrufen der Funktion drin stand.

Ich habe auf jeden Fall jetzt alle Transmit und Receive durch 
TransmitReceive ersetzt (Auf Master und Slave Seite). Da kann ich 
zumindest noch die Dummybytes setzen und schauen, ob die auf der anderen 
Seite richtig ankommen. Die Pakete sind dann auch in Ordnung.

Und einen Mehraufwand auf den Leitungen gibt es dadurch ja auch nicht, 
weil die Daten ja sowieso in beide Richtungen gehen.

[Holger T. (holger1979)]

Lösung gefunden!

Während ich empfange kann gesendet werden.
Während ich sende kann empfangen werden.

Habe mich an ein Beispiel aus einer Vorlesung erinnert mit zwei 
Eisenbahnen die über eine Kreuzung fahren mussten. Die gute, alte 
Semaphore.

Wenn ich das Eine blockiere, wenn das jeweils Andere aktiv ist, dann 
läuft es plötzlich.   ;)

Da kommt man aber auch nicht drauf...