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
@ 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
