MCP23016 SDA Low

Leopold N. schrieb:

I2C.PNG

Hi,

woher kommen die Spikes auf der SCK-Leitung? Vielleicht bringen die den Baustein so außer Tritt, dass er mit SDA Limbo spielt?

mfg mf

Leopold N. schrieb:

ist eine while Schleife die immer das Selbe sendet

Sieht irgendwie nicht so aus. Auf dem ersten Bild sehe ich 2x:

1. Write auf 0x20: 0x00 (-> ACK)
2. Read von 0x20, Antwort mit NAK

Beim dritten Mal ist es:

1. Write auf 0x20: 0x00 (-> ACK)
2. Weiteres Byte hinterher: 0x01 (-> ACK)

...und dann lässt Du SCL einfach auf High, womit Du den MCP23016 zwingst, sein ACK (Low-Pegel) auf dem Bus zu lassen.

Da muss ich dir tatsächlich Recht geben. Das sieht echt so aus, als würde der µC die 9te fallende Flanke einfach weglassen. Die Frage ist nur wieso? Es handelt sich um einen STM32H7 und das I2C Modul. Dadurch, dass ich in das I2C_TXDR Register schreibe, sollte doch eigentlich automatisch das Byte gesendet werden, auch mit dem 9ten ACK Bit. Warum wird das dieses eine Mal dann nicht gemacht?

Die im Bild gezeigte Sequenz wird in einer while Schleife endlos wiederholt, nicht nur die eine Übertragung.

Das I2C Modul des µC zeigt auch an, dass der Bus busy ist.

Ok, jetzt siehts so aus, als wäre das Problem behoben. Habe ein bisschen gegoogelt zu dem Problem mit der fehlenden fallenden 9ten Flanke und da hat jemand mal erwähnt, die GPIO Speed Settings zu reduzieren, so dass hochfrequente Störungen nicht so einen starken Einfluss haben. Seit dieser Änderung (GPIO Speed von "very high" auf "low" gestellt) scheint es zu laufen.

Danke für die Hilfe

Achim M. schrieb:

woher kommen die Spikes auf der SCK-Leitung?

Masse schlecht angeklemmt. @Leopold: sind die Messspitzen direkt an den Pins das Bausteins angeschlossen und sind ist die beiden(!) Masseklemmen (auf kürzestem Weg) direkt am (nummernlosen) GND Pin des MCP23016 angeschlossen? Denn nur so misst du das Signal, das auch der MCP23016 sieht.

Leopold N. schrieb:

da hat jemand mal erwähnt, die GPIO Speed Settings zu reduzieren, so dass hochfrequente Störungen nicht so einen starken Einfluss haben.

Richtig, dabei geht es aber darum, dass das andere Signale weniger gestört wird. Diese "langsameren" Setttings nimmt man also weniger zum "Verbessern" der Signalqualität, sondern vielmehr zur Reduzierung der Störabstrahlung.

Leopold N. schrieb:

Seit dieser Änderung (GPIO Speed von "very high" auf "low" gestellt) scheint es zu laufen.

Wenn du sowas brauchst, bzw. wenn sowas "hilft", dann steht dein Design aber auf einer schmalen Kante. Wie sieht der Signalverlauf mit dieser Änderung aus?

Lothar M. schrieb:

Wenn du sowas brauchst, bzw. wenn sowas "hilft", dann steht dein Design aber auf einer schmalen Kante.

Ich vermute schwer dass "das Design" nichts anderes ist als ein H7-Eval-Board und ein mit ein paar Dupont-Strippen verbundenes MCP23016-Modul aus der Arduino Ecke. Nichts Verwerfliches, aber dabei von "Design" zu sprechen ist schon krass übertrieben.

Wie üblich haben diese fliegenden Aufbauten ihre ganz eigenen Probleme. Sehr oft einfach zu schlechte Stabilisierung der Versorgungsspannung. Wenn dann noch an dem MCP23016 was dranhängt was auch noch Strom braucht dann wird's schon schwierig, sowohl von der Stromaufnahme her als auch von der Entstörung/Entkopplung. Denn oft werden diese Verbraucher einfach an die Versorgung des Moduls gehängt .... YMMV

Sind mit dem reduzieren der I/O Geschwindigkeit auch diese verdächtigen halben Clockimpulse verschwunden? ab dem 2.Byte kommen da Spitzen nach dem 9 Clockpuls, die auch mal höher werden.

Nun, zum Design: es ist eine extra Platine, auf der sowohl der µC als auch der MCP sitzen. Die Messpunkte sind knapp 10mm vom MCP entfernt, die gesamte Länge des I2C Busses beträgt ca. 55mm. Gemesssen mit dem Logic Pro 16 und SP10 Messspitzen. Messkabel-Länge ca. 10cm Ich würde also ein schlechtes Design mal stark ausschließen. Die Spikes kommen höchstwahrscheinlich durch die 10cm Messkabel, da die GND Leitung hier nicht direkt neben den Signal-Leitungen geführt werden.

Leopold N. schrieb:

Nun, zum Design: es ist eine extra Platine, auf der sowohl der µC als auch der MCP sitzen.

Nun, dann nehme ich alles zurück und behaupte das Gegenteil.

Leopold N. schrieb:

Dadurch, dass ich in das I2C_TXDR Register schreibe, sollte doch eigentlich automatisch das Byte gesendet werden, auch mit dem 9ten ACK Bit. Warum wird das dieses eine Mal dann nicht gemacht?

Das passiert manchmal wenn man ein TX-Register schreibt und nicht auf alle Status-Bits wartet die gelöscht sein sollten/müssten.

Aber warum ist das Problem dann mit den GPIO Settings umgangen?

Leopold N. schrieb:

Aber warum ist das Problem dann mit den GPIO Settings umgangen?

So ein H7 ist ja ein sehr hochfrequentes Teil. Eventuell werden tatsächlich sehr hochfrequente Spikes erzeugt die man mit "einfachen" (niederfrequenten) Oszilloskopen nicht nachweisen kann. Für solche Verdächtigungen würde ich testweise in die SCL- und SDA- Leitungen mal Längswiderstände von 100 bis 200 Ohm einfügen. Sollte dann ähnlichen Effekt haben wie die GPIO Speed Settings.

Leopold N. schrieb:

Aber warum ist das Problem dann mit den GPIO Settings umgangen?

Wastl schrieb:

Eventuell werden tatsächlich sehr hochfrequente Spikes erzeugt

.... was aber nicht erklärt warum das Stehenbleiben nur beim letzten Byte passiert.