MCP23016 SDA Low

[Leopold N. (leo_n)]

Hi zusammen,

ich nutze auf einem PCB an I2C Bus einen MCP23016. An dem Bus hängt noch 
ein anderer IC, mit dem die Kommunikation super klappt.
Nun habe ich das Problem, dass nach einer (scheinbar zufälligen) Anzahl 
von Übertragungen die SDA Leitung vom MCP23016 einfach auf Low gehalten 
wird und damit der Bus blockiert ist, bzw. der µC keine Antwort bekommt.
Im Anhang die I2C Leitungen als Digital und Analog Capture aus dem 
LogicAnalyzer. Hat jemand eine Idee, warum der MCP23016 das macht? Es 
ist übrigens sicher nicht der µC, das habe ich schon getestet.
Die I2C Pull-Ups sind nicht in dem Ausschnitt mit dabei, sind aber auf 
der Platine drauf als 4.7k
Der Fehler tritt aber immer an derselben Stelle der Kommunikation auf 
(ist eine while Schleife die immer das Selbe sendet)

[Achim M. (minifloat)]

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

[Hmmm (hmmm)]

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.

[Leopold N. (leo_n)]

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.

[Leopold N. (leo_n)]

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

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

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?

[Wastl (hartundweichware)]

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

[Matthias S. (Firma: matzetronics) (mschoeldgen)]

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.

[Leopold N. (leo_n)]

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.

[Wastl (hartundweichware)]

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.

[Wastl (hartundweichware)]

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.

[Leopold N. (leo_n)]

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

[Wastl (hartundweichware)]

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.

[Wastl (hartundweichware)]

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.