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
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
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.
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
> Mir ist aufgefallen, dass der MISO-Kanal auf der falschen Flanke ...
Wie hast du das genau festgestellt (Oszillogramm etc. posten)?
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.
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.
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
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
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.
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.
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.
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.
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.
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
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.
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.
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...
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
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.
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
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
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?).
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.
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.
@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.
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.
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.