I2C funktioniert (aber nur mit Oszilloskop)

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).

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

Mach mal n Foto von deinem Aufbau.

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

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.

>Kondensator an der RESET-Leitung des MCP23017?

Ich dachte eher an den zwischen VCC und GND.

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

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

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.

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

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.

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

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ß