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)
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.
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.
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.
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?
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.
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?
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.
I2C.PNG
(71 KB)
I2C_komplett.PNG
(47 KB)
Schaltplan.PNG
(7,9 KB)
