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?
Angehängte Dateien:
-
DS1Z_QuickPrint3.png
26 KB
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.
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
Angehängte Dateien:
Den Anhang hat es leider nicht gereicht ...
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.