STM32F2 SPI DMA CS Handling

[Commander Keen (Gast)]

Hallo,

ich versuche gerade zwei STM32F205 uC über SPI zu verbinden.
Mein erster Schritt ist es nun aus dem Master einen Output Stream via 
DMA zu entlocken.

Ich initialisiere also die DMA, setze den CS und warte auf den 
TransferComplete Interrupt in dem ich den CS wieder zurücknehme.

Mit dem Code unten funktioniert das im Prinzip, außer dass er im 
Interrupt den CS genau 15 Bits zu früh zurücksetzt.
Das erscheint mir auf dem zweiten Blick auch logisch, das 
TransferComplete Flag bedeutet in diesem Falle dass die letzten Daten 
über DMA an die SPI Peripherie übergeben wurden, sind zu diesem 
Zeitpunkt aber noch nicht gesendet. Für diesen Test folgendes Define 
aktivieren.

 
#define TRANSMIT_COMPLETE

Also habe ich mir gedacht ich benutze den TransferComplete Interrupt des 
DMA Receive Streams. Das funktioniert dann beim ersten Senden wie 
gewünscht, allerdings ist anschließend Sendeschluss. Für diesen Test 
folgendes Define aktivieren.

 
#define RECEIVE_COMPLETE

Es kommen beim zweiten Sendevorgang keinerlei Daten mehr auf den Bus 
geschweige denn ein TransferComplete Interrupt

###

#include <stdint.h>
#include "stm32f2xx.h"

#define TRANSMIT_COMPLETE
//#define RECEIVE_COMPLETE

#ifdef TRANSMIT_COMPLETE
#define DMA_STREAM_IRQn    DMA1_Stream7_IRQn
#define DMA_IRQ_STREAM    DMA1_Stream7
#define DMA_IRQ_TCIF    DMA_IT_TCIF7
#define DMA_IRQ_HANDLER    DMA1_Stream7_IRQHandler
#endif
#ifdef RECEIVE_COMPLETE
#define DMA_STREAM_IRQn    DMA1_Stream0_IRQn
#define DMA_IRQ_STREAM    DMA1_Stream0
#define DMA_IRQ_TCIF    DMA_IT_TCIF0
#define DMA_IRQ_HANDLER    DMA1_Stream0_IRQHandler
#endif


void init(void) {
  GPIO_InitTypeDef gpio;
  SPI_InitTypeDef spi;
  //clock peripherals
  RCC_APB1PeriphClockCmd(RCC_APB1Periph_SPI3, ENABLE);
  RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_GPIOA, ENABLE); //CS
  RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_GPIOC, ENABLE); //CLK, MISO, MOSI
  //init CS pin
  GPIO_StructInit(&gpio);
  gpio.GPIO_Pin = GPIO_Pin_15;
  gpio.GPIO_Mode = GPIO_Mode_OUT;
  gpio.GPIO_Speed = GPIO_Speed_50MHz;
  gpio.GPIO_OType = GPIO_OType_PP;
  gpio.GPIO_PuPd = GPIO_PuPd_NOPULL;
  GPIO_Init(GPIOA, &gpio);
  GPIOA->BSRRL = GPIO_Pin_15; //set CS
  //init spi pins
  gpio.GPIO_Pin = GPIO_Pin_10 | GPIO_Pin_10 | GPIO_Pin_10;
  gpio.GPIO_Mode = GPIO_Mode_AF;
  gpio.GPIO_Speed = GPIO_Speed_50MHz;
  gpio.GPIO_PuPd = GPIO_PuPd_NOPULL;
  GPIO_Init(GPIOC, &gpio);
  GPIO_PinAFConfig(GPIOC, GPIO_PinSource10, GPIO_AF_SPI3);
  GPIO_PinAFConfig(GPIOC, GPIO_PinSource11, GPIO_AF_SPI3);
  GPIO_PinAFConfig(GPIOC, GPIO_PinSource12, GPIO_AF_SPI3);
  //init spi
  SPI_StructInit(&spi);
  spi.SPI_Direction = SPI_Direction_2Lines_FullDuplex;
  spi.SPI_Mode = SPI_Mode_Master;
  spi.SPI_DataSize = SPI_DataSize_8b;
  spi.SPI_CPOL = SPI_CPOL_Low;
  spi.SPI_CPHA = SPI_CPHA_1Edge;
  spi.SPI_NSS = SPI_NSS_Soft;
  spi.SPI_BaudRatePrescaler = SPI_BaudRatePrescaler_256;
  SPI_Init(SPI3,&spi);
  SPI_Cmd(SPI3, ENABLE);
}

void send_dma(uint8_t* src, uint8_t* dest, uint32_t cnt) {
  DMA_InitTypeDef  dma;
  NVIC_InitTypeDef nvic;
  RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_DMA1, ENABLE);
  //init_nvic
  nvic.NVIC_IRQChannel = DMA_STREAM_IRQn;
  nvic.NVIC_IRQChannelPreemptionPriority = 0;
  nvic.NVIC_IRQChannelSubPriority = 2;
  nvic.NVIC_IRQChannelCmd = ENABLE;
  NVIC_Init(&nvic);
  //init tx dma
  dma.DMA_Channel = DMA_Channel_0;
  dma.DMA_PeripheralBaseAddr = (uint32_t)&SPI3->DR;
  dma.DMA_Memory0BaseAddr = (uint32_t) &src;
  dma.DMA_DIR = DMA_DIR_MemoryToPeripheral;
  dma.DMA_BufferSize = cnt;
  dma.DMA_PeripheralInc = DMA_PeripheralInc_Disable;
  dma.DMA_MemoryInc = DMA_MemoryInc_Enable;
  dma.DMA_PeripheralDataSize = DMA_PeripheralDataSize_Byte;
  dma.DMA_MemoryDataSize = DMA_MemoryDataSize_HalfWord;
  dma.DMA_Mode = DMA_Mode_Normal;
  dma.DMA_Priority = DMA_Priority_High;
  dma.DMA_FIFOMode = DMA_FIFOMode_Disable;
  dma.DMA_FIFOThreshold = DMA_FIFOThreshold_HalfFull;
  dma.DMA_MemoryBurst = DMA_MemoryBurst_Single;
  dma.DMA_PeripheralBurst = DMA_PeripheralBurst_Single;
  DMA_Init(DMA1_Stream7, &dma);
  //init rx dma
  dma.DMA_Channel = DMA_Channel_0;
  dma.DMA_DIR = DMA_DIR_PeripheralToMemory;
  dma.DMA_Memory0BaseAddr = (uint32_t) &dest;
  dma.DMA_BufferSize = cnt;
  dma.DMA_MemoryInc = DMA_MemoryInc_Enable;
  DMA_Init(DMA1_Stream0, &dma);
  //enable streams
  DMA_Cmd(DMA1_Stream0, ENABLE);
  DMA_Cmd(DMA1_Stream7, ENABLE);
  //enable interrupt
  DMA_ITConfig(DMA_IRQ_STREAM, DMA_IT_TC, ENABLE);
  SPI_I2S_DMACmd(SPI3,SPI_I2S_DMAReq_Rx,ENABLE);
  SPI_I2S_DMACmd(SPI3,SPI_I2S_DMAReq_Tx,ENABLE);
  GPIOA->BSRRH = GPIO_Pin_15;  //clear CS
  I2S_Cmd(SPI3, ENABLE);
}

void DMA_IRQ_HANDLER(void) {
  DMA_ClearITPendingBit(DMA_IRQ_STREAM, DMA_IRQ_TCIF);
  GPIOA->BSRRL = GPIO_Pin_15;  //set CS
}

uint8_t outbuffer[10];
uint8_t inbuffer[10];
int main(void) {
  outbuffer[0] = 1;
  outbuffer[0] = 2;
  outbuffer[0] = 3;
  init();
  for(int32_t i=0 ; i<100000 ; i++);
  send_dma(outbuffer, inbuffer, 3);    //breakpoint
  for(int32_t i=0 ; i<100000 ; i++);
  send_dma(outbuffer, inbuffer, 3);    //breakpoint
  while(1);
  return 0;
}

[Irgendwer (Gast)]

Was der DMA-Teil macht ist doch eigentlich völlig egal,
interessanter ist was der SPI-Teil macht.
Da z.B. der Interrupt mittels "Transmit buffer empty flag"

[STM Apprentice (Gast)]

Commander Keen schrieb:
> Also habe ich mir gedacht ich benutze den TransferComplete Interrupt des
> DMA Receive Streams.

Darf ich dich auf meine sehr ähnliche Problematik hinweisen:

Beitrag "[STM32F4xx] SPI Optimierung"

Vermutlich musst auch du das SPI_I2S_FLAG_BSY auswerten bis
du den CS wegnehmen kannst/darfst. Ob es dafür einen Interrupt
gibt kann ich so spät in der Nacht nicht sagen .... ;-)

[Commander Keen (Gast)]

Hallo,

habe beim Code zusammenstreichen noch einen Fehler gemacht, es muss 
heißen

gpio.GPIO_Pin = GPIO_Pin_10 | GPIO_Pin_11 | GPIO_Pin_12;

@ Irgendwer
Die SPI Interrupts hatte ich bisher nicht auf dem Schirm, werde ich mir 
mal anschauen

@STM Apprentice
Ich weigere mich bei der Verwendung einer DMA auf irgendwelches Polling 
zurück zu greifen. Dann wechsele ich lieber den uC ;-)

Ich habe hier
http://www.diller-technologies.de/stm32.html#spi_dma
unter
"16 SPI mit DMA"

noch eine Möglichekit für eine andere Familie gesehen.
Dort werden Interrupts miteinander verschachtelt.
Den Sinn habe ich noch nicht ganz verstanden.

Scheint bei den STMs alles nicht so benutzerfreundlich zu sein ...

[Stefan K. (stefan64)]

Du musst auf jeden Fall den SPI-Receive DMA benutzen, um das CS 
zurückzunehmen, weil nur dieser NACH erfolgtem Transfer aktiv wird.

Was heisst das genau:
> Es kommen beim zweiten Sendevorgang keinerlei Daten mehr auf den Bus
> geschweige denn ein TransferComplete Interrupt
Wird der SPI-Transfer überhaupt nicht gestartet?

Viele Grüße, Stefan

[Jim M. (turboj)]

Commander Keen schrieb:
> #define RECEIVE_COMPLETE
> Es kommen beim zweiten Sendevorgang keinerlei Daten mehr auf den Bus
> geschweige denn ein TransferComplete Interrupt

Kann ich mit dem geposteten Code nicht wirklich nachvollziehen.

Hier müsste mit 'nem Debugger mal nachgeschaut werden wo es klemmt. 
Eventuell hängt der Prozessor in irgendeinem nicht behandelten Interrupt 
fest.

[STM Apprentice (Gast)]

Commander Keen schrieb:
> Es kommen beim zweiten Sendevorgang keinerlei Daten mehr auf den Bus
> geschweige denn ein TransferComplete Interrupt

... äääääähhhhmmmm ....

Ist es dein Ernst, bei jedem Block Transfer die ganze DMA-
Maschine und den NVIC neu zu initialisieren?

Bestimmte Sachen können beim STM32 nicht zweimal initialisiert
werden, manche Sachen müssen auch erst disabled werden bevor
sie umprogrammiert werden können ..... bin mir nicht sicher
ob das auf deine Anwendung zutrifft.

[STM Apprentice (Gast)]

Commander Keen schrieb:

gpio.GPIO_Pin = GPIO_Pin_10 | GPIO_Pin_10 | GPIO_Pin_10;

Ich könnte mir vorstellen dass das nicht so gemeint ist.

[STM Apprentice (Gast)]

STM Apprentice schrieb:
> Ich könnte mir vorstellen dass das nicht so gemeint ist.

ooops, bereits vorher erkannt worden und ich hab es übersehen.

[STM Apprentice (Gast)]

Commander Keen schrieb:
> Ich weigere mich bei der Verwendung einer DMA auf irgendwelches Polling
> zurück zu greifen.

Wenn's nicht anders geht, dann vielleicht so:

Der DMA Interrupt wird ja sowieso durchlaufen weil der CS
deaktiviert werden soll. Der IRQ wird ausgelöst weil die DMA-
Maschine fertig ist, jetzt muss nur noch die "Pipeline" leer
werden, d.h. das letzte Byte vom SPI muss draussen sein. Dieses
Flag SPI_I2S_IT_TXE kann man im Interrupt-Kontext pollen, das
kann ja auch nicht lange dauern.

Das müsste funktionieren vorausgesetzt die SPI Flags werden im
DMA Modus auch entsprechend wie im Nicht-DMA-Modus gesetzt.

[Commander Keen (Gast)]

Stefan K. schrieb:
> Wird der SPI-Transfer überhaupt nicht gestartet?
Ich denke nicht. Wie erwähnt kommen nach dem ersten send_dma Aufruf 
sinnige Pegel am SPI. Er schickt die 3 Bytes raus und auch der CS ist in 
Ordnung. Beim zweiten Aufruf von send_dma passiert an den SPI Pins rein 
gar nichts mehr und er springt auch nicht mehr in die ISR.

Jim M. schrieb:
> Eventuell hängt der Prozessor in irgendeinem nicht behandelten Interrupt
> fest.
Beim debuggen läuft er ganz normal weiter. Auch zusätzlicher Code in der 
while(1) wird dann ausgeführt.

STM Apprentice schrieb:
> Ist es dein Ernst, bei jedem Block Transfer die ganze DMA-
> Maschine und den NVIC neu zu initialisieren?
Der Code ist quick&dirty. Ich hatte den ganzen dma und nvic Kram zuvor 
schon in der init Routine die nur einmalig aufgerufen wird allerdings 
ohne Erfolg. Deswegen aktuell alles immer neu initialisiert weil ich 
gehofft habe so eher zum Erfolg zu kommen.

@ STM Apprentice
Im Prinzip gebe ich Dir recht. Sobald der Interrupt kommt könnte ich die 
restliche (kleine) Zeit warten bis die letzten Bits rausgeschickt sind.

Allerdings verstehe ich nicht warum der Code bei dem DMA1_Stream7 
Interrupt (Transmit) funktioniert und beim DMA1_Stream0 (Receive) nicht 
mehr.
Aus Sicht der DMA dürfte doch beides gleich sein ?

[STM Apprentice (Gast)]

Commander Keen schrieb:
> I2S_Cmd(SPI3, ENABLE);

Könnte es sein dass diese Zeile ist falsch ist?

* @brief Enables or disables the specified SPI peripheral (in I2S mode).

Wodurch genau wird eigentlich der DMA/SPI Transfer ausgelöst?

[Commander Keen (Gast)]

STM Apprentice schrieb:
> Commander Keen schrieb:
>> I2S_Cmd(SPI3, ENABLE);
>
> Könnte es sein dass diese Zeile ist falsch ist?
So wie ich das verstanden habe unterstützt der SPI 2 und 3 noch den I2S 
Mode. Der Unterschied zur Funktion SPI_Cmd(SPI3, ENABLE); besteht in der 
Fehlerabfrage

STM Apprentice schrieb:
> Wodurch genau wird eigentlich der DMA/SPI Transfer ausgelöst?

SPI_I2S_DMACmd(LCD_SPI_PERIPH,SPI_I2S_DMAReq_Rx,ENABLE);
SPI_I2S_DMACmd(LCD_SPI_PERIPH,SPI_I2S_DMAReq_Tx,ENABLE);

Ich habe den Fehler nun gefunden.
Bevor die DMAs initialisiert werden sollte man

  * @brief  Deinitialize the DMAy Streamx registers to their default reset values.
DMA_DeInit(DMA1_Stream0); 
//bzw.
DMA_DeInit(DMA1_Stream7);

aufrufen.

Nun schickt er die Daten mit korrektem CS Timing raus und ich bekomme 
sogar richtige Daten als Antwort im Receive Puffer.

Nochmals Danke für den Input

[STM Apprentice (Gast)]

Commander Keen schrieb:
> Ich habe den Fehler nun gefunden.
> Bevor die DMAs initialisiert werden sollte man  * @brief  Deinitialize
> the DMAy Streamx registers to their default reset values.
> DMA_DeInit(DMA1_Stream0);
> //bzw.
> DMA_DeInit(DMA1_Stream7);
> aufrufen.

Klingt nicht sehr überzeugend, denn nach einem Kaltstart bzw
Reset sollte man eigentlich den De-Init Zustand haben - so
wie du es selbst zitierst.

Sieht eher danach aus als ob dein Programm noch etwas anderes
mit den Registern bezüglich DMA macht.

Ansonsten wäre das ja eine Macke im STM-Chip wenn man
vorher per Software resetten muss .....

[Darth Moan (Gast)]

Moin,

ich moechte an dieser Stelle einen gut gemeinten Rat zum Besten geben.
Wenn deine Hauptschleife nicht den SPI Status prueft, weil du das nicht
moechtest, dann sollte deine send-Funktion dies auf jeden Fall tun! Und
eine re-initialisierung der SPI oder DMA ablehnen, wenn der Transfer
noch laeuft. Die Warteschleife, die nichts tut, ausser warten, kann von
einem agressieven Optimierer schonmal komplett rausgeschmissen werden.
Das kann man in Variablen halten und im RX-DMA Interrupt entsprechend
auf "finished" setzen, oder direkt den CS GPIO zuruecklesen.
Wenn man einen DMA Transfer neu "konfigurieren" will (adresse, laenge)
sollte man vorher den DMA disablen. Ich habe den F407 am start, aber
ich glaube dass ist bei deinem 205 das gleiche.

sieht bei mir etwa so aus (nach dem tarnsfer complete check):

    GPIOB->BSRRH = GPIO_PIN_12;

    DMA1_Stream4->CR &=  ~DMA_SxCR_EN;
    DMA1_Stream3->CR &=  ~DMA_SxCR_EN;

    DMA1->HIFCR = (DMA_HIFCR_CTCIF4 | DMA_HIFCR_CHTIF4 | DMA_HIFCR_CTEIF4 | DMA_HIFCR_CDMEIF4 | DMA_HIFCR_CFEIF4 );
    DMA1->LIFCR = (DMA_LIFCR_CTCIF3 | DMA_LIFCR_CHTIF3 | DMA_LIFCR_CTEIF3 | DMA_LIFCR_CDMEIF3 | DMA_LIFCR_CFEIF3 );


    DMA1_Stream4->CR  = ( DMA_SxCR_PL_1 | DMA_SxCR_MSIZE_0 | DMA_SxCR_PSIZE_0 | DMA_SxCR_MINC | DMA_SxCR_DIR_0  );
    DMA1_Stream3->CR  = ( DMA_SxCR_PL_1 | DMA_SxCR_MSIZE_0 | DMA_SxCR_PSIZE_0 | DMA_SxCR_MINC );

    DMA1_Stream4->NDTR = Len;
    DMA1_Stream3->NDTR = Len;

    DMA1_Stream4->PAR  = (uint32_t)&(SPI2->DR);
    DMA1_Stream3->PAR  = (uint32_t)&(SPI2->DR);
    DMA1_Stream4->M0AR = (uint32_t)MsgPtr;
    DMA1_Stream3->M0AR = (uint32_t)RXBuf;

    DMA1_Stream4->FCR &= (~(DMA_SxFCR_FEIE | DMA_SxFCR_DMDIS));
    DMA1_Stream3->FCR &= (~(DMA_SxFCR_FEIE | DMA_SxFCR_DMDIS));

    DMA1_Stream3->CR  |=  DMA_SxCR_EN;
    DMA1_Stream4->CR  |=  DMA_SxCR_EN;