Hallo Leute, ich habe eine Problem mit einem vermeintlichen übersprechen zwischen SDA und SCL Leitung (im Bild rot umkreist). Die Glitches entstehen bei einer Flanke des Taktsignals, allerdings nur sporadisch. Leider kommt womöglich deswegen immer wieder zu Übertragungsprobleme mit einem angeschlossenen TAOS TCS3404CS (RGBW-Farbsensor). Was gibt es für möglichkeiten das übersprechen zu minimieren? Die Leitung ist ca. 1,2m lang (kürzer geht leider nicht), die Taktfrequenz beträgt 400kHz (SCL).
Angehängte Dateien:
-
I2C_Uebertragung_1.jpg
71 KB
Max schrieb: > Übersprechen: sicher nich!, die flane is grad andersrum... Ok, wenn es kein übersprechen ist, woher könnte dann das Problem des sporadischen Ausfalls der kommunikation kommen?
>Die Glitches entstehen bei einer >Flanke des Taktsignals, allerdings nur sporadisch. So ein Peak entsteht wenn der I2C Master zum lesen des Acknowledge Bits die Leitung frei gibt. Das ist normal. Zähl mal nach ob der Peak immer zwischen dem 8ten und 9ten Clockpuls kommt.
Die glitches sollten keine Rolle spielen, da sie bei fallender Flanke auftreten, ich vemute es ist die Umschaltung des ack-signals des slave.
ok, kann es denn trotzdem aufgrund der länge der leitung zu problemen kommen, die ein nichterreichen des busteilnehmers erklären würden
>Die Leitung ist ca. 1,2m lang (kürzer geht leider nicht), >die Taktfrequenz beträgt 400kHz (SCL). Dann geh halt mal auf 100kHz.
Geh mal mit einem Oszi (Analogkanal) an deine Signalleitungen drann, dein Bild oben wirkt etwas zu digital. Dein Tek kann da zwar schön 0 und 1 trennen, aber ob die verwendeten Schaltkreise das auch so sehen? Wo hast du den I2C-Pull-UP? Eventuell splitten und an jedes Ende des Busses. I2C-Repeater möglich? Andere Leitung getestet (z.B Flachbandkabel, jede 2.Ader GND), aber übersprechen ist es eh nicht,
>Die Leitung ist ca. 1,2m lang (kürzer geht leider nicht), >die Taktfrequenz beträgt 400kHz (SCL). Ähm - was "I²C" bedeutet ist auch bekannt? Das ist ein Bus, um innerhalb einer Platine oder eines Geräts zu kommunizieren. Dass I²C immer wieder auch für größere Entfernungen missbraucht wird, ändert nichts an der ursprünglichen Intention von Philips. Für Störungsfreie Übertragung verwendet man differentielle Übertragung, RS485 z.B. oder zumindest ordentliche Pegel wie RS232.
holger schrieb: >>Die Leitung ist ca. 1,2m lang (kürzer geht leider nicht), >>die Taktfrequenz beträgt 400kHz (SCL). > > Dann geh halt mal auf 100kHz. 100kHz hatte ich schon ausprobiert, ergab keine besserung
Angehängte Dateien:
-
uq.jpg
76 KB
dummschwaetzer schrieb: > Geh mal mit einem Oszi (Analogkanal) an deine Signalleitungen drann, > dein Bild oben wirkt etwas zu digital. Dein Tek kann da zwar schön 0 und > 1 trennen, aber ob die verwendeten Schaltkreise das auch so sehen? Wo > hast du den I2C-Pull-UP? Eventuell splitten und an jedes Ende des > Busses. I2C-Repeater möglich? Andere Leitung getestet (z.B > Flachbandkabel, jede 2.Ader GND), aber übersprechen ist es eh nicht, Ja, im analogen Modus sind Peaks so nicht erkennbar. Der Schwellwert ist auf 1,4V eingestellt, ab da an interpretiert das Oscar diese als High. Die Pull-Ups befinden sich auf der Steuerplatine, die 1,2m vom Farbsensor entfernt ist. Da der µC mit 5V arbeitet der Farbsensor aber 3,3V benötigt, befindet sich dazwischen noch ein Pegelwandlung. Die Pegelwandlung ist nach der AppNote von NXP aufgebaut.
Marvin M. schrieb: > Für Störungsfreie Übertragung verwendet man differentielle Übertragung, > RS485 z.B. oder zumindest ordentliche Pegel wie RS232. Haben wir aus dem Oszillogramm nicht gerade gelernt, dass es KEINE Übersprechen ist. Die Spikes treten alle 9 Takt. Könnte das etwas mit der Richtungsumschaltung zu tun haben?
Hast du mal versucht, die Spikes etwas unkonventionell angemessen mit einem kleinen C wegzubügeln? Aber nicht übertreiben ;-)
Wolfgang schrieb: > Hast du mal versucht, die Spikes etwas unkonventionell angemessen mit > einem kleinen C wegzubügeln? Aber nicht übertreiben ;-) Jop, 100pF jeweils von SDA, SCL nach GND, keine besserung.
das hat zwar nicht unbedingt was mit deinem Übertragungsproblem zu tun, aber wenn du die Pegelwandlung mit dem MOSFET machen willst, muss die Source auf die 3,3V Seite. Du hast sie in der Zeichnung oben auf der 5V Seite, und dann leitet die Substratdiode bei High-Pegel. Ein analoges Oszibild von beiden Enden der Leitung wäre vielleicht doch hilfreich, um den Fehler zu finden... schöne Grüße Achim S.
Marvin M. schrieb: > Ähm - was "I²C" bedeutet ist auch bekannt? Das ist ein Bus, um > innerhalb einer Platine oder eines Geräts zu kommunizieren. Dass I²C > immer wieder auch für größere Entfernungen missbraucht wird, ändert > nichts an der ursprünglichen Intention von Philips. Das ist aber schon ein paar Jahre her. NXP hat inzwischen ein bisschen Lesestoff für längere Übertragungswege in der App-Note AN10658 zusammengestellt. www.nxp.com/documents/application_note/AN10658.pdf
Achim S. schrieb: > das hat zwar nicht unbedingt was mit deinem Übertragungsproblem zu tun, > aber wenn du die Pegelwandlung mit dem MOSFET machen willst, muss die > Source auf die 3,3V Seite. Du hast sie in der Zeichnung oben auf der 5V > Seite, und dann leitet die Substratdiode bei High-Pegel. > > Ein analoges Oszibild von beiden Enden der Leitung wäre vielleicht doch > hilfreich, um den Fehler zu finden... > > schöne Grüße > > Achim S. Hmm, ja da sind wohl drain und source vertauscht, sollte aber denke ich mal bei mosfet nichts machen. Das komische ist ja, es lief eine ganze zeit lang ohne probleme, und heute macht es plötzlich probleme. Analoge Oskarbilder kann ich morgen ggf. nachreichen wenn ich in der FH bin.
I2C schrieb: > sollte aber denke ich mal bei mosfet nichts machen. ... bis auf die auch im Datenblatt eingezeichnete Diode mit Kathode an Drain und Anode an Source ...
ne, die Verpolung macht fast nichts, außer dass die angestrebte Pegelwandlung nicht funktioniert. Lies die AppNote von NXP noch mal durch. Das es in der Vergangenheit lief und erst seit heute Probleme macht, ist eine ziemlich wichtige Info, die ich vorher wohl überlesen habe. In solchen Fällen sollte man sich fragen: was hat sich verändert, seit es das letzte mal stabil lief. Die Antwort lautet spontan meistens "nichts", aber nach einigem Nachdenken kommt man dann doch auf den eigentlichen Grund des Problems. schöne Grüße Achim S.
>Jop, 100pF jeweils von SDA, SCL nach GND, keine besserung. Scheiss Idee. Damit macht man das virtuelle Kabel noch mal gefühlte 2m länger. >Das komische ist ja, es lief eine ganze >zeit lang ohne probleme, und heute macht es plötzlich probleme. Dann wird es wohl Zeit auch die Software in Frage zu stellen. Oder dein Handy hat die Hardware zerstört, oder dein heisser Finger. Mach das Kabel doch einfach mal kürzer. Dann kannst du wenigstens da einen Fehler ausschliessen.
Ja, ich werde es morgen zunächst mit einem kürzeren Kabel ausprobieren. Vllt. liegt es ja an der trockenen Luft, etc...
I2C über Strecke ... ja, da habe ich mir richtig die Finger verbrannt ! I2C über 3m Telefonkabel. Alles prima, bis der erste LKW durch das Werkstor bei VW fuhr und dermaßen mit Funkwellen beschossen wurde, daß es hing. Später haben wir eine E1-Zertifizierung bestanden, da hatte ich dann kurzerhand eine CRC-Prüfsumme eingeführt... Die Pull-Ups klein wählen. Die Speed langsam wählen (warum nicht 50kHz?).
Ich habe mal etwas ähnliches, als ein Arduino als Master immer nach Bit 15 einen kurzen Peak auf die Leitung setzte. Ich habe das dann über einen Widerstand gelöst, das der Peak unter dem Level für High blieb. 400 KHz finde ich bei der Leitungslänge auch ganz schön schnell.
Angehängte Dateien:
-
I2C_Fehler.png
4 KB -
I2C_Fehler_2.PNG
5,9 KB
So ich hab noch mal ein paar Bilder gemacht, wir haben jetzt die Leitung durch ein Netzwerkkabel getauscht, soweit scheint die Kommunikation wieder zu funktionieren. Allerdings kommt bes beim aufnehmen des analogen Oszilloskopsignal zu komischen "zwischen" Pegel. Diese stellt das Oskar mit einem ausrufezeichen dar. Anbei die Bilder
Das zweite Bild zeigt jeweils das Datensignal am ende und am anfang der Leitung gemessen. Kann der Zwischenpegel möglicherweise an Reflexionen liegen?
Diese Zwischenpegel können doch dadurch entstehen, daß beide Devices auf beiden Seiten des Pegelwandlers Signale auf der DATA-Leitung senden. Wie soll sonst das ACK übertragen werden ? Und der Pegelwandler ist ja auch ein Haufen FETs=Widerstand mit Dioden. Sieh Dir die Schaltung mal genau an. (Master gibt DATA frei, Pull-Up würde ja gerne hochziehen, aber auf der anderen Seite der Diode zieht Slave jetzt gegen Gnd, bis, ja, bis wann denn? Reflexionen kannst Du hier ausschließen.
Hallo, die "Zwischenpegel" ergeben sich tatsächlich daraus, dass dort nicht mehr der Master sondern der Slave die Leitung nach low treibt, um das ACK zu geben. Auch der kurze "Glitch", den du zu Beginn verdächtigt hast, gehört zum ACK und stört nicht (wie es Holger ja auch schon erklärt hat). Bedenklich finde ich aber die Absolutpegel, die du erreichst. Das Signal schaltet laut Oszi zwischen 1V und 3V, und das sowohl auf der Master-Seite (mit 5V Supply) als auch auf der Slave-Seite (mit 3,3V Supply). Das ist untypisch für einen IIC-Bus und passt nicht zu dem Schaltbild, das du gestern gepostet hast. Entweder stimmt was mit der Messung nicht (GND Clip angeschlossen? Uncal-Setting im Oszi?), oder der Bus wird stärker belastet, als er sollte (nicht nur von den oben gezeigten 3,6kOhm Pullups). schöne Grüße Achim S.
Ja, das kann möglicherweise am nicht angeschlossenen GND liegen, es handelt sich um eine Mixed Signal Oscilloscope Tek MSO 2024, wir hatten den GND der digitalen Anschlussleitung mit unseren GND verbunden und deswegen den von den Tastköpfen weggelassen, da wir davon ausgegangen sind das diese intern verbunden sind.
Ahh, jetzt verstehe ich was du meinst, ich habe in beiden Fällen bei 3,3V gemessen. Nur einmal vor- und einmal hinter der Busleitung.
ok, verstanden Aber selbst wenn das Oszi einen Offset von 1V haben sollte und beide Messungen aus dem 3,3V-Bereich stammen, ist der Swing des Signals mit 2V immer noch zu klein. (Und ich würde eigentlich auch davon ausgehen, dass der GND des Logikteils und der Analogkanäle intern verbunden sind, und dass darüber kein GND-Shift von 1V entstehen kann.) Also richtig "gesund" sehen die Pegel immer noch nicht aus... schöne Grüße Achim S.
I2C schrieb: > wir hatten den GND der digitalen Anschlussleitung mit unseren GND > verbunden und deswegen den von den Tastköpfen weggelassen, da wir > davon ausgegangen sind das diese intern verbunden sind. Das sind die schon, ABER für höhere Frequenzen viel zu hochimpedant. Dann zappelt die Masse des anderen Signals irgendwo in der Luft herum und erzeugt so irgendwelche Artefakte... Merke: jeder Tastkopf muß auf kürzestmöglichem Weg direkt neben der Messtelle mit GND verbunden werden. Sonst passiert dir evtl. sowas: Beitrag "Re: Spannungspeaks / Ripple durch Schaltregler. Abhilfe?"
@Tom >Haben wir aus dem Oszillogramm nicht gerade gelernt, dass es KEINE >Übersprechen ist. Die Spikes treten alle 9 Takt. Könnte das etwas mit >der Richtungsumschaltung zu tun haben? Habe ich mich auf die Spikes bezogen? Nein. Funktioniert die Datenübertragung störungsfrei? Nein. Ist I²C die richtig Übertragungsmethode? Offenbar fraglich. @Wolfgang >Das ist aber schon ein paar Jahre her. NXP hat inzwischen ein bisschen >Lesestoff für längere Übertragungswege in der App-Note AN10658 >zusammengestellt. >www.nxp.com/documents/application_note/AN10658.pdf Kenne ich. Und dennoch verwende ich I²C nicht. Warum, das erfährt der TO momentan am eigenen Leibe. Ich habe gelernt, nicht lange an Symptomen herumzubasteln, sondern die Ursache zu beseitigen - und seit ich I²C nicht mehr für längere Übertragungswege nutze, habe ich Ruhe. Da muss nur der schon angesprochene LKW durch das Hoftor fahren oder ein neu angeschaffter PC ist eben doch nicht ganz EMV-konform und schon passt es nicht mehr. Bis hin zu statischer Entladung (bei diesem Wetter sehr wahrscheinlich) hat irgendetwas geschrottet / angetickt, so dass eine vorher "gerade noch" gute Verbindung nun eben nicht mehr funktioniert. Ich würde, wie schon mehrfach vorgeschlagen, die Geschwindigkeit massiv herunterfahren. Versuche mal 10kHz und darunter. Geschirmte Kabel (aber "richtig" geerdet) sind sowieso ein Muss. Bei sporadischen Fehlern würde ich mal einen Datenlogger über längere Zeit anhängen, die kurzen Oszi-Snapshots sind wenig aussagekräftig.
Marvin M. schrieb: > ... und seit ich I²C nicht mehr für längere > Übertragungswege nutze, habe ich Ruhe. Hast du einen PC Monitor mit VGA/DVI/HDMI Verbindung zum PC? Dann hast du auch eine I2C Schnittstelle zwischen 2 Geräten mit langem Kabel.
Ahh, jetzt verstehe ich was du meinst, ich habe in beiden Fällen bei 3,3V gemessen. Nur einmal vor- und einmal hinter der Busleitung. Achim S. schrieb: > ok, verstanden > > Aber selbst wenn das Oszi einen Offset von 1V haben sollte und beide > Messungen aus dem 3,3V-Bereich stammen, ist der Swing des Signals mit 2V > immer noch zu klein. (Und ich würde eigentlich auch davon ausgehen, dass > der GND des Logikteils und der Analogkanäle intern verbunden sind, und > dass darüber kein GND-Shift von 1V entstehen kann.) Also richtig > "gesund" sehen die Pegel immer noch nicht aus... > > schöne Grüße > > Achim S. die übertragung funktioniert nun wieder, allerdings habe ich mir nochmal das phänomen angesehen, dass die busleitung nicht richtig auf masse gezogen wird. Ich denke das wird wohl tatsächlich mit den vertauschten drain und source liegen. Ich werde die Schaltung mal umlöten, und dann nochmal berichten
Passt wahrscheinlich nicht ganz zum Thema aber ich habe einen merkwürdigen zusammenhang in einer I2C Kommunikation in einer Bastelei von mir entdeckt. Kann mir irgendjemand vielleicht ansatzweise erklären, warum bei niedrigen Freqeunzen (~ <250kHz) die Kommunikation nicht mehr funktioniert, aber bei allen Freqeunzen (bis zu 400kHz Normwert) die Datenübertragung einwandfrei funktioniert? *Das Flachbandkabel wirkt bei höheren Freqeunzen induktiver und die Induktivitätsbeläge können kapazitives Verhalten kompensieren, was bei einen Open-Drain Bus Vorteile hat? *Fehlanpassung des Pullup Widerstandes bei tiefen Freqeunzen? (Im Datenblatt des ATMEGA644 gibt es einen Abschnitt zum Berechnen des Pullup Widerstandes in Abhängigkeit der Freqeunz und der Kapazitiven Last die die Portpins treiben müssen) *Etwas völlig anderes?
Angehängte Dateien:
-
IMG_1304.JPG
70 KB
Habe den Spike auch (rechts). Er kommt nach dem ACK (9. Taktpuls) in der Lo-Phase von SCL, dürfte also nichts weiter ausmachen. Ich denke, es ist kein Übersprechen, sondern durch Umschaltvorgänge/Reaktions-/Laufzeiten im µC verursacht. Angeschlossen ist ein LPC1768 und ein MCP3221 (ADC), Takt 400 kHz, Leitung ca. 20 cm. Die angehobenen Lo-Pegel in der Bild-Mitte kommen durch Serien-Widerstände in SDA. So erkennt man, wer der Sender ist, wenn auf der richtigen Seite gemessen wird. Hier sendet der MCP seine Daten. MaKro
Angehängte Dateien:
-
IMG_1305.JPG
48 KB
Habe den Spike noch mal im kleineren Zeitbereich dargestellt, die Kästchen sind 250 ns. Liegt also eindeutig im SCL = Lo (oben SDA, unten SCL), gleiche Stelle wie vorhin. MaKro
Den Grund warum unsere Taktleitung (SCL) und Datenleitung (SDA) die 0V nicht erreicht haben, haben wir jetzt gefunden. Die beiden MosFETs hatten wohl einen weg, ein umtausch durch zwei neue errbrachte den gewünschten effekt. Möglicherweise sind diese durch statische elek. gestorben, konnte aber nicht geklärt werden. Danke für die Hilfe. mfg I2C
Ist doch gut, wenn man nicht alles dem Logikanalysator überläßt, sondern mal guckt, was wirklich auf der Leitung los ist. Ein Analogsignal sagt mehr als "tausend Fragezeichen".
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.