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?
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.
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.
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.
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...
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.
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).
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.
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
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?
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.
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)
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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)
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.
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.
DS1Z_QuickPrint3.png
(26 KB)
