ARM Cortex M3 (ATSAM3S4B) - SPI mit PDC (DMA-Controller)

[Dieter (Gast)]

Hallo,

ich bin gerade dabei, eine SPI-Kommunikation mit zwei gleichen 
Controllern aufzubauen (Vollduplex). Der Controller-Typ ist ein ARM 
Cortex M3 von Atmel (ATSAM3S4B).

Da die Übertragungsgeschwindigkeit ca. 10 MBit beträgt, möchte ich die 
zu übertragenden Daten mit Hilfe des PDC (DMA-Controller) übertragen.


Die SPI-Kommunikation mit PDC funktioniert soweit schon, jedoch habe ich 
noch ein Problem:

Die übertragenen Daten kommen beim Slave verschoben an:
Es werden 16 Bytes übertragen, wobei das erste Byte das letzte Byte der 
vorherigen Übertragung ist.

Es sieht danach aus, dass nach Senden (Master) des letzten Bytes dieses 
im Slave im Empfangsregister (RDR) bleibt und nicht durch den PDC in den 
Speicher übertragen wird.
Mit einem Oszilloskop wurde die gesamte SPI-Übertragung analysiert und 
festgestellt, dass die Daten richtig gesendet werden. Somit liegt das 
Problem höchstwahrscheinlich beim PDC.


Die Themen zu SPI und PDC aus dem Datenblatt kenne ich schon auswendig, 
komme jedoch trotzdem nicht weiter, wobei diese auch nur knapp 
beschrieben sind.



Hat jemand auch solche oder ähnliche Probleme gehabt oder kennt das 
Problem?



Dieter

[SeriousSam (Gast)]

Ich würde auf eine falsch konfigurierte Einstellung der 
Polarität/Phase/Selects tippen.

[Dieter (Gast)]

Hallo,

Danke für die Antwort.
Natürlich habe ich die SPI-Modes vorher überprüft und
ausgiebig getestet - leider ohne Erfolg.


Hier erstmal noch ein paar weitere Infos:

Die beiden Controller laufen mit 64 MHz und die SPI-Geschwindigkeit 
beträgt 10,6 MBit.
Es werden 16 Bytes gesendet und empfangen. Die zu sendenden Testdaten 
sehen wie folgt aus (Master und Slave):

Oberes Nibble   = Byte-Nummer (0x0 bis 0xF)
Unteres Nibble  = Testzähler  (0x0 bis 0xF)

Dadurch können die einzelnen Bytes in der Position genau zugeordnet 
werden (Senden und Empfangen beim Master und Slave).





Zum SPI-Master:
Auf dem Master läuft der SysTick-Interrupt, der alle 125 µs ausgeführt 
wird. In der Interrupt Service Routine wird der PDC zyklisch gestartet 
und somit die SPI-Kommunikation ausgelöst.


Nachfolgend einige Codeausschnitte:


SysTick-Interrupt Master:

void SysTick_Handler (void)
{
  SPI->SPI_PTCR = (SPI_PTCR_TXTEN | SPI_PTCR_RXTEN);    // DMA enable
  
  
  while(!(SPI->SPI_SR & SPI_SR_ENDTX)){}
  SPI->SPI_PTCR = SPI_PTCR_TXTDIS;        // DMA-Transmit disable
  
  while(!(SPI->SPI_SR & SPI_SR_ENDRX)){}
  SPI->SPI_PTCR = SPI_PTCR_RXTDIS;        // DMA-Receive disable
  
  
  
  SPI->SPI_TPR = &spi_tx_buffer;
  SPI->SPI_TCR = sizeof(spi_tx_buffer);

  SPI->SPI_RPR = &spi_rx_buffer;
  SPI->SPI_RCR = sizeof(spi_rx_buffer);
  

  
  for (uint8_t i=0; i<sizeof(spi_tx_buffer); i++)      // Sendedaten aktualisieren
  {
    spi_tx_buffer[i] &= 0xF0;
    spi_tx_buffer[i] |= (testZaehler & 0x0F);
  }
  testZaehler++;
}

Hier die SPI-Konfiguration des Masters:

void SPI_init_Master (void)
{
  // --- Parallel Input/Output Controller A ---
  PIOA->PIO_WPMR = PIO_WPMR_WPKEY_PASSWD;                              // Disables the Write Protect (PIOA)
  PIOA->PIO_ABCDSR[0] &= ~(PIO_ABCDSR_P11 | PIO_ABCDSR_P12 | PIO_ABCDSR_P13 | PIO_ABCDSR_P14);  // Peripheral Select A: NSS, MISO, MOSI, SPCK
  PIOA->PIO_ABCDSR[1] &= ~(PIO_ABCDSR_P11 | PIO_ABCDSR_P12 | PIO_ABCDSR_P13 | PIO_ABCDSR_P14);  // Peripheral Select A: NSS, MISO, MOSI, SPCK
  PIOA->PIO_PDR = (PIO_PDR_P11 | PIO_PDR_P12 | PIO_PDR_P13 | PIO_PDR_P14);            // PIO Disable: PA11, PA12, PA13, PA14
  PIOA->PIO_PUDR = (PIO_PUDR_P11 | PIO_PUDR_P12 | PIO_PUDR_P13 | PIO_PUDR_P14);          // Disables the pull up resistor on PA11, PA12, PA13, PA14
  
  
  // --- SPI (Configuration as Master) ---
  PMC->PMC_PCER0 = PMC_PCDR0_PID21;                                // Enables the peripheral clock for SPI
  SPI->SPI_WPMR = SPI_WPMR_WPKEY_PASSWD;                              // Disables the Write Protect (SPI)
  SPI->SPI_CR = (SPI_CR_SPIDIS | SPI_CR_SWRST);                          // SPI Disable; SPI Software Reset
  SPI->SPI_MR = (SPI_MR_MSTR | SPI_MR_PCS(0xE));                           // SPI Master Mode; Peripheral Chip Select 0
  SPI->SPI_CSR[0] = (SPI_CSR_BITS_8_BIT | SPI_CSR_SCBR(0x06));
  SPI->SPI_CR = SPI_CR_SPIEN;                                    // SPI Enable
}

SPI-Slave:
Auf dem Slave läuft ebenfalls ein Interrupt mit der Frequenz von 8 kHz. 
Da die Quarze der beiden Controller nicht 100% dieselbe Frequenz haben, 
werden die Interrupts synchronisiert, wobei der Regler natürlich schon 
funktioniert.
Im Anhang ist dazu ein Oszilloskopbild dargestellt. Das gelbe Signal 
(Kanal 1) ist dabei die Dauer des PWM-Interrupts im Slave (Beim Eintritt 
in den ISR-Handler wird ein Ausgang gesetzt, beim Austritt wieder 
zurückgesetzt).

Code-Ausschnitt des PWM-Interrupts im Slave:

 void PWM_Handler(void)
{
  PIOA->PIO_SODR = PIO_SODR_P17;

   PWM->PWM_ISR1;
     

   
   SPI->SPI_TPR = &spi_tx_buffer;
   SPI->SPI_TCR = sizeof(spi_tx_buffer);
   
   SPI->SPI_RPR = &spi_rx_buffer;
   SPI->SPI_RCR = sizeof(spi_rx_buffer);
   
   SPI->SPI_PTCR = (SPI_PTCR_TXTEN | SPI_PTCR_RXTEN);
   
   
   for (uint8_t i=0; i<sizeof(spi_tx_buffer); i++)
   {
     spi_tx_buffer[i] &= 0xF0 ;
     spi_tx_buffer[i] |= (testZaehler & 0x0F);
   }
   
   testZaehler++;
   
  PIOA->PIO_CODR = PIO_CODR_P17;
   NVIC_ClearPendingIRQ(PWM_IRQn);  
}

Und hier die dazugehörige SPI-Konfiguration des Slaves:

void SPI_init_Slave (void)
{
  // --- Parallel Input/Output Controller A ---
  PIOA->PIO_WPMR = PIO_WPMR_WPKEY_PASSWD;                              // Disables the Write Protect (PIOA)
  PIOA->PIO_ABCDSR[0] &= ~(PIO_ABCDSR_P11 | PIO_ABCDSR_P12 | PIO_ABCDSR_P13 | PIO_ABCDSR_P14);  // Peripheral Select A: NSS, MISO, MOSI, SPCK
  PIOA->PIO_ABCDSR[1] &= ~(PIO_ABCDSR_P11 | PIO_ABCDSR_P12 | PIO_ABCDSR_P13 | PIO_ABCDSR_P14);  // Peripheral Select A: NSS, MISO, MOSI, SPCK
  PIOA->PIO_PDR = (PIO_PDR_P11 | PIO_PDR_P12 | PIO_PDR_P13 | PIO_PDR_P14);            // PIO Disable: PA11, PA12, PA13, PA14
  PIOA->PIO_PUDR = (PIO_PUDR_P11 | PIO_PUDR_P12 | PIO_PUDR_P13 | PIO_PUDR_P14);          // Disables the pull up resistor on PA11, PA12, PA13, PA14
  
  
  // --- SPI (Configuration as Slave) ---
  PMC->PMC_PCER0 = PMC_PCDR0_PID21;                                // Enables the peripheral clock for SPI
  SPI->SPI_WPMR = SPI_WPMR_WPKEY_PASSWD;                              // Disables the Write Protect (SPI)
  SPI->SPI_CR = (SPI_CR_SPIDIS | SPI_CR_SWRST);                          // SPI Disable; SPI Software Reset
  SPI->SPI_MR = 0x00000000;
  SPI->SPI_CSR[0] = 0x00000000;
  SPI->SPI_CR = SPI_CR_SPIEN;                                    // SPI Enable
}

Meine Frage ist jetzt, wie der PDC genau konfiguriert werden muss bzw. 
ob der Fehler (verschobene Bytes - siehe Anhang und 1. Beitrag) durch 
eine falsche Konfiguration des PDC/SPI zustande kommt oder ob die 
Reihenfolge des PDC falsch ist (PDC aktivieren, aktualisieren, 
deaktivieren).



Könnt ihr weiterhelfen? Bin für Hinweise und Tipps sehr dankbar.


Dieter

[Mirco (Gast)]

hast du schon beim atmel support angefragt? die jungs sind da relativ 
flott mit hinweisen

[Dieter (Gast)]

Hallo,

das Atmel-Supportteam hat mich nur auf das SPI/PDC Beispiel aus dem 
Atmel-Studio hingewiesen, welches mich jedoch nicht weiter gebracht hat.

Für einen weiteren Tipp wäre ich Euch wirklich dankbar!


Dieter

[Karl K. (leluno)]

Das ganze soweit verlangsamen dass du auf deinem oszi den Ablauf der 
Kommmunikation auch wirklich erkennen kannst.

Ein Problem mit Polarität/Phase ist naheliegend.

[Dieter (Gast)]

Hallo,

das dargestellte Oszillogramm sollte nur schematisch die 
SPI-Kommunikation darstellen. Bei weitern hineinzoomen kann ich die 
selben Bits wie im Sende- und Empfangsbuffer ausgelesen, feststellen.

Wenn ich mich nicht täusche, sind vier verschiedene Betriebsmodi für die 
Polarität/Phase möglich (hier mittels CPOL und NCPHA -> S. 561 aus dem 
Datenblatt: http://www.atmel.com/devices/sam3s4b.aspx?tab=documents).
Selbst bei sinnlosen ausprobieren aller dieser Betriebsmodi ist 
bestenfalls dieser Byte-Versatz enthalten. Somit dürfte dieser Fehler 
ausgeschlossen sein?!


Dieter

[Dieter (Gast)]

Hallo,

das Problem ist gelöst - hier die Erläuterung, damit alles etwas davon 
haben:


Um die empfangenen Daten zu überprüfen (siehe oben, 3. Beitrag), habe 
ich mit dem J-Link Debugger (von Segger) den Prozessor gestoppt. Das 
Senden (über SPI) wird über den PDC (DMA-Controller) gemacht, wobei 
dieser parallel zum Prozessor läuft.

Das Problem hierbei ist, dass durch den Prozessorhalt der 
Mikrocontroller-interne (Hardware)-Ablauf offensichtlich durcheinander 
gebracht wird und somit der Datenversatz entsteht.
Durch Programmierung von entsprechenden Testfunktion, bei denen auf 
einen Prozessorhalt verzichtet werden kann, wurde die Datenübertragung 
nun erfolgreich überprüft.



Dennoch, vielen Dank für die Tipps, Hinweise und Anregungen.


Dieter

[Konstantin (Gast)]

Hallo,


I think WDRBT bit in SPI_MR should be set during bidirectional SPI 
transfer with PDC. This solves our issue with wrong PCSes and maybe help 
you too.

--
Konstantin

[Jörg W. (dl8dtl) (Moderator)]

Konstantin schrieb:
> Hallo,

He did already solve the issue, and it's been related to the debugger.