I2C Acknowledge Problem

[Gonzo (Gast)]

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

[Joe F. (easylife)]

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

[Gonzo (Gast)]

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

[Acknowledger (Gast)]

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.

[m.n. (Gast)]

So richtig schlau werde ich aus Deinem Bild nicht. Mir erscheinen die 
SCL-Impulse zu kurz.

[Gonzo (Gast)]

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.

[Joe F. (easylife)]

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?

[Joe F. (easylife)]

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.

[Gonzo (Gast)]

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

[Niklas G. (erlkoenig)]

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

[Joe F. (easylife)]

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.

[Niklas G. (erlkoenig)]

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

[Joe F. (easylife)]

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

[Joe F. (easylife)]

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.

[Joe F. (easylife)]

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

[Gonzo (Gast)]

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

[Christopher B. (chrimbo)]

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.

[m.n. (Gast)]

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.

[Klaus (Gast)]

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

[Joe F. (easylife)]

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.

[m.n. (Gast)]

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 :-(

[Peter D. (peda)]

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

[Gonzo (Gast)]

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!

[Klaus (Gast)]

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