SPI Verbindungsproblem

May 31, 2011 22 Replies

Guten Tag



Ich habe hier gerade ein FPGA (Master) mit einem SPI Core aufgebaut. Damit versuche ich ein WLan Modul (Slave) anzusteuern. Das Modul funktioniert zu beginn tadellos, allerdings spuckt es mir immer an der gleichen Stelle falsche Daten an der MISO Leitung aus. Oftmals ist es genau um 1 Bit verschoben, manchmal erkenn ich alelrdigns überhaupt nichts in dem Datensalat.



So jetzt das Phänomen. Nun habe ich gerade ein DSO angehängt um zu sehen was passiert. Ohne das ich überhaupt die Daten mir am Oszi angesehen habe, funktioniert nun die SPI Verbindung und ich erhalte die Daten die ich möchte. Wenn ich die Tastmessköpfe vom Oszi trenne (BNC Stecker), nicht jedoch von meinen SPI Leitungen, dann funktioniert das ganze auch noch. Entferne ich wieder die Tastmessköpfe komplett, so funktioniert nichts mehr.



Daher vermut ich das eventuell kapazitive Effekte eine Rolle spielen könnten. Verschiedene FPGA Pins habe ich schon getestet, ich denke nicht das die Probleme machen.



Meine SPI Kommunikation läuft mit 1,5MHz und als Verbindungskabel hab ich einfach ein Flachbandkabel genommen das aus meinem Modul raus (3,3V Pegel) direkt auf die FPGA Pins geht. Die Verbindung zwischen Kabel und FPGA ist eine kleine Platine auf der eine Sockelleiste ist und eben der Wannenstecker. Davor hatte ich eine ziemliche Pfuschlösung, die hatte aber das gleiche Verhalten mit dem Oszi, wie jetzt.



Hat irgend jemand einen Tipp was da schief läuft? Oder besser eine Idee wie ich das ganze beheben könnte.



Vielen Dank für jeden Tipp, ich quäl mich schon ewig damit rum :(



Gruß Tobias


So isses wohl. Und ich kenne Leute die in solchen Faellen allen Ernstes je 10pF dranhaengen und das ganze zur Produktion freigeben lassen wollten ;-)

Ich nehme mal an mit Master Input (MISO) meinst Du die Leitung vom WALN Modul zum FPGA, also dass das WLAN Modul die Daten nicht sauber schnackelt. Sieh Dir mal die Flanken am WLAN Modul an. Zum einen ob die sauber sind (Terminierung vergessen oder verkehrt?) und dann auch ob das Timing zwischen SCLK und MOSI vielleicht zu scharf "an der Kante" sitzt.

Auch schon passiert: DAC eines namhaften Herstellers zeigte aehnliche Effekte. Finger auf MOSI, ging, Finger weg, ging nicht, oder manchmal doch oder woll oder nicht. Es stellte sich heraus dass die Timing Angaben im Datenblatt wohl, ahem, nicht so ganz stimmten. Rausgefunden habe ich das auf die brachiale, SCLK invertiert -> alles war paletti, selbst wenn ich mit der Kaeltespraydose einen halben Eisberg auf den DAC setzte.

Gruesse, Joerg http://www.analogconsultants.com/ "gmail" domain blocked because of excessive spam. Use another domain or send PM.

Tobias Baumann schrieb:

Hallo,

nimmst Du 1:1 oder 10:1 Tastköpfe? Bei 1:1 sind es wenn ich mich recht erinnere so 10 pF Eingangskapazität, bei 1:1 wohl 100 pF. Versuch mal ob es läuft wenn Du an die SPI Leitungen noch 10 pF gegen Masse legst oder

100 pF bei 1:1. Schau aber vorher mal nach wie hoch die Eingangskapazitäten an Deinem DSO wirklich sind.

Bye

Tobias Baumann :

Eventuell ist die CLK-Polarität des SPI gedreht? d.h. du musst das jeweilige Bit an der anderen Flanke ausgeben bzw. abtasten, als Du es jetzt tust.

M.

Und so sprach Tobias Baumann:

Das klingt nach sehr knappen Flanken-Timings. Ich würde mal mit der Verschiebung des Clk-Signals ggü den Daten experimentieren.

Roland

[SPI Problem]

Ja. Genau das wird es höchstwahrscheinlich sein. Durch die Kapazität des Tastkopfes wird das Daten oder Taktsignal (wohl eher das Datensignal mit relative großem Pullupwiderstand) so weit verzögert, dass es dann genau hinkommt.

Viele Grüße, Martin L.

"Genau" eher nicht. Vielmehr so dass es dann so gerade eben geht. Wenn's draussen warm wird dann eventuell nicht mehr ;-)

Man muss der Sache auf den Grund gehen und die Flanke wenigstens einigermassen in die Naehe der optimalen Position bringen.

Gruesse, Joerg http://www.analogconsultants.com/ "gmail" domain blocked because of excessive spam. Use another domain or send PM.

Ich bedanke mich schon mal recht herzlich für alle Antworten.

Das mit der CLK Polarität kann ich mir nicht so vorstellen. Ich sende und empfange ja eine zeitlang davor schon Daten und da passt alles. Erst ab einem bestimmten Zeitpunkt fängt das Modul an mir Müll auszuspucken.

Leider kann ich nicht mit dem Oszi sehen was gerade bei den Schrott Daten passiert, weil wenn ich das Oszi dran habe funktioniert ja alles. Und in der Phase in der alles funktioniert kommen die Taktflanken auch super optimal. Wenn ich zum Beispiel die Bitfolge 101 habe, dann sind meine Flanke genau in der Mitte der Pegel.

Leider musste ich heute schon um 17 Uhr Feierabend machen, hätte gerne noch etwas experimentiert. Vll kann ich Freitag weiter machen, dann versuch ich mal die bis dahin gesammelten Tipps umzusetzen.

Vielen Dank an alle Helfer!

Gruß Tobias

Ich bin gerade in der Testphase, sowas wie ein "Proof of Concept". Solchen Murks kann ich mir eigentlich auch erlauben, hauptsache es läuft dann irgendwie. Wenn mein Projekt klappt, hat mein Nachfolger ab Juli dann die Probleme an der Backe ;)

Ich versuche Freitag mal ein Bild zu machen. Seltsamerweise beeinflussen sich die Pins auf alle Fälle gegenseitig. Wenn ein Taktsignal kommt dann hab ich ein starkes oszillierend abfallendes Rauschsignal. Etwas doof zu beschreiben, aber die Amplitude ist schon deutlich erkennbar, ca. 0,2V.

Terminierung hab ich keine. Es hieß zu mir das bei den Geschwindigkeiten und meinem 10cm Flachbandkabel da keine Probleme auftauchen sollten. Dazu müsste ich mich erst noch ein bisschen einlesen wie eine vernünftige Terminierung aussieht (ich glaub bei mikrocontroller.net hab ich nenn Artikel dazu gefunden). Leider passt mir das zeitlich gar nicht in Kram, da ich nächste Woche donenrstag Diplomprüfung habe. Gibt es da ein paar Standartwerte für R und C wie eine Terminierung aussieht? Eine Terminierung auf WLan Modulseite ist nicht vorhanden und kann nachträglich auch nicht ohne weiteres eingefügt werden. Daher hoffe ich das eine Terminierung auf FPGA Seite auch reicht.

SCLK invertieren wird bei mir nicht gehen. Muss am Anfang eine Software ins Modul laden und das funktioniert auch tadellos. Wenn ich SCLK invertiere kann ich schon keine Software mehr reinladen.

Aber Datenblätter können einen echt fertig machen. Mit dem Datenblatt von dem Modul kämpf ich auch schon seit Wochen. Mittlerweile ist ein Update draussen, das einigermaßen verständlich ist. Die erste Version als das Modul auf den Markt kam war jedoch der Horror. Über 100 Seiten und wichtige Informationen stehen in kleinen Nebensätzen oder vll mal ganz edel in Klammern. Wochen lang mit dem Support geärgert warum am Anfang gar nichts ging, bis mal die Frage kam ob ich mit Interrupts arbeite. War antürlich nicht der Fall, weil von Interrupts nicht die Bohne was im Datenblatt steht (naja in der neue Version schon, jetzt zu spät). 30¤ Modul und hunderte ¤ Lohn für den Käse draufgegangen. So langsam ist das Modul auch nicht mehr wirtschaftlich. zum Glück bin ich nur als HiWi angestellt, sonst wäre die Entwicklung schon ziemlich teuer geworden. ;)

Gruß Tobias

Ich hab nenn 1:1 Tastkopf mit 11,1pF. Ich probier das mal aus (konnte heut Nachmittag nicht mehr ins E-Labor und das schnell anlöten). Wenn das die schnelle Lösung wäre das echt super, auch wenns ein bisschen gemurkst ist.

Aber ich finde das ganze Verhalten schon seltsam. Können diese knapp

10pF wirklich den Unterschied zwischen tut und tut nicht ausmachen. 10pF sind doch wirklich so gut wie nichts oder? Ich bin echt gespannt ob was geht, muss Freitag doch unbedingt das testen.

Gruß Tobias

Das kann z.B. daran liegen dass die Setup&Hold Zeiten so gerade eben eingehalten werden und wenn dann mal mehr als so-und-so Bits einer bestimmten Polaritaet kommen sackt irgendwas auf dem Chip infinitesimal weg und ... rumms.

Kann natuerlich auch sein dass ganz ordinaer etwas digitales spinnt.

Trick 17: Falls keine FET-Probes zur Hand einfach Koax an die Eingaenge des Scopes, und selbiges auf 50ohm Abschluss schalten. Dann am anderen Ende jedes Koax den Mantel auf Masse und mit 1k an SLCK, MOSI und MISO. Dann ist dort keine grosse Kapazitaet. Mehrere kohm gehen auch noch, aber irgendwann verzerrt das.

Mitte sollte eigentlich gehen, aber nur wenn die SPI-Geschwindigkeit nicht ausgereizt ist.

[...]
Gruesse, Joerg http://www.analogconsultants.com/ "gmail" domain blocked because of excessive spam. Use another domain or send PM.

Nach Dir die Sintflut? Dat iss jetz abba fies, woll ... :-)

Oszillierend ist nicht gut. Sehen wir mal wie das Bild am Freitag aussieht. Da ist nicht versehentlich irgendwo im FPGA eine Schleife reinprogrammiert?

Versuche es mal mit rund 100ohm in Serie zu den FPGA Pins fuer SCLK und MOSI. Fuer MISO (FPGA empfaengt) dann 100ohm und 22pF oder so als Serienschaltung vom MISO Pin nach Masse.

Ok, dann wuerde ich erstmal die Terminierung probieren. Wenn die Leitungen wie Du oben schriebst "ueberklingeln" dann muss das beinahe Aerger geben. Bei 10cm Flachkabel wundert mich das zwar etwas, aber wer weiss. Sieh Dir auch mal die Abblock-C am WLAN Modul und FPGA an, oder mit dem Scope direkt die Betriebsspannungen.

Sieh es mal positiv: Das staehlt spaeter fuer den Job, wo Du sowas reihenweise erleben duerftest, wie unsereins. Ganz herrlich sind Datenblaetter asiatischer Bauteile. Riesiger Kaefer mit dutzenden von Funktionen, Datenblatt ganze zwei Seiten lang, Informationsgehalt nahe Null. Wie unser Feldwebel immer sagte, alles was nicht unmittelbar zum Tod fuehrt haertet ab.

Gruesse, Joerg http://www.analogconsultants.com/ "gmail" domain blocked because of excessive spam. Use another domain or send PM.

Naja ich bin ja für die Software des FPGAs zuständig und nur bedingt für die Elektronik dazwischen. Und da ich eh nur 44h im Monat arbeite muss ich irgendwo Abstriche machen ;)

Ich weiß nicht genau wie ich das zu verstehen hab. Da ich mit der EDK arbeite habe ich praktisch eh keine Chance in einem vernünftigen Zeitrahmen meinen SPI-Core noch irgendwie zu optimieren. Ich hab da eh schon ziemlich pfuschen müssen, da mein SS Signal über ein GPIO gesteuert wird und nicht über den SPI-Core. Aber der Core hat leider nicht soviel "I" im IP, so das ich auf diese Lösung angewiesen bin um eine Variable Bitlänge zu realisieren.

Ok werd ich versuchen. Wenn diese Lösung funktioniert wäre das ein super Arbeitstag an dem ich mal nicht kurz davor bin das ganze aus dem Fenster zu schmeißen ;)

Betriebsspannung hab ich mir schon angeschaut. Die ist wirklich sauber.

Hmmmm, seltsamerweise kommt mein Modul auch aus Asien. Hab das Problem auch schon dem Support dort geschiltert. Sehr ausführliche Email, mit detaillierter Fehlerbeschreibung, ala "Ich erwarte in Byte 10 ein 0xA5, erhalte aber ein 0xBC" oder ähnliches. Woran kann das liegen? Antwort: "In Byte 10 müsste 0xA5 rauskommen, nicht 0xBC, bitte prüfe das nach". Am liebsten wär ich nach Indien geflogen und hätte denen das Teil an Kopf geworfen. Aber immerhin erhalt ich eine Antwort und werde nicht ignoriert ;)

Verstaendlich. M.W. durften wir in der 80ern noch 19 Wochenstunden als Hiwi machen.

Ich kenne mich nicht mit FPGA aus aber ich hatte mal was aehnliches. Man frotzelte schon was von Wuenschelrute und so, weil ich den Spektrumanalysator immer mit einem Stueck Draht als Antenne mitlaufen liess. Der Spektrumanalysator blitzte auf, bei fast 1GHz und so schnelle Clocks hatten die gar nicht im System. Dann habe ich mir die E-Feld Sonde genommen und damit die Pins abgeklappert. Bei einigen tauchte dann dieses "Waeldchen" oben ueber dem UHF Bereich auf. Also mit dem FPGA Spezi zusammengesetzt und es stellte sich raus dass irgendwie zwei Prozesse gleichzeitig auf die Pins zugriffen, nur in umgekehrter Richtung. Das ergab einen ungewollten und ziemlich instabilen Burst-Oszillator, aber nur bei bestimmten Bit-Kombinationen.

Auf diese Art finde ich oft Bus Contention die nur zeitweise auftritt. Das laesst normalerweise bei jeder Kampfepisode eine EMI-Russwolke ab. Anfang des Jahres etwa. Die Bootzeit des Systems war endlos lang, 15 Sekunden oder so und auch nicht immer konstant. Danach sank die auf ein paar hundert Millisekunden und war immer gleich.

Da darf auf jeden Fall nichts "ausrauschendes" oder oszillierendes auf den Signalen zu sehen sein.

Sehr gut. Da erkennt man den Praktiker, erstmal den Reifendruck pruefen :-)

Das kenne ich mittlerweise zu Genuege, besonders was chinesische Hersteller angeht. Manchmal habe ich den Eindruck dass sie Leute frisch von der Uni an sowas lassen und mit Kommunikation haben sie's eh nicht so in den Firmen :-(

Gruesse, Joerg http://www.analogconsultants.com/ "gmail" domain blocked because of excessive spam. Use another domain or send PM.

Passive Tastköpfe mit Teilerfaktor 1:1 und Eingangskapazität von 11 pF kanns nicht geben. Die Eingangskapazität von Oszis liegt ja schon bei 15pF.

Miß mal den Widerstand zwischen Tastkopfspitze und Steckersitift. Liegt der bei 10_MOhm, hat dein Tastkopf einen fest eingastellten Teilerfaktor von 1:10. Dann sind 10_pF real.

mfg hdw

Moderne FPGAs machen teilweise extrem steile Flanken und daher müssen die Signale sauber terminiert werden, auch wenn die Taktfrequenzen eben dieser Signale eher moderat sind wie bei dir.

Bei manchen kann man auch in der FPGA-Konfig die Flankensteilheit etwas entschärfen.

Gruß, Enrik

Darf man auch heute noch, nur muss man dann natürlich Abgaben zahlen, bei 40-44 Stunden im Monat (je nach Stundenlohn) bleibt man unter

400EUR...

Gruß Henning

Ok ich hatte diesen Wert im Kopf, weil der glaub auf dem Tastkopf drauf steht. Kann es jetzt gerade nicht nachschauen und auf der Tektronix Seite find ich den Tastkopf nicht.

Ok, werd ich mal versuchen.

Gruß Tobias

Könnte ich auch, aber dann würde mir das Bafög gekürzt, was auch nicht sonderlich sinnvoll ist. Aber in guten Monaten komm ich sicher auch auf

19h / Woche, wenn man versucht etwas zum laufen zu griegen und der persönliche Ehrgeiz größer, als die Liebe zum Job ist ;)

Ich hoffe mal das sowas nicht Auftritt. Wenn wirklich 2 Prozesse einen Pin setzen wollen, dann hab ich ein Problem und könnte das nicht mal verhindern. allerdings dürfte dann auch meine Synthese nicht mehr durchlaufen, da diese meckert wenn zwei Prozesse ein Signal schreiben wollen.

Ok, da ist auf alle Fälle was und es tritt immer auf wenn ne Clock-Flanke steigt oder fällt. Jetzt ärger ich mich das ich kein bild gespeichert hab, musste gestern leider dann dringend losflitzen in die Vorlesung :(

Spart sicher auch einiges an Geld. Ich hab mal in einem Programmierbuch gelesen das die meiste Kosten die bei Software anfällt der Support/Dokumentation und die Wartung/Updates sind. Bei Elektronik, vor allem im billigen Preissegment kann ich mir das irgendwie auch vorstellen und das da dann gern gespart wird :(

Ok, Bafoeg bekam ich keins. Allerdings hat das Studium ein wenig unter der Arbeit gelitten, doch im Nachhinein hat mir dieser HiWi Job mehr berufsrelevantes Wissen gebracht als die Vorlesungen oder das Klausurbueffeln.

Das hatte der Ingenieur beim Kunden auch gedacht. "I can't believe this is happening!", so in etwa "Das darf doch wohl nicht wahr sein!".

Ginge es aus dem Gedaechtnis raus auf ein Blatt Papier und in den Scanner?

Bei manchen Firmen gibt es nie Updates. Ich habe einen chinesischen Funktionsgenerator hier. Er hat einige Features die westliche Geraete meist nicht haben, aber auch Schnitzer die vermutlich in der Firmware sitzen. Plus einen HW-Designfehler den man per Firmware kaschieren koennte. Ich versuche seit ein paar Monaten den Jungs zu zeigen wo die Probleme sind und wie man sie umschiffen koennte. Erfolg bisher Null, die Firmware ist Version 1.0 von anno 2008.

Gruesse, Joerg http://www.analogconsultants.com/ "gmail" domain blocked because of excessive spam. Use another domain or send PM.

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required