Komisches Verhalten des SPI [STM32]

[Tobias P. (hubertus)]

Moin moin,

ich habe ein komisches Problem mit dem SPI des STM32F407. Und zwar habe 
ich eine ADC am SPI angeschlossen (und zwar einen ADS8320). Diesen 
versuche ich auszulesen, was allerdings nicht reproduzierbar klappt.

Ich habe euch mal einen Screenshot vom Oskar angehangen. Man sieht auf 
den 3 Kanälen von oben nach unten:

Chip Select
Clock
Daten.

Meiner Meinung nach wird nun bei dieser SPI-Übertragung gemäss den 
Signalverläufen auf dem Oszilloskop das Datenwort

11111001 11111111 00011111

übertragen. Im Screenshot von menem Debugger könnt ihr aber sehen, dass 
der STM32 das Datenwort

11111000 11111111 00011111

empfängt. Aus einer 1 ist also plötzlich eine 0 geworden! Wie kann das 
sein?

Mein Code zum Auslesen des ADC ist wie folgt:

static uint32_t spi_write_dac(uint16_t data)
{
  uint32_t ret = 0;



  /* wait until the transmit buffer is empty */
  while((SPI1_SR & BIT_01) == 0);

  /* dummy write and wait until the transmit buffer is empty */
  SPI1_DR = 0;

  /* wait until the receive buffer is not empty, then read the received data */
  while((SPI1_SR & BIT_00) == 0);
  ret = SPI1_DR;
  ret = ret << 8;

  while((SPI1_SR & BIT_01) == 0);

  /* transmit the msb */
  SPI1_DR = (data >> 8);

  /* wait until the receive buffer is not empty, then read the received data */
  while((SPI1_SR & BIT_00) == 0);
  ret = ret | SPI1_DR;
  ret = ret << 8;

  while((SPI1_SR & BIT_01) == 0);

  /* transmit the lsb */
  SPI1_DR = data;

  /* wait until the receive buffer is not empty, then read the received data */
  while((SPI1_SR & BIT_00) == 0);
  ret = ret | SPI1_DR;

  return ret;
}

Am selben SPI-Interface hängt noch ein DAC, der mit der selben routine 
angesteuert wird (man schreibt also auf den DAC und liest gleichzeitig 
den ADC aus).

Warum liest mein STM32 manchmal eine 0 statt einer 1? Ich muss dazu noch 
sagen, dass die Lesefunktion manchmal funktioniert, manchmal allerdings 
nicht, allerdings ist das nicht reproduzierbar. Ich habe schon alles 
versucht: niedrigere Baudrate, andere CPOL/CPHA sowie Interrupts 
deaktivieren - nichts hilft....


Edit: sorry, falschen Screenshot angehanden vom Oszi. Der richtige ist 
"oszi_richtig.jpg" :-) Vielleicht löscht ein Mod netterweise den 
falschen.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Tobias P. schrieb:
> Warum liest mein STM32 manchmal eine 0 statt einer 1?
Geht in Richtung "falscher SPI-Modus": vermutlich tastest du an der 
MISO-Flanke ab und nicht dann, wenn MISO stabil ist...

> Ich habe schon alles versucht: niedrigere Baudrate, andere CPOL/CPHA
> sowie Interrupts deaktivieren - nichts hilft....
Wieso "probiert"? Das kann man doch einfach einstellen. Du brauchst 
SPI-Mode 0 oder 3 um stabile Werte zu bekommen. Und der Unterschied 
zwischen 0 oder 3 ist dann nur noch, ob du ein Bit verschoben bist oder 
nicht...

[Uwe B. (Firma: TU Darmstadt) (uwebonnes)]

Eine Stolperfalle kann auch das zu schnelle Abschalten des SPI sein. Es 
langt nicht, auf das Herausschieben des letzten Bits zu warten. Du musst 
warten, bis Dir das Receive Register den Empfang des letzten Wortes 
meldet. Erst dann darfst Du abschalten.

[Little B. (lil-b)]

Die Leseroutine alleins hilft an der Stelle nicht weiter, zeig bitte 
deine Init-Routine des SPI.

Nach händischem Dekodieren des Oszilloskops scheint dein ADC 0x7FC7 zu 
liefern.

Der SPI muss für diesen ADC auf folgende Configs eingestellt werden:
- Clock Idle High
- Data Sample on Second Edge
- min 24kHz, max 2,4MHz

Das Protokoll sieht dann so aus:
- Die ersten 5 bit wegwerfen, Sample-Zeit
- Das 6. bit ist immer 0
- die darauf folgenden 16 bit sind die Daten mit MSb first

Siehe Seite 10 des ADC-Datenblattes

[Tobias P. (hubertus)]

O.K. meine Init sieht wie folgt aus:

  /* spi1 power on */
  RCC_APB2ENR |= BIT_12;

  /* select 8 bit frame length, 1.25MHz clock, master mode */
  SPI1_CR1 = (BIT_09 | BIT_08 | (4u << 3) | BIT_02);

  /* disable all interrupts, disable ss output */
  SPI1_CR2 = 0;

  /* enable the spi */
  SPI1_CR1 |= BIT_06;

Testweise habe ich den Vorteiler schon erhöht auf 7 (entspricht Teilung 
durch 256), das hat aber auch keine Abhilfe gebracht. Was ich allerdings 
jetzt sehe: Die Leseroutine scheint ein Problem zu haben mit dem 1. 
Byte, das übertragen wird. Der Rest ist immer richtig, nur beim 1. Byte 
kann das LSB fälschlicherweise als 0 gelesen werden :-( ich seh den 
Fehler echt nicht.

[Little B. (lil-b)]

Mit

SPI1_CR2 = 0;

schreibst du das frame format auf Motorola. Was dann in

SPI1_CR1[1:0]

steht, weiß kein Mensch. Schreibe diese bits anschließend noch auf 0b11, 
um die spezifikationen des ADCs zu erfüllen. Wie aber der DAC darauf 
reagiert, kann ich dir erst sagen, wenn du diesen genauer bezeichnest.

Sicher, dass dein APB1 nur mit 10MHz taktet? Normal taktet der auf 
maximaler Geschwindigkeit mit 42MHz. Dann wäre deine Baudrate deutlich 
zu hoch. Versuch mal

(5u << 3)

Dann musst du die Daten nur noch richtig interpretieren.

[Tobias P. (hubertus)]

Der DAC ist ein DAC8501. Also auch 16 Bits.

Aber ich habe das Problem jetzt eingrenzen können. Ich habe testweise 
mal den Output Port Speed auf maximal gesetz (GPIOx_OSPEEDR). Damit 
funktioniert es. Anscheinend sind die Flanken für den ADC sonst zu lahm 
(?).

Mein APB1 sollte eigentlich mit 40 MHz laufen ... :-)

[Little B. (lil-b)]

tja, blöd, der DAC und der ADC haben verschiedene Frame Formate.

(DAC sampled auf falling edge, ADC auf rising edge)

Beide an dem selben Bus zu betreiben wird nicht möglich sein.

[Tobias P. (hubertus)]

Hmm kann ich das u.U. noch reparieren durch Zuschalten eines kleinen 
Inverters in die Taktleitung?
komischerweise hat es ja jetzt zwar funktioniert.

und, im ADC Datenblatt heisst es:
However, if the minimum hold time for DOUT is acceptable, the
system can use the falling edge of DCLOCK to capture each
bit.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Little B. schrieb:
> tja, blöd, der DAC und der ADC haben verschiedene Frame Formate.
> (DAC sampled auf falling edge, ADC auf rising edge)
> Beide an dem selben Bus zu betreiben wird nicht möglich sein.
Man kann den SPI-Modus einfach zwischendurch umschalten...

Tobias P. schrieb:
> Ich habe testweise mal den Output Port Speed auf maximal gesetz
> (GPIOx_OSPEEDR). Damit funktioniert es. Anscheinend sind die Flanken für
> den ADC sonst zu lahm (?).
Damit schiebst du einfach den Abtastzeitpunkt oder das Weitertakten um 
ein paar ns in die "richtige" Richtung. Es ist nach wie vor eine 
wacklige Sache. Mach die Bauteile mal heiß oder kalt...

[Tobias P. (hubertus)]

Hi Lothar,

ja, ist mir klar, habs jetzt auch gesehen. Wobei im Datenblatt steht, 
dass es erlaubt sei, auch auf die fallende Flanke zu sampeln, wenn die 
Holdzeit von 5 ns genügt. Im STM32 Datenblatt heisst es, dass die 
Holdzeit 2ns betragen soll - was im Prinzip also  geht.

Auf meinem PCB habe ich aber noch die Möglichkeit, einen kleinen 
Inverter in die Clockleitung vom ADC zu schalten. Damit könnte es gehen, 
oder nicht?