Hallo Forengemeinde,
ich habe gerade ein Problem mit dem I2C Bus :-(. Es geht um die
Ansteuerung eines Display Controllers (UC1601s) mittels RL78 Controller
von Renesas. Die I2C Busansteuerung habe ich per SW nachgebildet
(Emulation der Open Drain Ausgänge mittels GPIO), d.h. die Peripherie
verwende ich nicht. Das Display zeigt auch schon was sinnvolles an. Mein
Problem ist nur, dass ich immer wieder mal NACKs vom Display Controller
empfange. Wenn ich mir das Ganze auf dem Scope ansehe wird eine Sequenz
von Bytes sauber übertragen, d.h. ich bekomme immer ein Ack nach dem 8.
Bit. Dann kommt aber immer wieder mal ein ACK des Display Controllers
schon beim 8. Datenbit wodurch ich dann in meiner Software beim 9. Bit
ein NACK erkenne.
Kann mir hier vielleicht einer weiterhelfen? Einen Screenshot habe ich
angehängt.
Danke schon mal im voraus!
Viele Grüße...
Wo hast du die Signale denn gemessen? Am Controller oder am Display?
Vermutlich am Controller...
Sieht mir so aus, als ob das Display keine saubere Clock sieht, und sich
deswegen "verzählt" (Doppeltrigger).
Du könntest mal versuchen die Clockrate runterzusetzen (momentan hast du
ja ca. 240KHz, gehe mal testweise auf 50 oder so), um zu gucken, ob das
Problem dann verschwindet.
Ausserdem die Signale mal direkt am Display messen, ob da auch noch
saubere Pegel da sind - vielleicht hast du auch Serienwiderstände oder
Ferrite drin (der etwas erhöhte Low-Pegel bei Antworten vom Display
lässt darauf schließen), die die CLK am Display verhunzen...
Hi Joe,
danke für Deine Antwort. Gemessen habe ich zwischen Controller und
Steckverbinder zum Display, d.h. sehr nahe am Steckverbinder. Das
Display selber ist über ein FPC mit der Leiterplatte verbunden. Direkt
am Displaycontroller kann ich leider nicht messen (Chip on Glas und
alles vergossen :-() Ich werde die Datenrate mal reduzieren.
Ich hatte auch schon ein wenig die Versorgung in Verdacht da ich beim
Schalten auf Low immer einen leichten Einbruch der VCC sehe. Einen
anderen Versuch den ich machen wollte ist die VCC leicht zu erhöhen. Mal
sehen was dann passiert.
Von der Schaltung her verwende ich einen Pullup von 3k3 mit jew. 15pF
von SDA/SCL auf Masse. Wie ist deine Meinung zu den Kondensatoren? Rein
von der Buskapazität müsste es denke ich passen.
Viele Grüße...
Gonzo schrieb:> Von der Schaltung her verwende ich einen Pullup von 3k3 mit jew. 15pF> von SDA/SCL auf Masse. Wie ist deine Meinung zu den Kondensatoren? Rein> von der Buskapazität müsste es denke ich passen.
Ich habe noch nie Kondensatoren am I2C Bus gesehen. Damit vergrößert man
doch nur die Buskapazität.
Habe jetzt mal die Frequenz sehr stark reduziert. Das Problem tritt
immer noch auf.
Was ich eben noch vergessen habe: Im LCD Controller ist denke ich noch
ein Serienwiderstand drin. Deshalb geht der Pegel beim ACK nicht
komplett auf GND runter. Im Anhang ist jetzt ein Bild mit reduzierter
Frequenz.
Gonzo schrieb:> Von der Schaltung her verwende ich einen Pullup von 3k3 mit jew. 15pF> von SDA/SCL auf Masse. Wie ist deine Meinung zu den Kondensatoren?
Raus damit.
Versuche es auch mal mit 2.2K Pullups (Standard bei 3.3V).
> Rein von der Buskapazität müsste es denke ich passen.
Du erhöhst ja die Buskapazität, und das ist keinesfalls ein Vorteil. Im
Gegenteil, es belastet die I2C Treiber zusätzlich.
Gonzo schrieb:> Im LCD Controller ist denke ich noch> ein Serienwiderstand drin. Deshalb geht der Pegel beim ACK nicht> komplett auf GND runter.
Ist ja momentan sogar ganz nützlich, um zu erkennen, welche Seite SDA
auf low zieht.
Und der low Pegel sieht auch in Ordnung aus.
Nach wie vor glaube ich an eine schlechte Clock am LCD - oder ein
Problem mit GND.
Kannst du SCL hinter dem Serienwiderstand (auf der Display Seite)
messen?
Gonzo schrieb:> Einen> anderen Versuch den ich machen wollte ist die VCC leicht zu erhöhen
Würde ich nicht machen.
Im Datenblatt des UC1601s steht folgendes:
VIH Input logic LOW 0.2xVDD (max.)
Das sind bei 3.3V 0.66V.
Evtl. ist dein SCL low Signal am Display da schon knapp an der Grenze
(durch den Serienwiderstand).
Wo sitzen denn die Pull-Ups? An der Display-Seite oder der
Controller-Seite der Serienwiderstände?
Ausserdem:
Gonzo schrieb:> Das> Display selber ist über ein FPC mit der Leiterplatte verbunden.
Wie lange ist das FPC?
Sind auf dem PCB andere Signale nahe und parallel zum SCL Trace verlegt?
Evtl. streut dir ein anderes Signal in SCL ein.
Du solltest irgendwie versuchen, am Displayende SCL vom FPC abzugreifen
und am Oszi angucken.
Das FPC hat eine Länge von ca. 2cm. Direkt am Displaycontroller zu
messen wird schwierig. Wie gesagt. Ist alles vergossen. Ich könnte mal
versuchen durch das FPC zu stechen und dann zu messen. Ich habe aber
inzwischen auch die Vermutung dass ich ein Verbindungsproblem habe und
ich mir dadurch Takte einfange. Im FPC sind eigentlich keine Signale
verlegt. Die Belegung ist: SCL, SDA, 3.3V, GND, VB1+, VB1-, VB0-, VB0+,
VLCDOUT, VLCDIN
Die Pullups sind auf der Leiterplatte relativ nahe am FPC Sockel (<5mm).
Hallo, ich habe exakt das selbe Problem mit einem EA DOGXL240N-7 und dem
enthaltenen UC1611s Controller, den ich mit Hardware I²C von einem
STM32F373CC aus ansteuere. Die Häufigkeit mit der dies auftritt erhöht
sich wenn das Oszilloskop angeschlossen ist. An den I²C Leitungen sind
keine Kapazitäten, nur 4.7kΩ Pullups, und sie sollten eigentlich gut
gelayoutet sein (Layout ist nicht von mir).
Auf dem Oszilloskop sieht es eigentlich gut aus, ist direkt am LCD-Modul
gemessen.
Was ich beobachten konnte: Der durch den Controller produzierte
Low-Pegel enthält Störungen im Takt der Ladungspumpe.
Meine "Lösung" ist bis jetzt den Controller per Reset-Leitung
zurückzusetzen wenn dies auftritt. An einer richtigen Lösung wäre ich
auch sehr interessiert...
Niklas Gürtler schrieb:> Die Häufigkeit mit der dies auftritt erhöht> sich wenn das Oszilloskop angeschlossen ist.
Und das ist ein deutliches Zeichen dafür, dass mit der Signalqualität
etwas nicht stimmt.
Dein Fall könnte aber anders gelagert sein, als der von TO.
Dein Timing ist gefährlich.
Bei I2C sollte der Master niemals SDA gleichzeitig mit SCL ändern (was
bei dir auf fallenden SCL Flanken passiert).
Dadurch kannst du unabsichtlich START oder STOP conditions erzeugen...
Immer SDA ändern -pause- SCL high -pause- SCL low -pause- SDA ändern
etc.
Joe F. schrieb:> Bei I2C sollte der Master niemals SDA gleichzeitig mit SCL ändern (was> bei dir auf fallenden SCL Flanken passiert).> Dadurch kannst du unabsichtlich START oder STOP conditions erzeugen...> Immer SDA ändern -pause- SCL high -pause- SCL low -pause- SDA ändern> etc.
Okay, das ist so die Standardeinstellung vom Hardware I²C. Laut
Datenblatt des Controllers muss SDA mindestens 11ns nach der fallenden
Flanke von SCL anliegen (hold time), und das ist bei mir mehr als
erfüllt (sieht man auf obigem Oszillogramm nicht so gut). Wenn schon
könnte man sich so eine Start Condition generieren (Stop Condition wäre
steigende SCL Flanke), aber dafür müsste SDA vor SCL fallen, was aber
nicht der Fall ist.
PS: Bei Gelegenheit werde ich aber mal probieren ein längeres Delay
einzustellen...
Niklas Gürtler schrieb:> aber dafür müsste SDA vor SCL fallen, was aber> nicht der Fall ist.
Wenn die Buskapazität von SCL einen Tick höher ist als die von SDA kann
das durchaus passieren (SCL wird verzögert).
Hier gibt's übrigens einen weiteren Fall:
Beitrag "DOG XL 240-7 antwortet ab und zu mit NAK?"
Er hat es am Ende durch Fehlererkennung und Retry gelöst.
Scheint wohl kein so toller Display Controller zu sein.
Gonzo schrieb:> Ich habe aber> inzwischen auch die Vermutung dass ich ein Verbindungsproblem habe und> ich mir dadurch Takte einfange. Im FPC sind eigentlich keine Signale> verlegt. Die Belegung ist: SCL, SDA, 3.3V, GND, VB1+, VB1-, VB0-, VB0+,> VLCDOUT, VLCDIN>> Die Pullups sind auf der Leiterplatte relativ nahe am FPC Sockel (<5mm).
Und die Serienwiderstände, wo sind die? Zwischen RL78 und Pullups?
Wenn ja: brücke die mal mit 0R. SCL Low muss auch am Display (deutlich)
unter 0.6V bleiben.
Füge auch mal noch zusätzliche Kondensatoren nahe am FPC Connector
zwischen 3.3V und GND ein (4.7u, 100n).
Moin,
die Serienwiderstände sind denke ich im LCD Controller integriert. Ich
gehe zumindest davon aus, da der ACK Pegel des Controllers nicht 100%
auf Masse runter geht. Sonst sind keine Serienwiderstände verbaut.
Am FPC Stecker befindet sich ein Kondensator mit 220nF. Ein weiterer
100nF und 2,2uF befindet sich im Bereich des Netzteils welches ca. 1cm
weit weg ist.
Vielen Dank nochmal für die Hilfe! Ich werde noch ein paar Versuche mit
den Pullups und Kondensatoren machen. Was ich aber auf SW Seite noch
machen muss ist eine saubere Verarbeitung der Fehler. Wahrscheinlich wie
oben mit einem Retry im Fehlerfall.
Viele Grüße...
Joe F. schrieb:> Versuche es auch mal mit 2.2K Pullups (Standard bei 3.3V).
Ich wuerde eher versuchen die Pullups hochohmiger zu machen und die
Geschwindigkeit zu senken. Wenn er die niederohmiger macht hat der
Serienwiderstand ja noch mehr Spannungsabfall und sein Low geht weiter
nach oben.
Funktioniert das Display denn überhaupt in einem anderen Umfeld?
Die Ratschläge, die 15 pF als großes Übel auszumachen oder an ein paar
Widerständen herumzuspielen, wirken doch sehr hilflos.
Die Signale sehen für mich nicht so schlecht aus, als daß es nicht
funktionieren sollte.
Gonzo schrieb:> Das FPC hat eine Länge von ca. 2cm.Christopher B. schrieb:> Ich wuerde eher versuchen die Pullups hochohmiger zu machen und die> Geschwindigkeit zu senken. Wenn er die niederohmiger macht hat der> Serienwiderstand ja noch mehr Spannungsabfall und sein Low geht weiter> nach oben.
Full ACK. Bei solchen Längen, auch schon mal 10 bis 20cm hab ich 400kHz
auch schon mit den internen Pullups zuverlässig hin bekommen. I2C Inputs
haben eigentlich immer Schmitt-Charakteristik, da darf die High-Flanke
auch mal krumm sein.
Gonzo schrieb:> Die I2C Busansteuerung habe ich per SW nachgebildet> (Emulation der Open Drain Ausgänge mittels GPIO), d.h. die Peripherie> verwende ich nicht.
Ich würde das Problem eher in der SW vermuten
MfG Klaus
Guckt mal ins Datenblatt. Das Ding kann weit mehr als 400KHz, und das
macht bei einem Displaycontroller ja auch Sinn.
Zu lasch sollten die Pullups also nicht sein.
Allerdings ist es eine gute Idee, zur Fehlereingrenzung mal probeweise
z.B. 10K zu nehmen.
Wenn dann das Problem weg ist, kann man darauf schließen, dass es am
schlechten Low-Pegel liegt.
Joe F. schrieb:> Allerdings ist es eine gute Idee, zur Fehlereingrenzung mal probeweise> z.B. 10K zu nehmen.
Gute Idee? Dürfen es auch 9,1 kOhm sein oder 10k8?
Bei 1 MOhm ist das Problem auch weg, es taucht aber wahrscheinlich eines
neues auf :-(
Gonzo schrieb:> Chip on Glas
Die Dinger sind bekannt für Probleme.
Die SDA/SCL-Leitungen auf dem Glas sind sehr hochohmig (~1k).
Kann daher sein, daß der ACK-Level zu nahe an der Schaltschwelle liegt.
Probier mal größere Pullups (4,7k oder 10k).
Moin moin,
ich habe inzwischen noch ein wenig weiter am I²C Bus geforscht. Die
Signale sahen eigentlich bis hinter den FPC Stecker ganz i.O. aus. Was
mir aber noch aufgefallen ist war, dass ich auf der SDA Leitung mit
jeder Schaltflanke der SCL Leitung einen Spike auf dem Signal hatte. Das
Ganze sah von der Form her wie ein Differenzierglied aus. Meine
Vermutung ist jetzt dass ich ein Übersprechen zwischen den beiden
Signalleitungen SDA/SCL habe was dann am LCD Controller für die Fehler
sorgt. Leider kann ich dort nicht direkt messen, versuche aber noch eine
Möglichkeit zu finden das zu verifizieren.
Was ich aber jetzt gemacht habe ist, die SCL-Leitung über eine Push-Pull
Stufe zu betreiben. SDA ist weiterhin Open Drain. Seit dieser Änderung
hatte ich jetzt kein einziges NACK mehr.
Jetzt hätte ich noch eine Frage:
Laut I2C Spec. kann ich das ja so machen wenn der LCD Controller den
Clock nicht runter zieht (Clock Stretching). Hierzu kann ich nichts im
Datenblatt des Controllers finden. Hat hier vielleicht einer eine Ahnung
ob dieser Ultra Chip Controller ein Clock Stretching implementiert hat?
Vielen Dank nochmal für eure Hilfe!
Gonzo schrieb:> dass ich auf der SDA Leitung mit> jeder Schaltflanke der SCL Leitung einen Spike auf dem Signal hatte. Das> Ganze sah von der Form her wie ein Differenzierglied aus
Cross talk, also kapazitive Kopplung zwischen zwei Signalen. Das bekommt
man noch "besser" hin, wenn man SDA und SCL als Paar führt und am besten
noch verdrillt ;)
Eigentlich sollte zwischen SCL und SDA eine Masseleitung oder ein
passabler Abstand sein.
Gonzo schrieb:> Was ich aber jetzt gemacht habe ist, die SCL-Leitung über eine Push-Pull> Stufe zu betreiben.
Das verstärkt den Effekt noch, die Flanken werden steiler, das
Übersprechen größer. Daran hats also nicht gelegen. Was mir beim
allererste Scope-Bild auffällt ist, das die High-Periode von SCL
ziemlich kurz ist. Könnte es sein, daß das jetzt besser geworden ist?
Gonzo schrieb:> Laut I2C Spec. kann ich das ja so machen wenn der LCD Controller den> Clock nicht runter zieht (Clock Stretching)
"Clock Stretching" findet auch ganz ohne Slave statt. Miss mal die
Taktrate eines I2C HW-Masters ganz ohne Slave am Bus. Dann erhöhe mal
die Kapazität an der SCL-Leitung auf die erlaubten 400pF und miss noch
mal. Die Frequenz wird sinken, weil der Master das High auf SCL
abwartet, bevor er den Timer für seine Highzeit startet. Den Effekt kann
man verkleinern, wenn man die Pullups klein macht, aber nur soweit, daß
man die max. 3mA für die I2C Treiber nicht verletzt.
MfG Klaus
LeCroy7.jpg
(240 KB)
