Hi, ich bastele an einer SPI Verbindung zwischen einem Freescale Microcontroler (HCS12 Familie) und einem Spartan-3 FPGA von Xilinx. Leider habe ich anhaltende Probleme mit Bitfehlern auf der Leitung, die für mich wie Übersprechen aussehen. Der FPGA ist über einen Pegelwandler mit dem Microcontroler verbunden. Die Anschlüsse sind jeweils an einer normalen Stiftleiste aufgelegt. Am FPGA 4 in Reihe und am Microcontroler 4 in einem Quadrat auf einer 2 reihigen Stiftleiste. Der FPGA fungiert dabei als SPI Master. Zum testen habe ich derzeit ein Programm auf dem Microcontroler, dass die letzten Empfangenen Daten wieder an den FPGA zurückschickt. Dieser sendet über Schalter einstellbare Werte an die MCU. Schalte ich nun die Bits vom höchstwertigsten nach unten hin an und übertrage jeweils nach dem Einstellen (der letzte Wert wird ja zurück übertragen) so kipppt jeh nach dem wie die Kabel gelegt sind ein benachbartes Bit. Dieser Effekt ist auch nach langem probieren immer wieder reproduzierbar. Werden jedoch nur Nullen von der MCU zum FPGA übertragen, so kommen alle Werte korrekt durch. Ich habe nun schon versucht die Einzeladern durch ein Flachbandkabel zu ersetzen, dass auf jeder 2ten Ader geerdet ist. Jedoch habe ich auch damit jeh nach dem wie es gerade da liegt dieses Problem. Es scheint also direkt im Bereich der Steckverbindung am Microcontroler aufzutreten. Auch zum Teil geschirmte Kabel (jeweils eine Datenleitung mit entweder SCK oder /SS zusammen) bringen keinen Erfolg. Hat jemand von euch vielleicht noch einen Rat, was ich probieren könnte um das Problem loszuwerden? Auch ein starkes herunterschalten der Taktrate verändert die Gesamtsituation nicht. Mit einem ATmega16 habe ich beim gleichen Versuchsaufbau übrigens keine Probleme. Der AT empfängt und sendet stets korrekte Werte, während hingegen alle 3 SPI Ports am Freescale (MC9S12DP512) das gleiche Verhalten zeigen. Gruß, Martin
nein Spass ... das Kabel ist ungefähr 20cm lang. Viel kürzer kann ichs auch aufgrund der Platinenanordnung nicht gestalten
@ Martin Lang (Gast) >Schalte ich nun die Bits vom höchstwertigsten nach unten hin an und >übertrage jeweils nach dem Einstellen (der letzte Wert wird ja zurück >übertragen) so kipppt jeh nach dem wie die Kabel gelegt sind ein >benachbartes Bit. Dieser Effekt ist auch nach langem probieren immer >wieder reproduzierbar. Klingt für mich wie eine falsche Einstellung der Taktphase/Taktpolarität. >Werden jedoch nur Nullen von der MCU zum FPGA übertragen, so kommen alle >Werte korrekt durch. Keine Kunst ;-) >Hat jemand von euch vielleicht noch einen Rat, was ich probieren könnte >um das Problem loszuwerden? Auch ein starkes herunterschalten der >Taktrate verändert die Gesamtsituation nicht. Logisch, wenn du gerade auf der Flanke abtastest. MfG Falk
Zu 1: Das habe schon überprüft. Wenn ich die CPHA Einstellung auf einer Seite ändere so kommt nichts korrekt durch. Zu 2: Nein. Was gemeint war ist, dass die Übertragung korrekt ist, wenn in eine Richtung nur Nullen übertragen werden. Davon abgesehen kann ich den Fehler durch Wackeln an der Verkabelung ein bzw Ausschalten. Ich hätte es nur gerne Dauerhaft stabil. Gruß, Martin
@ Martin Lang (Gast) >Davon abgesehen kann ich den Fehler durch Wackeln an der Verkabelung ein >bzw Ausschalten. Ich hätte es nur gerne Dauerhaft stabil. ??? Du hast einen Wackelkontakt!!! Stell mal ne ordentliche Kabelverbindung her. Leute gibts. MfG Falk
an Kopf pack Ich habe daran zig verschiedene neue Kabel mit ordentlichen Steckverbindern ausprobiert. Außerdem passen alle restlichen Anzeichen ganz und garnicht zu einem Wackelkontakt. Warum sorgt ein Wackelkontakt dafür, dass Daten, die auf einer Rückleitung übertragen werden, die Übertragung stören? Warum kann man jeh nach Lage der Kabel durch einfache Abschirmung mit einem Stück geerdeter Alu Folie das Problem beheben und es tritt wieder auf, soblad man die Alufolie nicht mehr erdet? Das Wackeln sorgt lediglich dafür, dass sich die Lage der Kabel verändert. Besonders an der Stelle, wo ich das Flachbandkabel getrennt hab, so dass es mit 2 2er Steckkontanten an den Microcontroler passt. Ich bastel daran nun schon seit mehreren Tagen herum und habe schon einiges ausprobiert um das Problem zu verringern. Das Flachbankabel sorgt auch schon für eine deutliche Verbesserung im Vergleich zu den Einzeladern, aber ein Wackelkontakt ist das nun sicher nicht mehr.
@ Martin Lang (Gast) >Warum sorgt ein Wackelkontakt dafür, dass Daten, die auf einer >Rückleitung übertragen werden, die Übertragung stören? Woher weisst du, in welcher Ader der Wackelkontakt ist? Und wenn er in der Masse ist, na dann Prost. >Warum kann man jeh nach Lage der Kabel durch einfache Abschirmung mit >einem Stück geerdeter Alu Folie das Problem beheben und es tritt wieder >auf, soblad man die Alufolie nicht mehr erdet? Voodoo. Da reichen die kleinsten Erstütterungen. >Ich bastel daran nun schon seit mehreren Tagen herum und habe schon Genau, "basteln" ist das Stichwort. Versuch das Problem mal systematisch und solide anzugehen. >Einzeladern, aber ein Wackelkontakt ist das nun sicher nicht mehr. Wenn das mal kein Irrtum ist. MFG Falk
Ich habe danach schon am totalen Anfang gesucht und nichts dergleiche gefunden. Der gemessene Widerstand der Steckverbindungen ist denkbar gering. Auch die Masseleitung steckt absolut fest. Ich habe das gleiche Kabel für dem ATMega verwendet, wie ich sie nun auch für den Freescale Prozessor benutze. Weiterhin tritt das Problem an allen Masseanschlüssen auf dem Board, sowie auch an allen 3 SPI Ports des Microcontrolers in ähnlicher Weise auf. Ich habe nun schon wirklich einiges Probiert und hatte hierrein gepostet um anregungen für neue Fehlerquellen zu finden, die ich bisher noch nicht probiert hab (deshalb auch das lange einstiegsposting). Aber ich werde wohl nur auf Dinge aufmerksam gemacht die ich schon zig mal überprüft habe oder zu systematischem Arbeiten aufgefordert, wobei über meine vorgehensweise nichts weiter bekannt ist. Aber ok ... Wenn jemand noch Ideen hat was es für Fehlerquellen bei einer solchen Schaltung geben kann, die kein Wackelkontakt sind, so wäre ich sehr dankbar für weitere Anregungen. Gruß, Martin
Hallo, hast du schom mal probiert inwieweit die Störung von der Datenrate abhängig ist? Konntest du das Übersprechen schon mal mit einen Oszi verfolgen? Stimmen die Versorgungspannungen? MfG Dirk
soo .... nachdem ich heute nachmittags nochmals die Verbindung kleinlich kontrolliert habe, hat sich immer noch keine Besserung eingestellt. Insbesondere ist für mich noch nicht ersichtlich in wiefern die einzelnen Puzzleteile zusammenpassen. Zum einen scheint der Fehler irgendwie in der Kabelverbindung zu liegen - sei es nun durch schlechte Kontakte (wobei ich da nichtmehr wüsste in wiefern ich da noch etwas verbesser soll) oder durch irgendwelche Einstreuungen (was mir eigentlich aufgrund von 5V und geringen Strömen eigentlich eher unrealistisch vorkommt) oder auf sonst eine Art und Weise, die ich im Moment grad nicht sehe. Veränderungen an der Verkabelung (umlegen, bewegen der Kabel nahe des Steckverbinders) ändern das Auftreten des Fehlers. Die Datenrate scheint ziemlich unabhängig zu sein. Ich habe den Fehler auch schon bei 1 Hz Bitrate gesehen. Er scheint jedoch nur dann aufzutreten, wenn Daten in beide Richtungen übertragen werden. Übertrage ich nur Nullen von der MCU zum FPGA so kommen die Daten korrekt bei der MCU an und umgekehrt. Nach Oszi ist die leere Datenleitung dann auch wirklich die ganze Zeit auf Masse, weshalb ich einen Kurzschluss ausschließe. Ich bin fürs erste ratlos was ich damit machen soll. Aber zumindest mal danke für die Anregungen. Gruß, Martin
Probiers mal mit kleinen Serienwiderständen, ca. 25-40 Ohm, jeweils so nah wie möglich an den Ausgängen von Takt (auf jeden Fall!) und Daten um Reflexionen zu verhinden. Deine Beschreibung der Empfindlichkeit auf die Lage der Kabel oder das Berühren derselben könnten damit auch erklärt werden.
Auch wenn der Beitrag schon sehr alt ist, ich hatte heute das gleiche Problem und habe auch alle oben genannten Tipps versucht. Da ich eine Lösung in meinem speziellen Fall gefunden habe, dachte ich, ich poste sie mal: Ich habe an einem Master mehrere Slaves, also muss ich per CS den richtigen auswählen. In meiner SPI Lib werden aber (natürlich) nicht alle Pins automatisch high gesetzt. Also hatte ich beim Einschalten an dem cs-Pin, mit dem ich den Slave anspreche einen nicht definierten Zustand, der aber nach "Neustart" des controllers immer (sehr hochohmig) high war. Somit klappte alles. Beim Berühren des Kabel hat sich der Zustand geändert und schon kam die Störung. Ein manuelles high und low Setzen des cs-pins war die Lösung. Mein Kabel ist ohne zusätzlichen Widerstand 30cm lang, als Kabel und Stecker nehme RJ25, das ist ein sechspoliger Stecker, der auch für ISDN benutzt wird. Ich benutze die sechs Adern für Stromversorgung 5V, Masse, miso, mosi, cs und clk. Das Kabel ist nicht abgeschirmt und ich arbeite mit 12MHz SPI Taktfrequenz. Meine Controller (master und alle slaves) sind teensy3.1. Diese Kombi arbeitet wesentlich schneller und störungsfreier als der vorher benutzte i2c. Gruß Roland
Thread beobachten
Seitenaufteilung abschaltenBitte 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.