Forum: Mikrocontroller und Digitale Elektronik SPI Controller triggert im Slave Mode auf falscher Flanke


von Andre B. (Firma: FH-Münster) (andre_buss)


Lesenswert?

Hallo Gemeinde

Ich habe ein Demoboard UMFT4222EV von FTDI mit der Revision C. Dieses 
will ich im Slave-Mode betreiben, zur Kommunikation zwischen Computer 
und Atmega16. Mir ist aufgefallen, dass der MISO-Kanal auf der falschen 
Flanke getriggert wird, also z.B. im SPI-Mode 0 auf der steigenden 
Flanke statt auf der abfallenden.

Getestet wird das Board momentan auf einem Breadboard im Self-Powered 
Modus mit einem Frequenzgenerator zur Erzeugung der Clock. Weiter ist 
nur eine Auswerteelektronik (Oszi) angeschlossen. Es sind die 
unterschiedlichen SPI-Modies getestet worden, es zeigt sich bei allen, 
dass der MISO auf der falschen Flanke getriggert wird. Dies ist bei 
hohen (2MHz) und auch bei niedrigen (50kHz) SPI-Clock raten gleich. Der 
FT4222 ist auch mit unterschiedlichen Tacktfrequenzen getestet worden. 
Angesteuert wird der FT4222 über eine Python Lib, die auf die Hersteller 
DLL zugreift. Es ist auch der Master-Mode getestet worden. Hier zeigen 
sich keine Fehler im MOSI-Kanal.

Ich habe bereits Kontakt mit dem technischen Support von FTDI 
hergestellt. Deren Antworten sind leider nur: Bitte lese die Dokus, 
Beispiel Programme und verwende die neuste DLL. Da wir maximal 5 Chips 
im Jahr von denen abnehmen ist deren Zurückhaltung nicht groß 
verwunderlich.

Vielleicht hat hier jemand ähnliche Probleme gehabt oder jemand der mir 
mit interessanten Ideen weiter helfen kann.

LG
Andre

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Andre B. schrieb:
> dass der MISO-Kanal auf der falschen Flanke getriggert wird
Definiere "getriggert".

> Es sind die unterschiedlichen SPI-Modies getestet worden, es zeigt sich
> bei allen, dass der MISO auf der falschen Flanke getriggert wird.
Es kann aber auch sein, dass du da die falsche Vorstellung hast, was 
beim SPI bei welcher Flanke bei welchem Teilnehmer zu passieren hat. So 
war das bei mir bisher immer...

: Bearbeitet durch Moderator
von Falk B. (falk)


Lesenswert?

Andre B. schrieb:

> und Atmega16. Mir ist aufgefallen, dass der MISO-Kanal auf der falschen
> Flanke getriggert wird, also z.B. im SPI-Mode 0 auf der steigenden
> Flanke statt auf der abfallenden.

Wie hast du das festgestellt? Bei SPI wird nichts getriggert, da werden 
nur Daten auf einer Flanke ausgegeben und bei der anderen abgetastet.

> Getestet wird das Board momentan auf einem Breadboard im Self-Powered
> Modus mit einem Frequenzgenerator zur Erzeugung der Clock.

Soso, der clock.

> Weiter ist
> nur eine Auswerteelektronik (Oszi) angeschlossen.

Und was willst du da testen? Müßte man da nicht Daten erzeugen und 
diesen am PC prüfen, ob sie korrekt empfangen wurden?

> hergestellt. Deren Antworten sind leider nur: Bitte lese die Dokus,
> Beispiel Programme und verwende die neuste DLL.

Vermutlich haben sie recht.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Andre B. schrieb:
> Getestet wird das Board momentan auf einem Breadboard im Self-Powered
> Modus mit einem Frequenzgenerator zur Erzeugung der Clock. Weiter ist
> nur eine Auswerteelektronik (Oszi) angeschlossen.
Einen SPI Slave kannst du eigentlich nur sinnvoll testen, wenn er 
Signale von einem Master bekommt, oder wie?

Oder ist der Baustein spezifiziert, allein mit einem Takt ganz ohne SS# 
irgendwas Sinnvolles zu machen?

: Bearbeitet durch Moderator
von Hardy (Gast)


Lesenswert?

> Mir ist aufgefallen, dass der MISO-Kanal auf der falschen Flanke ...

Wie hast du das genau festgestellt (Oszillogramm etc. posten)?

von Andre B. (Firma: FH-Münster) (andre_buss)


Angehängte Dateien:

Lesenswert?

Mit getriggert meine ich bei z.B. SPI-Mode 0, dass bei der abfallenden 
Flanke das Signal auf HIGH oder LOW gesetzt wird und bei der steigenden 
Flanke wird dann gemessen. Bei mir ist das falsch herum siehe Oszi-Bild.

Ich kann das einfach so, ohne MOSI Signal und "ohne" SS (SS liegt zum 
anwählen des Slaves auf GND), testen, da ich mir nur die Flanken 
anschaue.

In der echten Anwendung werden die richtigen Signale teilweise erkannt, 
das hängt von der Latenz zwischen Clock und triggern des Signals ab. 
Wenn die Latenz quasi Null ist wird das Signal vom Master richtig 
erkannt. Bei Latenzen von wenigen ns (ca. 10ns oder 12ns) liest der 
Master natürlich einen falschen Wert.

von Andre B. (Firma: FH-Münster) (andre_buss)


Angehängte Dateien:

Lesenswert?

Ich hab auch in der echten Anwendung einen Logic-Analyser mitlaufen 
lassen. Ein Bild dazu hab ich hier angehängt.

Da ist schön zu sehen, dass der MOSI das Signal auf der fallenden Flanke 
triggert und der MISO auf die steigende. Dies fürht halt dazu, dass der 
Computer den Atmel versteht der Atmel aber den Computer nicht.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Andre B. schrieb:
> Da ist schön zu sehen, dass der MOSI das Signal auf der fallenden Flanke
> triggert und der MISO auf die steigende.
Sieht für mich gut aus, wenn die Daten vom Master mit der fallenden 
Flanke gelesen werden.
Dann gibt eben der Master sofort nach der fallenden Taktflanke die 
nächsten Daten aus (zoome da mal deutlich rein), der Slave erst bei der 
steigenden Flanke.

[EDIT: steigend und fallend waren vertauscht]

: Bearbeitet durch Moderator
von Andre B. (Firma: FH-Münster) (andre_buss)


Lesenswert?

Ja genau das mit dem reinzoomen ist die Sache. Das Signal wird für 
gewöhnlich etwa 10ns nach der Clock erzeugt. Das führt dann halt zu dem 
Fehler, dass eher selten der richtige Wert übertragen wird.

In dem Bild oben vom Logic-Analyser sollte der übertragende Wert 21 
(10101) sein statt 45 (101101).

Edit:
Es gibt ja eine SPI-Spezifikation die sagt, mit welcher Flanke wann 
gelesen wird und hier wird vom Slave dagegen verstoßen.

Die Frage ist ja wie ich das berichtigen kann.

: Bearbeitet durch User
von Peter D. (peda)


Lesenswert?

Andre B. schrieb:
> Da ist schön zu sehen, dass der MOSI das Signal auf der fallenden Flanke
> triggert und der MISO auf die steigende. Dies fürht halt dazu, dass der
> Computer den Atmel versteht der Atmel aber den Computer nicht.

Ja, das Bild sieht vollkommen korrekt aus. Und das muß der AVR auch 
verstehen. Wenn sich der AVR nicht SPI-konform verhalten würde, hätte 
das bestimmt schon jemand bemerkt.

Oder meinst Du, daß der AVR Master und der FTDI Slave ist?
Kann gut, daß das wirklich noch niemand getestet hat. In der Regel macht 
man immer die komplexere CPU zum Master.

von Andre B. (Firma: FH-Münster) (andre_buss)


Lesenswert?

Der FTDI ist der Slave und der AVR der Master.

Ich kann nur den AVR als Master machen, da ich für die weitere Schaltung 
bestimmte Tacktzeiten einhalten muss.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Andre B. schrieb:
> Es gibt ja eine SPI-Spezifikation die sagt, mit welcher Flanke wann
> gelesen wird und hier wird vom Slave dagegen verstoßen.
Ich sehe da keinen "Verstoß".

> Die Frage ist ja wie ich das berichtigen kann.
Den richtigen SPI Mode verwenden.
Der Master muß hier auf der fallenden Flanke samplen. Der Slave gibt mit 
der steigenden Flanke den Takt aus.
Es muss also Mode 1 oder 2 sein:
http://www.lothar-miller.de/s9y/archives/15-SPI.html
Beim falschen dieser beiden sind die Daten um 1 Bit verschoben.

von Andre B. (Firma: FH-Münster) (andre_buss)


Lesenswert?

Die Idee ist mir auch schon gekommen. Das Funktioniert auch für den MISO 
allerdings wird dann der MOSI auf der falschen Flanke gelesen was dann 
natürlich dazu führt, dass der Slave den Master nicht mehr versteht. Und 
vor jedem Lesen- oder Schreibvorgang den SPI-Mode zu ändern ist keine 
Option für mich. Ganz davon abgesehen, dass lesen und schreiben 
instantan funktioniert.

Zum Thema Verstoß:
FTDI hat in deren Dokumentation beschrieben bei welchen Modi wann 
gelesen und getriggert wird. Das ist auch konform zur allgemeinen 
SPI-Spezifikation. Das Demoboard triggert aber im Slave-Mode den MISO 
auf die falsche Flanke und das führt zu Fehlern.

von Wolfgang (Gast)


Lesenswert?

Andre B. schrieb:
> Und vor jedem Lesen- oder Schreibvorgang den SPI-Mode zu ändern ist keine
> Option für mich. Ganz davon abgesehen, dass lesen und schreiben
> instantan funktioniert.

Bei SPI gibt es im eigentlichen Sinne kein "Lesen" und "Schreiben".
Bei der Übertragung werden grundsätzlich Bytes zwischen Master und Slave 
ausgetauscht. Wie die Bytes zu bewerten sind, entscheidet eine höhere 
Software Schicht. Das ist aber unabhängig von der Aktion auf dem Bus.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Andre B. schrieb:
> Das Demoboard triggert aber im Slave-Mode den MISO auf die falsche Flanke
Wurde eigentlich schon mal erwähnt, dass da beim SPI gar nichts 
"triggert"?
Der Slave FT4222 gibt am MISO die Daten aus, die dann mit der fallenden 
Flanke gelesen werden müssen. Was ist daran falsch? Du hast den selber 
so konfiguriert, der könnte laut Datenblatt je nach Konfigurationsbits 
auch alle anderen SPI-Modes:
1
5.2.3
2
SCK Format
3
Software can select any of four combinations of serial clock (SCK) phase and polarity.
Welchen SPI-Mode hast du da eingestellt?

> und das führt zu Fehlern.
Und was sind das für "Fehler"?
Sendet der FT4222 den richtigen Wert (das kann man ja mal mit dem 
Logikanalyzer kontrollieren)?
Liest der Master verglichen mit dem Logikanalyzer beliebige andere 
Daten?
Sind die vom Master gelesenen Daten um 1 Bit versetzt?

Ich denke nach wie vor, dass du einfach nur den falschen SPI-Modus 
verwendest. Bei mir war das bisher immer der Fall. Geh die nächste Woche 
einfach davon aus, dass die FTDI-Jungs diese Schnittstelle getestet 
haben, das Timing zum Datenblatt passt und der Fehler bei dir liegt.

Andre B. schrieb:
> Ich kann nur den AVR als Master machen, da ich für die weitere Schaltung
> bestimmte Tacktzeiten einhalten muss.
Kann ich nicht ganz nachvollziehen, dass du da einen so engen Schuh 
anziehen musst...

: Bearbeitet durch Moderator
von Andre B. (Firma: FH-Münster) (andre_buss)


Angehängte Dateien:

Lesenswert?

Was ich unter triggern verstehe habe ich oben schon mal erwähnt. Ich 
verwende das Wort weil ich zu faul bin um zu schreiben: wird an der 
Flanke auf HIGH oder LOW gesetzt (was nach meines erachtens gut als 
triggern bezeichnet werden kann).

Ich wende mich hier an die breite Masse, weil ich das Problem vor etwa 4 
Wochen erkannt habe. Ich habe mit mehreren Fachkundigen Leuten darüber 
gesprochen und die geben mir alle recht, dass das MISO Signal auf der 
falschen Flanke erzeugt wird, um mal nicht getriggert zu sagen. Ich bin 
nicht der Meinung, dass der Fehler nicht bei mir liegt aber genauso 
wenig, dass der Fehler nicht beim Chip liegt. Für meinen Teil habe ich 
die unterschiedlichen Dokus von FTDI teilweise öfters gelesen und kann 
keinen Fehler in der Schaltung oder im Programm finden.

Ich habe auch alle SPI-Modus "Paarungen" getestet. Dabei stellt sich 
sinnvollerweise heraus, dass der Modus bei den unterschiedlichen 
SPI-Teilnehmern gleich sein muss, damit die sich verstehen.

Um mein Anliegen nochmal etwas zu verdeutlichen haben ich in dem Bild 
vom Logic-Analyser etwas herum gemalt. Meine Paintskills sind nicht 
gerade die besten aber ich hoffe das es zum Verständnis Hilft.

Die Annahme, dass das Signal etwa 10ns nach der Clock erzeugt wird ist 
nicht geraten sonder gemessen. Diese Latenz erstreckt sich zwischen 
"0ns" (wenig genug, dass der Master einen falschen Wert liest) und etwa 
12ns.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Nur, dass da mal ein Außenstehender die selben Voraussetzungen hat: mit 
welchen CPOL/CPHA Einstellungen beim Slave FT4222 wurden denn die Bilder 
da gemacht?

Andre B. schrieb:
> Ich verwende das Wort weil ich zu faul bin um zu schreiben: wird an der
> Flanke auf HIGH oder LOW gesetzt (was nach meines erachtens gut als
> triggern bezeichnet werden kann).
Faulheit hin oder her: du verwendest ganz einfach das falsche Wort. Für 
SPI haben die beiden Flanken schon einen Namen, denn die eine ist dies 
Schiebeflanke (theoretisch) und die andere die Sampleflanke. Wobei die 
zweitere auch gern zum Schieben verwendet wird, sodass erst gesamplet 
und mit der selben Flanke auch gleich geschoben wird.

von c-hater (Gast)


Lesenswert?

Andre B. schrieb:

> Ich wende mich hier an die breite Masse, weil ich das Problem vor etwa 4
> Wochen erkannt habe.

Nein, hast du nicht. Du glaubst das nur, das aber so richtig fest...

> Ich habe mit mehreren Fachkundigen Leuten darüber
> gesprochen und die geben mir alle recht, dass das MISO Signal auf der
> falschen Flanke erzeugt wird, um mal nicht getriggert zu sagen.

Das mag sein. Bedeutet aber auch dann nur: du hast offensichtlich den 
falschen SPI-Mode gewählt, nix anderes.
Auf welchen Flanken beim AVR8-SPI was geschieht, steht für jeden 
einzelnen der vier möglichen Modi haarklein im DB beschrieben. Und die 
Hardware verhält sich exakt so, wie im DB beschrieben. Wäre es nicht so, 
hätte das in der langen Zeit der Existenz der AVR8-SPI-Engine sicher 
schon mal jemand bemerkt...

> Ich bin
> nicht der Meinung, dass der Fehler nicht bei mir liegt

Dann dann ist ja alles gut. Korrigere also einfach deinen Fehler.

Spannend wäre übrigens, auch mal ein DB der Gegenstelle zu lesen. Darin 
sollte zumindest dokumentiert sein, was diese eigentlich erwartet...

von Einer K. (Gast)


Lesenswert?

Offensichtlich ist dir so einiges durch die Lappen gegangen...

c-hater schrieb:
> Auf welchen Flanken beim AVR8-SPI was geschieht, steht für jeden
> einzelnen der vier möglichen Modi haarklein im DB beschrieben.
Nein, es dreht sich nicht um den AVR!


c-hater schrieb:
> Spannend wäre übrigens, auch mal ein DB der Gegenstelle zu lesen. Darin
> sollte zumindest dokumentiert sein, was diese eigentlich erwartet...
Was hindert dich?

Tipp:
Es dreht sich um den UMFT4222EV

von Andre B. (Firma: FH-Münster) (andre_buss)


Lesenswert?

Das Bild ist wie der Name schon verrät im SPI-Mode 0 entstanden also 
CPOL=0 und CPHA=0.

Auf Wunsch kann ich auch mit Bildern von Mode 1, 2 und 3 dienen.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Andre B. schrieb:
> Das Bild ist wie der Name schon verrät im SPI-Mode 0 entstanden also
> CPOL=0 und CPHA=0.
Welcher Teilnehmer hat da den Mode 0? Master und Slave? Was passiert, 
wenn du Master im Mode 0 lässt, aber im Slave mal die anderen 3 Modi 
durchprobiert?

> Auf Wunsch kann ich auch mit Bildern von Mode 1, 2 und 3 dienen.
Mach das bitte mal, und schreibe beim Mode 1 und 2 dazu, wie CPOL und 
CPHA gesetzt sind.

: Bearbeitet durch Moderator
von Peter D. (peda)


Lesenswert?

Andre B. schrieb:
> Mir ist aufgefallen, dass der MISO-Kanal auf der falschen
> Flanke getriggert wird

Auf welcher Flanke der Slave das MISO ausgibt, läßt sich doch auf dem 
Oszibild sehen und das sieht vollkommen korrekt aus. Ebenso sieht das 
MOSI, daß der AVR sendet, korrekt aus. Und wann der AVR-Master das MISO 
einliest, sollte auch stimmen, da gehe ich mal davon aus, daß das 
AVR-Datenblatt korrekt ist.
Bleibt also nur die Frage übrig, wann der FTDI-Slave das MOSI einliest.
Auf Deinem Bild wird MOSI mit der fallenden Flanke gesendet, d.h. der 
Slave muß es mit der steigenden Flanke einlesen. Um das zu prüfen, kann 
man das SCK mit einem Monoflop (74HC123) verzögern. Der Monoflop 
triggert auf der steigenden Flanke und erzeugt die fallende Flanke nach 
0,25..0,75 Bitzeit. Liest der Slave richtig ein, so wird immer das 
gleiche Byte empfangen.
Liest er aber auf der fallenden Flanke ein, ergibt sich, je nach 
Verzögerung des Monoflops, das Byte um ein Bit verschoben.

: Bearbeitet durch User
von ich (Gast)


Lesenswert?

Peter D. schrieb:
> Auf welcher Flanke der Slave das MISO ausgibt, läßt sich doch auf dem
> Oszibild sehen und das sieht vollkommen korrekt aus.

sehe ich nicht so. Der Master fährt eindeutig Mode 0 (setup bei 
fallender Flanke).
Der Slave hat sein setup aber zur steigenden Flanke. Das passt definitiv 
nicht zusammen.

Entweder der FTDI arbeitet im falschen SPI Mode (1 oder 2), oder dessen 
CLK Eingang wird (wie auch immer) irgendwo invertiert (kann man das beim 
FTDI einstellen?).

von Peter D. (peda)


Lesenswert?

ich schrieb:
> sehe ich nicht so. Der Master fährt eindeutig Mode 0 (setup bei
> fallender Flanke).
> Der Slave hat sein setup aber zur steigenden Flanke. Das passt definitiv
> nicht zusammen.

Stimmt, beide müssen an der gleichen Flanke ihren Ausgang wechseln. 
Einer hat also den falschen Mode eingestellt.
Ist auch schön im AVR-Datenblatt zu sehen, in Mode 0 wechseln beide an 
der fallenden Flanke und samplen an der steigenden.

von Andre B. (Firma: FH-Münster) (andre_buss)



Lesenswert?

Ich lade hier einfach mal alle Bilder hoch die ich zu dem Thema gemacht 
habe. Die mit der Endung _App sind aus der realen Applikation 
aufgenommen. Die anderen sind auf dem Breadboard mit einem 
Frequenzgenerator als Clock entstanden. Das mit der Endung _Pico ist mit 
nem Oszi auf dem Beardboard aufgenommen.

Zu den Modes:
Mode 0: CPOL=0, CPHA=0
Mode 1: CPOL=0, CPHA=1
Mode 2: CPOL=1, CPHA=0
Mode 3: CPOL=1, CPHA=1

@ Peter:
Wir hatten auch schon mal die Idee zu verzögern allerdings nur den MISO 
um eine halbe SCK. Mir war da, dass mir dabei 1 Bit verloren gehen 
würde, aber ich denke da noch mal drüber nach.

von Andre B. (Firma: FH-Münster) (andre_buss)


Lesenswert?

@Peter:
Ja die Vermutung mit der Flanke kommt sehr schnell auf. Ich habe den 
Slave mit allen Modes (unterschiedlich zum Master) ausprobiert, es gibt 
Einstellungen ich glaube Mode 3 (also Master Mode 0, Slave Mode 3) dann 
versteht der Master den Slave aber der Slave versteht dann den Master 
nicht mehr.

von Andre B. (Firma: FH-Münster) (andre_buss)


Lesenswert?

Ich habe noch mal die Errata Technical Note von FTDI gelesen. Wir sind 
uns nicht sicher ober dies hier unser Problem ist. Vielleicht hat einer 
von euch schon öfter solche Fehlerberichte gelesen und kann das besser 
einschätzen.

3.3.4 SPI Slave Data Lost
Issue
When operating in SPI Slave mode, the FT4222H would occasionally loose 
data packets.
Workaround
Verified that the latency Timer configuration was not correct, hence 
causing no full packet responses,
instead all packets responded with short packets. This results in packet 
drops with D2XX driver.
No workaround was provided, this issue is corrected at revision D.

von Clemens L. (c_l)


Lesenswert?

Andre B. schrieb:
> 3.3.4 SPI Slave Data Lost Issue

Da geht es um USB-Pakete.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.