STM32F407 und das SPI Modul

[holger (Gast)]

Beim messen am SPI Modul vom STM32F407 kamen ein paar
merkwürdig Dinge ans Tageslicht.

Diese Routine wurde quasi nach den Beispielen aus der Periphery Library
von ST programmiert. Hier halt nur direkt über die Register.

uint16_t SPI2_SendReceive(uint16_t data)
{
  /*!< Loop while DR register in not empty */
  // hk we do not need this if we can be sure last transmission ends before
  while ((SPI2->SR & SPI_I2S_FLAG_TXE) == RESET);

  /*!< Send byte through the SPI2 peripheral */
  SPI2->DR = data;

  /*!< Wait to receive data */
  while ((SPI2->SR & SPI_I2S_FLAG_RXNE) == RESET);

  /*!< Return data read from the SPI bus */
  // there is a 500ns pause between transfers.

  return SPI2->DR;
}

Funktioniert auch, ABER zwischen den einzelnen Bytes ist eine ziemlich
grosse Pause von 250ns beim SPI1 und 500ns beim SPI2 zu sehen. Wo kommt 
die denn her?
Die Pause ist unabhängig von der eingestellten SPI Taktrate.

Gut, zweiter Versuch statt 8 Bit gleich 16 Bit übertragen wenn es
die Daten erlauben. Das geht, jetzt hat man nur noch eine Pause
zwischen jeweils 16 Clock Zyklen. Schön ist das aber auch nicht.

Dritter Versuch SPI_I2S_FLAG_RXNE, was wohl der Grund für die Pause ist, 
nicht mehr
abfragen wenn man nur senden möchte. Am Ende dann auf das Busy Flag 
warten.
Ich weiss das das im Datenblatt nicht empfohlen wird. Beim DMA Transfer
allerdings schon. Dazu komme ich später.

void SPI2_Send(uint16_t data)
{
  /*!< Loop while DR register in not empty */
  while ((SPI2->SR & SPI_I2S_FLAG_TXE) == RESET);

  SPI2->DR = data;

  // after last data send, use SPI2_WaitSend() to be sure transfer has finished
}

uint16_t SPI2_WaitSend(void)
{
  /*!< Loop while DR register in not empty */
  while ((SPI2->SR & SPI_I2S_FLAG_TXE) == RESET);

  /*!< Wait for transfer finished */
  while ((SPI2->SR & SPI_I2S_FLAG_BSY) == SET);
  return SPI2->DR; // this read resets SPI_I2S_FLAG_RXNE flag
}

Dann einfach mal einen IO Pin vor dem senden auf
High gesetzt, und wenn Busy auf 0 geht auf Low setzen.

 SPI2_Send(0xFF);
 SPI2_Send(0xFF);
 SPI2_WaitSend();

Auf dem Osci sieht man dann warum ST die Busy Abfrage nicht
empfiehlt. Busy geht auf Low bevor die Daten rausgetaktet wurden.
Nach Busy Low kommen noch drei oder vier Takte auf der Clock Leitung.
Na herzlichen Glückwunsch, wie soll man bei einem reinen Sendetransfer
eigentlich feststellen wann die Übertragung beendet ist? Es gibt
ausser Busy kein Flag dafür.

Kommen wir mal zu einem reinen DMA Sendetransfer. Da wird von ST
empfohlen das Busy Flag abzufragen. So wie in SPI2_WaitSend();.
Funktioniert nur nicht. Der selbe Effekt wie oben. Busy geht low
bevor der Transfer beendet ist.


Hat ST das SPI Modul wirklich so vergurkt?

[erhardd (Gast)]

... ich weis nichtmehr genau wo, -aber hier hat der Autor einige , 
nennen wir sie mal , "Kuriositäten" (s.DMA) zusammengetragen.
Sehr aufschlussreich...
http://blog.frankvh.com

[holger (Gast)]

Hier mal der Sourcecode als Minimalprojekt.
Gleich folgen ein paar Bilder vom Osci.

[holger (Gast)]

Im ersten sieht man das das SPI Modul mit 42MHz läuft.
Im zweiten Bild die Pause zwischen den Übertragungen.

[holger (Gast)]

Hier im 16Bit Modus. Pause nur alle 16Bit.

[holger (Gast)]

Hier 16Bit Send Only. Das verdammte Busy geht runter bevor
die Übertragung beendet ist. Das gleiche passiert bei einer
Send Only DMA Übertragung bei der Übertragung des letzten
Elements.

[erhardd (Gast)]

... ja, warum?
Nur mal eine These:
der Clock-Impuls ist etwa 23nS lang;
8 Datenimpulse auf MOSI dürften dann theor. etwa 184nS lang sein;
sind aber etwa 200nS;
Fast 1 Clock verzögert. -warum?

[erhardd (Gast)]

...Frank hatte darauf hingewiesen, finde nurnicht wo...

[erhardd (Gast)]

...und er hatte auch einen "workaround" dafür;