Forum: Mikrocontroller und Digitale Elektronik I2C Problem: Kein ACK


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Switcher (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ich versuche gerade, ein INA219-Modul (so wie 
[[https://cdn-learn.adafruit.com/downloads/pdf/adafruit-ina219-current-sensor-breakout.pdf]] 
aber von Ali) über einen STM32F103 anzusteuern.

Nachdem der STM32 sich bei Hardware-I2C mit einem dauergesetzten 
Busy-Flag aufgehängt hat (aber das ist eine andere Geschichte), bin ich 
testweise auf Software-I2C umgestiegen.

Das Signal sieht meiner Meinung nach ganz gut aus (gelb=SCL, blau=SDA), 
und das Oszi dekodiert auch die I2C-Daten wie gesendet. Allerdings 
erhalte ich nie ein ACK vom INA219. Dieses müsste doch SDA auf Low 
ziehen, das geschieht aber nicht (roter Pfeil im Oszi-Screenshot).

Die Device-Adresse müsste 0x40 sein (also übertragen 0x80 und 0x81 für 
Schreib- und Lesezugriff), ich erhalte aber nie ein ACK. Habe testweise 
alle Werte von 0..0xff rausgespult, aber ohne Erfolg...

Was mache ich falsch, bzw. was könnte ich noch ausprobieren?

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Hast du die beiden Brücken A0 und A1 auf dem Modul offen gelassen?

von Switcher (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ja, die Brücken sind beide offen. Damit sind A0 und A1 auf GND, und die 
Adresse sollte 0x40 bzw die Daten mit R/W Bit rechts dann 0x80 oder 0x81 
sein.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Also Stromversorgung müsste sowohl 3,3V als auch 5V gehen. SDA und SCL 
sehen gut aus, die Adress-Jumper sind auch richtig.

Mir fällt da nur noch eins ein: Probiere mal, das Netzteil erst in die 
Steckdose zu stecken und einzuschalten, dann verbinde es mit deiner 
Elektronik. Worauf ich hinaus will ist, dass die Versorgungsspannung 
eventuell zu langsam oder unsauber ansteigt.

von Wolfgang (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Switcher schrieb:
> Die Device-Adresse müsste 0x40 sein (also übertragen 0x80 und 0x81 für
> Schreib- und Lesezugriff), ich erhalte aber nie ein ACK. Habe testweise
> alle Werte von 0..0xff rausgespult, aber ohne Erfolg...

Unsicherheiten mit der Adressierung kannst du am einfachsten mit einem 
I2C-Scanner ausräumen - ein Mal durchlaufen lassen und er sagt dir, wo 
jemand zu Hause ist.

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
SDA und SCL vertauscht? Device hat keine Spannungsversorgung? Device ist 
defekt? Überprüfe erst mal ersteres, das ist der Punkt an dem Du die 
einfachste Möglichkeit hattest einen Fehler einzubauen.

: Bearbeitet durch User
von Switcher (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Nein, die Leitungen sind korrekt. Ich greife das Oszi-Signal direkt am 
Modul ab. Versorgung habe ich auch nachgemessen, ist 3.3V.

Defekt könnte natürlich sein...

von Harry L. (mysth)


Bewertung
0 lesenswert
nicht lesenswert
PullUp an SDA & SCL?

von Arduino Fanboy D. (ufuf)


Bewertung
1 lesenswert
nicht lesenswert
Harry L. schrieb:
> PullUp an SDA & SCL?

Das sehe ich sogar, dass dem so ist.

von Harry L. (mysth)


Bewertung
0 lesenswert
nicht lesenswert
Arduino Fanboy D. schrieb:
> Harry L. schrieb:
>> PullUp an SDA & SCL?
>
> Das sehe ich sogar, dass dem so ist.

Ja, das sieht auf den Oszillogrammen so aus - trotzdem ist die frage 
berechtigt.

von STM Apprentice (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Switcher schrieb:
> Was mache ich falsch, bzw. was könnte ich noch ausprobieren?

Ich vermute du ziehst SDA hart auf 1 während du auf das ACK
wartest.

Das muss man auch machen aber nur dafür dass der Open Drain
hochohmig wird. Ist dein SDA Pin auf Open Drain programmiert?

Normalerweise sieht man das im Kurvenverlauf dass der Slave
die Pegelsteuerung übernimmt (wenn er nicht durch äussere
Umstände am Pegel daran gehindert wird).

von STM Apprentice (Gast)


Bewertung
0 lesenswert
nicht lesenswert
STM Apprentice schrieb:
> Normalerweise sieht man das im Kurvenverlauf

--> Kleine Stufe im Rechteck

von Kastanie (Gast)


Bewertung
0 lesenswert
nicht lesenswert
STM Apprentice schrieb:
> STM Apprentice schrieb:
>> Normalerweise sieht man das im Kurvenverlauf
>
> --> Kleine Stufe im Rechteck

Nein, normalerweise sieht man das nicht, da ja nur der "aktive" Zustand 
verschieden sein kann, also nur, wenn auf Low geschaltet wird.
Der Highpegel sollte immer identisch sein.

von STM Apprentice (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Kastanie schrieb:
> Der Highpegel sollte immer identisch sein.

Von einem High Pegel habe ich nicht gesprochen. Eine kleine
Stufe im Pegel bekommt man wenn der Master seinen Low Pegel
aufgibt und auf hochohgmig übergeht, die Pegelgewalt also dem
Pullup bzw dem Slave überlässt.

Das kann aber je nach Master-/Slave-Konfiguration und Reaktions-
geschwindigkeit nicht oder auch nur sehr schwach auftreten.

So gilt auch hier wieder mal: YMMV

von Kastanie (Gast)


Bewertung
0 lesenswert
nicht lesenswert
STM Apprentice schrieb:
> Von einem High Pegel habe ich nicht gesprochen. Eine kleine
> Stufe im Pegel bekommt man wenn der Master seinen Low Pegel
> aufgibt und auf hochohgmig übergeht, die Pegelgewalt also dem
> Pullup bzw dem Slave überlässt.

Du sprichst in Rätseln.
Die "Pegelgewalt" gilt nun mal nur für den LowPegel. Und hier würde man 
nur dann eine eventuelle "Stufe" sehen können, wenn auch ein anderer 
Busteilnehmer den LowPegel erzeugt.
Das ist hier eindeutig nicht der Fall, also vollkommen irrelevant.
Denn wo willst Du sonst eine "Stufe" sehen?

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Die SDA Leitung steigt langsam an, man sieht deutlich die "runde Ecke" 
links oben an der blauen Linie an der Stelle, wo das ACK Signal erwartet 
wird.

Diese Form ist typisch für Pull-Up mit kapazitiver Last. Ich denke, dass 
er hier den I/O Pin schon korrekt als Open-Drain verwendet.

von zyxw (Gast)


Bewertung
0 lesenswert
nicht lesenswert

von A. S. (achs)


Bewertung
0 lesenswert
nicht lesenswert
Wenn das SW-I2C ist, ... warum so schnell? Erstmal ein paar Nops 
zwischen den Flanken, dann ist schonmal eine Signalflanken-Verfälschung 
am Slave ausgeschlossen.

Dass Du Clock und Daten niemals auf High setzt (also immer nur 0 oder 
HI-Impedanz) setze ich mal voraus. Dann kannst Du Slave-Data auch mit 1k 
oder so anschließen. Und mit dem Oszi direkt am Pin prüfen, ob der Slave 
irgendwann überhaupt irgendwas macht. (Deutlicher als der sonst auch 
erkennbare Knick in der Kurve)

von Wolfgang (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Switcher schrieb:
> Was mache ich falsch, bzw. was könnte ich noch ausprobieren?

Du hast zwei Baustellen offen: Soft-I2C und Slave mit unbekanntem 
Zustand.
Hänge irgendeinen bekannten anderen Slave dran und gucke, ob der Bus 
sich damit vernünftig verhält.
Alternativ hänge das INA219-Modul mal an einen anderen Master, von dem 
du sicher bist, dass er funktioniert.

von Dergute W. (derguteweka)


Bewertung
0 lesenswert
nicht lesenswert
Moin,

Nachdem ja schon einiges ausgeschlossen wurde und das Bild so aussieht, 
als ob einfach SDA bzw. SCL oder beide im Nichts enden, statt bei einem 
Slave wuerde ich mal diese Vermutung:

Switcher schrieb:
> Defekt könnte natürlich sein...

erhaerten und durch HW-Tausch verifizieren.

Du koenntest hoechstens beim Timing noch ein bisschen laenger nach der 
fallenden SCL Flanke warten, bis du SDA aenderst. Aber anundpfirsich 
sollt' es so, wie's ist auch funktionieren.

Gruss
WK

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
STM Apprentice schrieb:
> Ich vermute du ziehst SDA hart auf 1 während du auf das ACK
> wartest.

Hab ich auch erst vermutet, aber bei genauerem Blick auf das 
Oszillogramm sieht man deutlich das das dieser Verlauf der Flanken mit 
an Sicherheit grenzender Wahrscheinlichkeit tatsächlich völlig korrekt 
von Open-Drain mit Pullup erzeugt wird. das Oszillogramm sieht aus wie 
aus einem Lehrbuch entnommen. Also an der Stelle würde ich daher nicht 
weiter suchen.

von A. S. (achs)


Bewertung
0 lesenswert
nicht lesenswert
Bernd K. schrieb:
> das Oszillogramm sieht aus wie
> aus einem Lehrbuch entnommen.

nein, eben nicht. Meines erachtens sind die Flanken gleichzeitig oder 
zumindest fast gleichzeitg. Je nach Umschaltschwelle ist da m.E. nicht 
gewährleistet, dass es am Baustein wirklich nacheinander ist.

von HildeK (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Dergute W. schrieb:
> Du koenntest hoechstens beim Timing noch ein bisschen laenger nach der
> fallenden SCL Flanke warten, bis du SDA aenderst.

Ja, es gibt I2C-Bausteine, die etwas empfindlich sind auf die Pausenzeit 
zwischen fallender Taktflanke und dem Wechsel des Datums.
Deshalb wäre das auch mein Vorschlag.

Achim S. schrieb:
> Meines erachtens sind die Flanken gleichzeitig oder
> zumindest fast gleichzeitg.

Naja, das Oszillogramm ist auf 20µs/div eingestellt. Da sieht man die 
Details noch nicht.

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
Achim S. schrieb:
> Bernd K. schrieb:
>> das Oszillogramm sieht aus wie
>> aus einem Lehrbuch entnommen.
>
> nein, eben nicht. Meines erachtens sind die Flanken gleichzeitig oder
> zumindest fast gleichzeitg. Je nach Umschaltschwelle ist da m.E. nicht
> gewährleistet, dass es am Baustein wirklich nacheinander ist.

Doch. Gesampelt wird nämlich bei der aufsteigenden Flanke von SCL. Da 
liegt SDA schon einen halben Takt vorher stabil an, das ist wie aus dem 
Lehrbuch. Die aufsteigenden Flanken sind leicht verschliffen wegen 
Open-Drain, ebenfalls wie aus dem Lehrbuch.

Das Oszillogramm könnte nicht schöner aussehen, es läßt nichts zu 
wünschen übrig. Es ist als ob er die falsche Adresse hätte oder als ob 
der Slave gar nicht angeklemmt oder nicht eingeschaltet wäre. Oder er 
hat am Slave die falschen Pins verwendet wie ich schon weiter oben 
vermutete.

Jetzt hilft nur noch Schaltplan und ein aussagekräftiges Foto um weitere 
anhaltende Spekulationen zu erübrigen und das Rätsel zu lösen.

: Bearbeitet durch User
von HildeK (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Bernd K. schrieb:
> Doch. Gesampelt wird nämlich bei der aufsteigenden Flanke von SCL. Da
> liegt SDA schon einen halben Takt vorher stabil an,

Es sind nur 100ns Setup notwendig, aber bei der fallenden Taktflanke bis 
zu 600ns Hold. Und genau das löst das Oszillogramm nicht sicher auf.

von Switcher (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Das Problem war ein defekter Baustein :-( Damit hatte ich nicht 
gerechnet, meist ist es ja was anderes...

Jetzt läuft alles absolut problemlos mit Software-I2C, auch mit 100kHz.

Zu den anderen Fragen:

- Pullup ist 4.7k, und Outputs natürlich Open Drain. Ich denke, die 
leichte Krümmung bei L->H wegen der kapazitiven Last ist normal.

- Die Flanken treten schon in der richtigen Reihenfolge auch. Ich warte 
im Code jeweils, bis der gesetzte Pegel korrekt zurückgelesen wird.

Weshalb Software-I2C:

Der Grund ist, dass das Hardware-I2C des STM32F103 sich wegen einen Bugs 
im Silizium mit gesetztem Busy-Flag aufhängt 
[[http://www.st.com/content/ccc/resource/technical/document/errata_sheet/7d/02/75/64/17/fc/4d/fd/CD00190234.pdf/files/CD00190234.pdf/jcr:content/translations/en.CD00190234.pdf#page26]], 
und dieses gar nicht so einfach aus diesem Zustand zurückzuholen ist. 
Das geschieht bei mir nach jedem Start des des Systems (Einschalten oder 
neu Flashen).

Jetzt da die Funktion des I2C-Slaves verifiziert ist, werde ich wieder 
auf Hardware-I2C umprogrammieren.

Die Frage bleibt natürlich, weshalb der INA219 kaputt gegangen ist. Ich 
habe zwar nie bewusst die Ausgänge auf Push-Pull und H gesetzt. 
Trotzdem: Wäre das ausreichend, um die OD des Slaves zu zerstören? Oder 
haben diese eine Art von Strombegrenzung, um solche Fälle zu vermeiden? 
Wäre ja sinnvoll.

von Wolfgang (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Switcher schrieb:
> Trotzdem: Wäre das ausreichend, um die OD des Slaves zu zerstören? Oder
> haben diese eine Art von Strombegrenzung, um solche Fälle zu vermeiden?
> Wäre ja sinnvoll.

Hänge auf SDA und SCL jeweils einen Widerstand zwischen Master und 
Slave. Der begrenzt den Strom, muss allerdings so abgestimmt sein, dass 
er die Pegel nicht zu sehr verzieht.

von Bernd K. (prof7bit)


Bewertung
-2 lesenswert
nicht lesenswert
Wolfgang schrieb:
> Hänge auf SDA und SCL jeweils einen Widerstand zwischen Master und
> Slave.

Nein, das ist Nonsens und kontraproduktiv. Es gibt keinen denkbaren Fall 
in dem sowas jemals irgendeinen irgendwie gearteten Vorteil bringen 
könnte. Es bringt nur Nachteile.

von HildeK (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Switcher schrieb:
> Wäre das ausreichend, um die OD des Slaves zu zerstören? Oder
> haben diese eine Art von Strombegrenzung, um solche Fälle zu vermeiden?

Das dürfte nicht sehr wahrscheinlich sein. Selbst wenn du an der Quelle 
HIGH treibst: der hat keine 0 Ohm und der Slave mit LOW auch nicht. 
Längerfristig ist das eher ein thermisches Problem.
Wenngleich ich schon mal einen IC hatte, der bei einem Schluss eines 
Outputs auf GND kaputt ging.

von Wolfgang (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Bernd K. schrieb:
> Es gibt keinen denkbaren Fall in dem sowas jemals irgendeinen
> irgendwie gearteten Vorteil bringen könnte.

Es bringt genau dann Vorteile, wenn man messtechnisch erfassen möchte, 
wer auf dem Bus den Pegel runter zieht und schützt, falls man mit 
Open-Drain Steuerung noch am üben ist.

von Arduino Fanboy D. (ufuf)


Bewertung
1 lesenswert
nicht lesenswert
Bernd K. schrieb:
> Wolfgang schrieb:
>> Hänge auf SDA und SCL jeweils einen Widerstand zwischen Master und
>> Slave.
>
> Nein, das ist Nonsens und kontraproduktiv. Es gibt keinen denkbaren Fall
> in dem sowas jemals irgendeinen irgendwie gearteten Vorteil bringen
> könnte. Es bringt nur Nachteile.

Das ist falsch!
Es gibt einen Fall, wo das richtig massive Vorteile bringt!

Im Feldeinsatz natürlich nicht, aber bei der Diagnose.

von Andreas B. (myratz)


Bewertung
0 lesenswert
nicht lesenswert
Wenn ich mir das Bild so anschaue, seh ich das ACK. Die fallende Flanke 
sorgt dafür, dass der Slave die SDA Leitung auf Low zieht.

Das ist auch richtig so. Siehe Orginal Specification:
https://www.nxp.com/docs/en/user-guide/UM10204.pdf

Seite 10

3.1.6 Acknowledge (ACK) and Not Acknowledge (NACK)

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Andreas B. schrieb:
> Wenn ich mir das Bild so anschaue, seh ich das ACK. Die fallende Flanke
> sorgt dafür, dass der Slave die SDA Leitung auf Low zieht.

Beim 9. Takt (HIGH) muss das ACK anliegen. Womöglich verpasst der Slave 
einen Taktimpuls.

"the receiver can pull the SDA line LOW and it remains stable LOW during 
the HIGH period of this clock pulse"

Während des 9. Taktimpulses haben wir eindeutig ein stabiles High, also 
NACK.

: Bearbeitet durch User
von HildeK (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Arduino Fanboy D. schrieb:
> Es gibt einen Fall, wo das richtig massive Vorteile bringt!

Auch im Feldeinsatz. Ich empfehle mal die I2C-Spec zu lesen:
"Optional series resistors Rs protect the I/O stages of the I2C-bus 
devices from high-voltage spikes on the bus lines and minimize ringing 
and interference."
Das Problem 'Ringing' ist aber eher bei den High-Speed-Devices ein 
Problem.
Der Serienwiderstand kann natürlich auch mit der Eingangskapazität das 
Timing ein wenig verändern und in manchen Fällen helfen.

Im Anhang ein Bild aus besagter Spec, die auch die Grenzen für diesen Rs 
nennt.

Mein Bild ist aus einer älteren Version entnommen (Jahr 2000, als NXP 
noch Philips war). Aktuell ist 
https://www.nxp.com/docs/en/user-guide/UM10204.pdf
von 2014.

von HildeK (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Den Anhang hat es leider nicht gereicht ...

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.