Hallo, ich treibe einen MCP23017 (IO Expander mit I2C) bei 100kHz I2C-Takt mit einem XMC4500 (Relax Kit Light). Die Settings im µC sind ok, denn die Verbindung zum MCP23017 klappt mit angeschlossenem Oszilloskop. Ich kann eine am MCP23017 angeschlossene LED zum Blinken bringen. Sobald ich aber das Scope abnehme (beide Leitungen weg, oder nur Masseanschluß bleibt bestehen) und neu starte hängt der µC und weigert sich, auch nur irgendwas zu versenden (Schreibpuffer läuft voll, getestet mit Debugger), der XMC4500 meldet allerdings auch keine Probleme. Das zuständige Statusregister zeigt allerdings auch keinerlei I2C-Aktivität an (PSR_IICMode = 0). Beide Bausteine (MCP23017 und XMC4500) laufen mit 3,3V. Pullups sind verbaut (4,7k je für SDA und SCL). Die Verbindungslänge beträgt etwa 20cm. Testweise hatte ich auch schon 1,5k Pullups dran (keine Änderung). Hat jemand eine Vorstellung, welches elektrische Problem dahinter stecken kann? Grüße schnack
Hiho, spontan gesagt, gilt die alte Frage: "Was ist Kalt und wenn man mit der Messspitze rankommt geht?" löte mal die Pins nach, das <u>könnte</u> helfen
Könnte auch ein Masseproblem sein, bzw. fehlende Masse. Hatte mal so ein ähnliches Problem: Schaltung mit Schieberegistern lief nur, wenn das Oszi angeschlossen war. Genauer gesagt, die Masse des Oszis. Es fehlte dann die Masseanbindung eines Schieberegisters.
steile Flanken --> Reflexionen auf den Leitungen --> Ringing, Abhilfe: Dämpfungswiderstand 33 - 100 Ohm in Reihe mit den beiden Leitungen (auf der Treiberseite).
@ egal (Gast) >steile Flanken --> Reflexionen auf den Leitungen --> Ringing, Abhilfe: >Dämpfungswiderstand 33 - 100 Ohm in Reihe mit den beiden Leitungen (auf >der Treiberseite). Käse. Wir reden von I2C, da ist nix mit Terminierung.
@ C. D. (schnack) >Masseanschluß bleibt bestehen) und neu starte hängt der µC und weigert >sich, auch nur irgendwas zu versenden (Schreibpuffer läuft voll, >getestet mit Debugger), der XMC4500 meldet allerdings auch keine >Probleme. Kann nicht sein. Wie soll der Schreibpuffer volllaufen, wenn es keine Probleme gibt? Jedes geschriebene Byte muss vom Slave bestätigt werden (ACK). Passiert das, läuft der Puffer nicht voll. Passiert das nicht (und die Übertragung blockiert somit), muss ein Fehler signalisiert werden (ACK timeout). Also ist dein I2C Softwaretreiber mangelhaft. >Beide Bausteine (MCP23017 und XMC4500) laufen mit 3,3V. >Pullups sind verbaut (4,7k je für SDA und SCL). Die Verbindungslänge >beträgt etwa 20cm. Kein Problem für I2C. Miss mal die Versogrungsspannug an deinem Portexpander, vielleicht passieren da komische Sachen.
Hallo, vielen Dank für die Vorschläge. Noch einmal kurz zur Beschreibung: das Problem tritt auch auf, wenn ich die Masse-Leitung des Oszilloskops anschließe. Um noch eins "drauf zu setzen": Die LED hängt nicht direkt am MCP23017, sondern über einen ULN2803-Treiber am Expander. Wenn ich die LED vom ULN2803 abklemme, geht sie natürlich aus, stecke ich sie wieder herein, stoppt der µC. Der ganze Aufbau ist auf einem ProtoBoard (weitgehend Klemmverbindungen). Die Versorgungsspannung habe ich via Oszi geprüft - sehe keine Besonderheiten. Ein angeschlossenes Multimeter lieferte allerdings Sprünge im Bereich 3,1..3,5V. Zur Treiber-SW: Ich kann mir das Verhalten des XMC4500 auch nicht erklären. Ich beschreibe lediglich den Wert der Statusregister. Der von Infineons DAVE generierte Source Code (und von mir kosmetisch geänderte Code) prüft wie folgt vor einem Schreibvorgang in den Eingangspuffer:
1 | if(I2CRegs->PSR_IICMode & USIC_CH_PSR_IICMode_WTDF_Msk) { |
2 | return false; |
3 | } |
4 | |
5 | if(USIC_IsTxFIFOfull(I2CRegs)) { |
6 | return false; |
7 | } |
Wenn der µC hängt, springt er bei der zweiten Prüfung raus und versucht permanent den Schreibvorgang zu wiederholen. Die erste Prüfung schaut auf I2C-Probleme. Abgesehen davon habe ich Interrupts aktiviert, die bei einem Protokollfehler inkl. fehlendem ACK anschlagen (und das haben sie bislang auch schon zur Genüge). Der aktuelle Code ist - so glaube ich - nicht fehlerhaft. Grüße schnack
@ C. D. (schnack) >Um noch eins "drauf zu setzen": Die LED hängt nicht direkt am MCP23017, >sondern über einen ULN2803-Treiber am Expander. Wenn ich die LED vom >ULN2803 abklemme, geht sie natürlich aus, stecke ich sie wieder herein, >stoppt der µC. Klingt so, als ob deine LED die Versorgung beeinflußt. Vorwiderstand vergessen? >Der ganze Aufbau ist auf einem ProtoBoard (weitgehend >Klemmverbindungen). Naja, >Die Versorgungsspannung habe ich via Oszi geprüft - sehe keine >Besonderheiten. Ein angeschlossenes Multimeter lieferte allerdings >Sprünge im Bereich 3,1..3,5V. Bitte? Dein Oszi sieht nix und dein Multimeter wackelt? Du musst schon gescheit triggern, also Triggerschwelle auf ca. 3V und Normal oder Single Shot Trigger. >Wenn der µC hängt, springt er bei der zweiten Prüfung raus und versucht >permanent den Schreibvorgang zu wiederholen. Klingt so, als ob der IC2C Bus als blockiert erkannt wird, weil SCL oder SDA LOW sind. >bislang auch schon zur Genüge). Der aktuelle Code ist - so glaube ich - >nicht fehlerhaft. Aha.
Hallo, ich habe mal den Verlauf auf der SDA/SCL-Leitung angehängt. Anscheinend gibt es auf der Leitung kleine Spikes von etwa 1V (oder es ist ein Meßartefakt). Die Spannungsversorgung habe ich mit einem zweitem Multimeter (mein Besseres) nachgemessen und erhalte nunmehr Werte im Bereich 3,295V-3,305V. Das Oszilloskop hat diese Varianz auch im Single Shot gezeigt. Grüße schnack
Und noch eines: Wie ich gerade festgestellt habe, geht die I2C-Verbindung auch, wenn ich das Messkabel vom Oszilloskop trenne (vorher hatte ich die Prüfspitzen von der Schaltung entfernt), also das Kabel frei endet. Die Kommunikation klappt auch, wenn ich danach die Prüfklemme für die Masse von der I2C-Schaltung nehme oder so neustarte. Die Schaltung geht erst dann nicht mehr, wenn dann auch die Prüfklemme, die an der SDA oder SCL (egal welche) hängt, getrennt wird. Grüße schnack
3,3V Pegel reicht dem MCP23017 nicht! Das Teil funktioniert mehr schlecht als Recht... Nachdem ich ein Pegelwandler eingebaut hatte, hat alles funktioniert. Falls du keine so hohe Taktfrequenz benötigst, kannst du zusätzlich mit dieser auch etwas runter gehen.
Sorry, ich hatte mit dem MCP23016 gearbeitet, nicht mit dem angeblich "besseren" 17er. Wie gesagt, Pegelwandler hat Abhilfe geschafft.
Hallo, das ist mal ein neuer Gedanke! Allerdings kann der MCP23017 laut Datenblatt zwischen 1,8V und 5V arbeiten, siehe http://ww1.microchip.com/downloads/en/DeviceDoc/21952b.pdf. Ich hatte den MCP23017 bislang mit 5V betrieben (am Atmega644), klappte anstandslos - und habe dies jetzt genauso am XMC4500 mit 3,3V erwartet. In http://www.raspberrypi.org/phpBB3/viewtopic.php?f=44&t=46896 wird übrigens gerade anders herum beschaltet. Der MCP23017 wird schon mit 3,3V betrieben (klappt) und soll an den Raspberry Pi angeschlossen werde (5V) - und es wird als Abhilfe wieder ein Pegelwandler vorgeschlagen. Verwirrend, die Sache. Grüße schnack P.S.: Der MCP23016 sollte auch 2V-5V als Versorgungsspannung unterstützen (auch hier Quelle: Datenblatt). Merkwürdig.
Mmn. war bei meinem damaligen Projekt eines der beiden Probleme die Fehlerursache: 1. Die Flankensteilheit ließ sehr zu wünschen übrig (Ähnlich wie bei dir jetzt) -> Taktfrequenz runtergesetzt :D 2. Der MCP23016 bzw. 17 kam mit dem 3,3V Pegel des RPI nicht klar. Da ich beide Lösungen gleichzeitig implementierte, kann ich im Nachhinein nicht 100% sagen was genau das Problem war. Kannst du mal ein ausführlicheres Oszi Bild von einem fehlgeschlagenen Sendevorgang zeigen? Wann genau bricht er den Vorgang ab? Bei mir kam nach dem ersten Byte oftmals noch ein Acknowledge, irgendwann stieg er dann aber aus... Gruß
Hallo, das gelingt mir leider nicht. Zwar kann ich einen Abbruch provozieren (mit dem "LED-Entfernen-und-wieder-anbringen-Trick". Allerdings hängt der µC genau dann, wenn er wieder senden will. Es gibt also keine fehlerhafte Sendung - es geht dann einfach nichts mehr raus. Und vorher war die Welt anscheinend in Ordnung. Die SCL- bzw. SDA sind in der ganzen Zeit auf 3,3V. Die Flankensteilheit ist an sich optimal eingestellt ("strong driver, sharp edge"), siehe: http://www.mikrocontroller.net/articles/Datei:Strong_Driver_Sharp_Edge.jpg Der Flankenverlauf im Scope sieht aber ganz anders aus.. Alles deutet darauf hin, dass die Kommunikation extrem empfindlich ist: die LED-Geschichte, das Verhalten mit den Scope-Kabeln. Nach einer Weile (5..10 Minuten) bricht aber auch dann die I2C-Verbindung ab, gerade bemerkt :-( Den I2C-Takt kann ich auch auf 1kHz drosseln und prüfen, ob es dann besser geht (wenn der MCP23017 mitmacht..). Grüße schnack
Da hat doch bestimmt wieder jemand die Abblockkondensatoren vergessen;)
Hallo Holger, Kondensator an der RESET-Leitung des MCP23017? In der Tat, der fehlt. Aber erklärt dies, warum der MCP23017 im laufenden Betrieb nicht mehr weitermacht? Beim Betrieb mit 5V hat das Fehlen des Kondensators auch nichts ausgemacht. Grüße schnack
C. D. schrieb: > ... Um noch eins "drauf zu setzen": ... Solche tollen "Effekte" kann man mit jedem schlechten Aufbau und etwas Fantasie wahllos und zur Genüge produzieren. Das ist sicher interessant und spannend, aber selten zielführend. > ... Der ganze Aufbau ist auf einem ProtoBoard (weitgehend > Klemmverbindungen). Oh weh, wie stark hast du dein ProtoBoard bisher beansprucht? - Stichwort: ausgeleierte Kontakte. > Die Versorgungsspannung habe ich via Oszi geprüft - sehe keine > Besonderheiten. Ein angeschlossenes Multimeter lieferte allerdings > Sprünge im Bereich 3,1..3,5V. Wenn du die Sprünge schon am Multimeter sehen kannst, ist das sehr bedenklich. > ... [weitere Vemutungen und Glaubensbekenntnisse] ... Nun lege endlich mal die Karten auf den Tisch, d.h. Schaltung (so wie du sie aufgebaut hast!) und Fotos. ;-)
Danke für das Oszillogramm, siehe die fallende Flanke des türkisen Signals. Falk, ich bleibe dabei: Ringing auf der fallenden Flanke des türkisen Signals --> Fehler, da der Empfänger mehrere Übergänge H-L-H-L sieht. Widerstand in Serie einfügen. Aufbau auf Breadboard ist halt nicht ideal.
Hallo, die Beschaltung des MCP23017 habe ich beigefügt. Sie ist auf einem PCB aufgebaut. Der XMC4500 ist via Relax Light Kit auf einem BreadBoard aufgesteckt. Foto vom Ganzen ist auch dabei. Grüße schnack
Und hier der SDA/SCL-Verlauf mit 1kHz. Die beschriebenen Empfindlichkeiten bleiben aber .. (LED-Geschichte, Scope-Kontakte..). Grüße schnack
C. D. schrieb: > Hallo, > die Beschaltung des MCP23017 habe ich beigefügt. Sie ist auf einem PCB > aufgebaut. Der XMC4500 ist via Relax Light Kit auf einem BreadBoard > aufgesteckt. Foto vom Ganzen ist auch dabei. Gleich auf den ersten Blick: C2 ist zu klein, keine Abblockkondensatoren an IC5 und IC6.
C. D. schrieb: > Hallo, > die Beschaltung des MCP23017 habe ich beigefügt. Sie ist auf einem PCB > aufgebaut. Der XMC4500 ist via Relax Light Kit auf einem BreadBoard > aufgesteckt. Foto vom Ganzen ist auch dabei. > > Grüße > schnack Auf den zweiten Blick: Wo ist die Masse-Verbindung zwischen dem XMC4500 und dem MCP-Board?
Hallo Michael, das fängt ja gut an. Danke für Deine Hinweise! Mir ist allerdings nicht klar, warum die gleiche Schaltung bei 5V problemlos funktionierte. Will sagen: warum wird der Aufbau empfindlicher/instabil, wenn ich ihn mit 3,3V betreibe? Warum können die von Dir angemerkten Punkte hier mit Sicherheit Besserung schaffen? Die gemeinsame Masse-Verbindung ist auf dem Foto nicht zu sehen- weil sie sich diese Verbindung Richtung Breadboard und PCB gabelt (und ich das Foto nicht noch unübersichtlicher machen wollte). Ich kann aber beide Masseanschlüsse (XMC4500, MCP) mal direkt verbinden. Grüße schnack
C. D. schrieb: > Ich kann aber beide Masseanschlüsse (XMC4500, MCP) mal direkt verbinden. Die Masse muss unbedingt auf dem kürzesten Weg zwischen den Modulen verbunden werden. Jeder Umweg ist eine Antenne für Störungen!
:
Bearbeitet durch Moderator
Hallo Michael und Lothar, also die Frage nach der Masseverbindung, die war nicht schlecht.Die Masseverbindung wird tatsächlich über mehrere Boards zu dem Testboard gebracht (Gesamtlänge ca. 50cm..70cm). Der XMC hängt über einen anderen Zug (etwa 40cm) am selben Massepunkt. Die I2C-Verbindung klappt nach der direkten Verbindung deutlich besser. Ich habe die Geschwindigkeit gleich mal auf 400kHz gesetzt, geht auch. Die SDA/SCL-Signalverläufe dafür sind beigefügt. Allerdings, die LED-Empfindlichkeit bleibt.
C. D. schrieb: > Hallo Michael, > das fängt ja gut an. Danke für Deine Hinweise! > > Mir ist allerdings nicht klar, warum die gleiche Schaltung bei 5V > problemlos funktionierte. Will sagen: warum wird der Aufbau > empfindlicher/instabil, wenn ich ihn mit 3,3V betreibe? Möglicherweise geringere Störabstände, oder aber Zufall, dass es mit 5V lief. > Warum können die > von Dir angemerkten Punkte hier mit Sicherheit Besserung schaffen? Google hilft ... z.B. http://www.rn-wissen.de/index.php/Abblockkondensator und http://www.rn-wissen.de/index.php/GND Bitte auch mal selbst über angesprochene Fachbegriffe informieren, nicht aller vorkauen lassen. ;-) > Die gemeinsame Masse-Verbindung ist auf dem Foto nicht zu sehen- weil > sie sich diese Verbindung Richtung Breadboard und PCB gabelt (und ich > das Foto nicht noch unübersichtlicher machen wollte). Ich kann aber > beide Masseanschlüsse (XMC4500, MCP) mal direkt verbinden. Mach das auf jeden Fall. Der "Umweg" über die Zuleitungen der Stromversorgung ist ungeeignet. 1. fängst du mit jedem Zentimeter Leitungslänge zusätzliche Störungen ein, und 2. erzeugen die Ströme in den Zuleitungen ebenso Störungen. Grüße.
Hi, Ohne Abblock-Kondensatoren können digitale Schaltungen machen, was sie wollen. Auch mit 5V funktionieren, aber mit 3V nicht mehr. Und das kannst Du ja schnell testen, einfach an beide ICs an VCC/GND 10 bis 100 nF dran. Gruß
Hallo zusammen, das probiere ich auf jeden Fall aus .. aber nicht mehr heute. Melde mich wieder.. Grüße schnack
@C. D. (schnack) >Die Flankensteilheit ist an sich optimal eingestellt ("strong driver, >sharp edge"), siehe: Das ist NICHT ideal! So langsam wie möglich, so schnell wie nötig. Auf deinen Oszibildern kann man sehen, dass die fallende Flanke extrem steil ist, das braucht keiner und macht ggf. Probleme. Ausserdem klingelt es ordentlich, wie man an der negativen Spannungsspitze sehen kann. >Alles deutet darauf hin, dass die Kommunikation extrem empfindlich ist: Weil dein Aufbau alles andere als solide ist. Man kann es nicht oft genug wiederholden. http://www.mikrocontroller.net/articles/Kondensator#Entkoppelkondensator !!!! >Den I2C-Takt kann ich auch auf 1kHz drosseln und prüfen, ob es dann >besser geht (wenn der MCP23017 mitmacht..). I2C geht beliebig langsam, weil es synchron ist. 400kHz ist mit deinen Pull-ups grenzwertig, die muss man dafür kleiner machen, die Häfte oder so.
Hi, ich kenne das Phänomän und hatte es schon - I2C funktioniert nur dann, wenn man die Tastköpfe des Oszis dranhängt. Das bei mir aber trotzt sauberem Layout und Leiterbahnen < 5cm. Teilnehmer: ein PIC und ein Microchip EEPROM. Ich persönlich vermute Reflexionen oder Einstrahlung, vermutlich auf den sehr hochohmigen HIGH-Zustand des Busses zurückzuführen. Das ließe sich mit aktiven Tastköpfen mit <1pF verifizieren, welche ich nicht habe. Was hir vermutlich hilft, ist die kleine Kapazität des Tastkopfes. Das sind aber nur Vermutungen... Lösung bei mir: Den Tastkopf in die Schaltung einbauen ;-): In I2C immer dann, wenn wenige Teilnehmer im Bus sind zu Ende der Leitung 47pF gegen Masse hineinhägen (ok, das ist etwa mehr als ein Tastkopf hat...). Das kann manchmal helfen, weil der Bus für HF etwas niederohmiger wird. Wichtig ist, die maximale Kapazität des Busses nicht zu überschreiten - d.h. die Summe der Kapazitäten darf mit den Pullups keine zu hohe Zeitkonstante bilden. Probier es doch mal. I2C stellt im Übrigen sehr hohe Ansprüche an das Layout / die Verkabelung - wegen des hochohmigen High-Zustandes. Daher sollte man I2C wenn möglich nicht zur Verkabelung von Platinen verwenden, weil es gegen Störungen sehr empfindlich ist.
Humpfdidumpf schrieb: > I2C stellt im Übrigen sehr hohe Ansprüche an das Layout / die > Verkabelung - wegen des hochohmigen High-Zustandes. Eigentlich nicht. Wenn I2C so empfindlich wäre, dann wäre der Bus schon lange aus der Unterhaltungsindustrie rausgeflogen. Und ein Pullup mit 1kOhm (bei 3V und 100kHz) bzw. 180 Ohm (bei 3V und 1MHz Fast Mode Plus) ist nicht mehr "hochohmig" im Sinne von "unglaublich störempfindlich". Nur unterliegt I2C eben auch der allgemeinen Physik, und man kann mit simplen Pullups niemals die Geschwindigkeiten eines richtig terminierbaren Busses erreichen. C. D. schrieb: > Pullups sind verbaut (4,7k je für SDA und SCL). Das Berechnen dieses Widerstands eine Wissenschaft für sich. Man suche einfach mal im Users Manual nach "resistor": http://www.nxp.com/documents/user_manual/UM10204.pdf Mach deine Widerstände einfach mal niederohmiger. Mit 2k2 fahre ich seit langem ganz gut... > Daher sollte man I2C wenn möglich nicht zur Verkabelung von Platinen > verwenden, weil es gegen Störungen sehr empfindlich ist. Ich habe hier einige CD- und DVD-Player, die das machen und auch ein paar Autoradios, Verstärker und sonstiges Zeug. Aber es hilft immer, wenn man sich vor Augen hält, was IIC bedeutet: "Inter IC Connection" also Verbindungen zwischen einzelnen ICsauf einer Platine.
:
Bearbeitet durch Moderator
@ Lothar Miller Ich kann nur aus meiner Erfahrung sprechen (hier: Industrie). Wenn ich so zurückdenke, welche Busse die Probleme bei den EMV-Tests hatten (Immunität), war es eben oft I2C. Der High-Pegel ist eben doch hochohmiger als bei einem Push-Pull-Bus, wodurch bie Einstrahlung / kapazitiver Kopplung einfach mehr Störpegel stehenbleibt bleibt als bei Push-Pull. bei z.B. 50E Impedanz (Push-Pull) und 1k (Pullup) ist das immerhin Faktor 20. Bei Audio werden natürlich andere Anforderungen gestellt, da heizt man auch nicht mit 20V/m HF drauf oder 16,5kV ESD. Ich habe beim TÜV mal live miterlebt, wie ein solches Gerät (ein Radio für Unterputz) auf einen "richtigen" Surge reagiert hat: Mit einem kleinen Brand ;-).
> I2C geht beliebig langsam, weil es synchron ist.
Das stimmt, allerdings ändert sich die Fehlanpassung dadurch überhaupt
nicht.
Nur übersieht man das Ringing (Klingeln) bei langsamer Zeitbasis leicht
am Oszi. Zoome mal in die fallende Flanke.
Auf den Tipp mit dem C nach Masse habe ich gewartet, der ist jedoch
kontraproduktiv, da dadurch nur die Ring-Frequenz gesenkt wird.
Außderdem wird durch den höheren Strom noch mehr Noise erzeugt, auch auf
Gnd.
Die Ursache muss bekämpft werden, und das ist die Reflexion auf Grund
der Fehlanpassung.
Zum PullUp: ein kleinerer R dämpft das Ringing stärker, oft geht es
dadurch besser.
Das Problem ist jedoch die fallende Flanke, da dort das komplexe Gebilde
Leitung (Induktivität) / Kapazität steil = niederohmig angeregt wird.
33 - 100 Ohm in die Leitung eingefügt (evtl. an beiden Enden) und alles
wird gut.
@ Humpfdidumpf (Gast) >wenn man die Tastköpfe des Oszis dranhängt. Das bei mir aber trotzt >sauberem Layout und Leiterbahnen < 5cm. Teilnehmer: ein PIC und ein >Microchip EEPROM. Dann hast du elementar was falsch gemacht. >Ich persönlich vermute Reflexionen oder Einstrahlung, vermutlich auf den >sehr hochohmigen HIGH-Zustand des Busses zurückzuführen. jaja, die beliebte Kaffeesatzleserei. > Das ließe sich >mit aktiven Tastköpfen mit <1pF verifizieren, welche ich nicht habe. >Was hir vermutlich hilft, ist die kleine Kapazität des Tastkopfes. >Das sind aber nur Vermutungen... Jaja. >Wichtig ist, die maximale Kapazität des Busses nicht zu überschreiten - >d.h. die Summe der Kapazitäten darf mit den Pullups keine zu hohe >Zeitkonstante bilden. Dann kann man ggf. mit der Taktrequenz runter gehen. >I2C stellt im Übrigen sehr hohe Ansprüche an das Layout / die >Verkabelung - wegen des hochohmigen High-Zustandes. LÄCHERLICH! >Daher sollte man I2C >wenn möglich nicht zur Verkabelung von Platinen verwenden, weil es gegen >Störungen sehr empfindlich ist. Lächerlich ^2! >Ich kann nur aus meiner Erfahrung sprechen (hier: Industrie). Du bist ein Bastler vor dem Herrn!
Humpfdidumpf schrieb: > I2C stellt im Übrigen sehr hohe Ansprüche an das Layout / die > Verkabelung - wegen des hochohmigen High-Zustandes. Daher sollte man I2C > wenn möglich nicht zur Verkabelung von Platinen verwenden, weil es gegen > Störungen sehr empfindlich ist. Das wird wohl dein Problem sein. Die DDC-Leitungen in deinem Monitorkabel, die ja ein I2C Bus sind, funktionieren natürlich nicht. Daher mußtest du diesen Text blind eintippen und konntest ihn nicht noch mal kontrolllesen. MfG Klaus
Und natürlich auch keine PS2-Tastatur, die mit einem ähnlichen Verfahren arbeitet...
Hallo, so. Mehrere Fixes sind jetzt umgesetzt: * Abblockkondensatoren mit jeweils 100nF bei jedem MCP23017 eingefügt (siehe Foto, zeigt einen MCP23017 von "unten") * 220µF Kondensator eingesetzt anstelle des 22µF (C2) * 2,2k Pullup-Widerstände verwendet Der so erreichte Fortschritt erscheint nicht so groß wie das Verbinden der Massepunkte XMC und MCP gestern. Ich habe die Verläufe für SDA/SCL bei 400kHz wieder angehängt (einmal zeitlich aufgelöst wie bei vorherigen Messung, einmal mit kleinerer Zeitbasis). Ich prüfe noch, ob ich an dem XMC4500 die Pad-Schalteigenschaften im I2C-Modus umstellen kann (wegen Überschwinger bei H->L). Das ursprüngliche Problem (I2C geht nur mit Scope) ist bereits durch die Masseverbindung gelöst worden (Chapeau!). Die LED-Geschichte gibt es immer noch, allerdings "springt" die I2C-Verbindung auch wieder an, wenn ich den Klemmenkontakt ein paar Mal öffne/schließe. Vorher war danach der XMC4500 in der Endlosschleife gefangen. Trotzdem: irgendwo ist noch was und ich habe es nicht verstanden. Die LED hängt über den ULN2803, der ja die Masseverbindung durchschaltet, und einem 2k Widerstand an der Ausgangsversorgungsspannung von 7,5V (Verbindungsstrecke: 0,5m). Grüße schnack
Schauen Sie mal, dass Sie Ihre Haifischflossen verbessern. Das sollte eigentlich rechteckförmig sein. Solange Sie keine EMV-Probleme haben oder den EMV-Award des Jahres gewinnen müssen, müssen die Flanken (natürlich nur die steigenden!) nicht absichtlich verschliffen werden.
Jede wette, dass noch irgendwo eine masseverbindung fehlt. Ich hatte genau diesselben Probleme, vom tastkopf über die "springende" spannung zu den "haifischflossen". hat alles solala trotzdem funktioniert weil es irgendwelche "floating" masseverbindungen gab (so, wie vcc manchmal über umwege kommt). Sauber hat alles erst dann funktioniert, als die fehlende masseverbindung hergestellt war...
Hallo, ich suche weiter. In der Zwischenzeit habe ich die Pads auf "Medium Driver" umgestellt. Die Flanken zeigen jetzt immerhin keine Überschwinger mehr auf. Grüße schnack
Hi, Auch wenn es ein Vorredner schon mal ähnlich geschrieben hat: Simuliere doch die Tastköpfe an den I2C Leitungen durch entsprechende Cs von etwa dem Wert, der auch die Probe hat (10pF ?). Dabei mal alle Möglichkeiten (C an SDA, C an SCL, jeweils ein C an beide Leitungen) ausprobieren. Die meisten Probleme bei I2C, die ich bisher gesehen habe, resultieren aus nem Softcore und sind nicht dem Layout / Treiber geschuldet. Da springt nen Slave an, wenn Daten eines anderen Slaves seine Adresse beinhalten... Solange die PullUps zur Buskapazität passen halte ich I2C für unkritisch. Mag sein, dass sich der ein- oder andere Teilnehmer nicht an die Spec hält (Fall Times < 20ns , kein 50ns Glitchfilter). Das "Ringing" bei fallenden Flanke ist wahrscheinlich ein Messartefakt. Du hast dann Fall Times von deutlich <5ns, weder Deine Probe, noch Dein Scope hat die Bandbreite, dass richtig zu messen. Habs selbst schon mal ausprobiert : 500MHz passive Probe / 500 MHz Scope bis 6GHz Active Probe / 7GHz Scope ist Ringing im bereich 500mV bis nix mehr zu sehen bei knapp 1ns Fall Times. Gruß
@ Marvin (Gast) >Die meisten Probleme bei I2C, die ich bisher gesehen habe, resultieren >aus nem Softcore und sind nicht dem Layout / Treiber geschuldet. >Da springt nen Slave an, wenn Daten eines anderen Slaves seine Adresse >beinhalten... Was natürlich ein grober Fehler ist. >Solange die PullUps zur Buskapazität passen halte ich I2C für >unkritisch. Mag sein, dass sich der ein- oder andere Teilnehmer nicht an >die Spec hält (Fall Times < 20ns , kein 50ns Glitchfilter). GENAU! >Das "Ringing" bei fallenden Flanke ist wahrscheinlich ein Messartefakt. Wahrscheinlich. Dennoch sind solche "Mörderflanken" unsinnig und kontraproduktiv. Es gilt immer: So langsam wie möglich, so schnell wie nötig.
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.