I2C-Problem auf dem STM32F303-Prozessor, was passiert mit SDA?

Ich versuche, meiner ferngesteuerten Drohne ein I2C-Display hinzuzufügen. Ich bekomme das Display nicht zum Laufen. Ich nahm den gleichen Code und kopierte ihn auf einen stm32f303k8 Nucleo und brachte das Display zum Laufen. Ich habe den Code zurück auf die Drohne verschoben und auf dem STM32F303cc-Prozessor getestet. Es funktioniert nicht. Die folgenden Signale bilden genau dieselbe Codezeile, die auf beiden Chips über I2c geht. Nun, natürlich neu kompiliert im cubemx-Framework für die verschiedenen Chips. Die gelbe Linie ist scl. Die blaue Linie die Uhr. Die gelbe Linie mit den Schnörkeln stammt von der Drohne, die nicht funktioniert. Die anderen 2 stammen vom Arbeitskern. Was stimmt nicht mit dem Signal auf der Drohne, dem stm32f303cc-Chip? Warum ist es wirklich schnörkellos. Beide haben Pull-Widerstände 2,2k und 4,7k. Warum ist die gelbe Linie unten, oberes Bild, 50/50 zwischen hoch und niedrig aufteilen, was wie das Bestätigungsbit aussieht? Danke

schlechte Kommunikation

gute kommunikation auf stm32f303k8 nucleo

Noch wichtiger: Warum zieht die SDA-Leitung nicht bis zum Boden?
Ich wünschte, ich wusste. Ursprünglich habe ich auf beiden Chips insgesamt 4 4,7-kOhm-Widerstände verwendet, um die Spannung auf den 2 Leitungen auf den 2 Chips hochzuziehen. Ich habe dann den Widerstand auf 2,2 kOhm auf der sda-Linie im oberen Diagramm geändert. Keine Änderung im Aussehen des Diagramms von der Problemdrohne. Selbst als ich den Bus auf 10 kHz einstellte, sah die Drohnengrafik gleich aus. Beim Nucleo liegt der I2C auf I2C1. Auf der Drohne ist es auf I2C2. Es gibt auch unterschiedliche Busgeschwindigkeiten und Uhreinstellungen. Ich denke nicht, dass das einen Unterschied machen sollte. Es sieht aus wie ein Tauziehen zwischen Hoch und Tief auf dem Rücken
"Die gelbe Linie ist scl. Die blaue Linie die Uhr." Aber "scl" ist die Uhr, also glaube ich nicht, dass Sie das meinen :-) Ich denke, Sie meinen, dass die gelbe Linie SDA und die blaue Linie SCL (die Uhr) ist - ja?
Ja, die gelbe Linie ist sda/non clock

Antworten (1)

geteilt 50/50 zwischen Hoch und Tief auf dem, was wie das Bestätigungsbit aussieht
[...]
Es sieht aus wie ein Tauziehen zwischen Hoch und Tief auf dem Ack

Richtig, und das bedeutet, dass der I 2 C-Master die SDA-Leitung nicht tatsächlich freigegeben hat, damit der I 2 C-Slave die Bestätigung ausführen kann.

Das bedeutet wiederum, dass die GPIO-Pins, die für den I 2 C-Bus auf dem I 2 C-Master verwendet werden (wahrscheinlich beide Pins, aber sicherlich SDA) falsch konfiguriert und auf ihrer Standardeinstellung „Push-Pull“ belassen und nicht umgeschaltet wurden "Open-Drain", wie es für den I 2 C-Betrieb erforderlich ist.

Das verursacht das "Tauziehen", wie Sie es beschrieben haben, oder wie glen_geek sagte: "Warum zieht die SDA-Leitung nicht bis zum Boden?" Die Antwort ist, dass SDA (und wahrscheinlich auch SCL, aber die meisten Slaves versuchen nicht, es zu fahren) immer noch angesteuert ( von einem GPIO-Pin, der immer noch als "Push-Pull" konfiguriert ist) und nicht freigegeben wird (nur mit passivem Pull-up). ) wie ein "Open-Drain" -Pin wäre.

Wenn Sie sich auf STM32CubeMX verlassen, um den Initialisierungscode zu schreiben, dann haben Sie entweder gerade einen Fehler in der von Ihnen verwendeten Version entdeckt (suchen Sie nach Updates und Errata) oder sie falsch konfiguriert (ich verwende es nicht, also kann es sein). sagen Ihnen nicht, welche Einstellung falsch sein könnte).

Beim Nucleo liegt der I2C auf I2C1. Auf der Drohne ist es auf I2C2.

Die I 2 C-Ports unterscheiden sich also zwischen den funktionierenden und nicht funktionierenden Konfigurationen. Das könnte leicht erklären, warum Ihr Problem nur bei einer Konfiguration auftritt, wenn das STM32CubeMX-Framework I2C2 nicht korrekt initialisiert (und es gab Port-Initialisierungsfehler, die nur einige Ports betreffen).

Wow, das ist extrem aufschlussreich. Vielen Dank. Ich habe ein O-Scope gekauft, nur um das zu sehen. Ich habe mich mehrere Wochen damit beschäftigt und alle möglichen netten Sachen gelernt. Als der Code von STM32CubeMX erstellt wurde, handelte es sich hauptsächlich um ein Standardprojekt für Nucleo. Das Standardprojekt von cubemx für das STM32F303cc-Board hatte i2c2 auf pf0- und pf1-Pins. Ich musste sie auf PA9 und Pa10 umstellen, um mit den Spuren zu diesen Pins zu arbeiten. Dies ist eine Drohne zwischen dem Display und der CPU.
Ich werde mir den Code noch einmal ansehen, ich erinnere mich, dass es im Grunde dasselbe war. .. In beiden als offener Abfluss gekennzeichnet. Ich werde mir das genauer ansehen und sehen, was anders ist. Ich muss akzeptieren, dass einer auf i2c1 und der andere auf i2c2 steht. Wenn ich das zum Laufen bekomme, hat der ursprüngliche Drohnencode die Peripheriebibliothek verwendet, nicht hal. Ich muss letztendlich herausfinden, wie das falsch konfiguriert wurde / mehr über gpio-Konfigurationseinstellungen erfahren
@Jeffrey - Ich bin froh, dass die Erklärung geholfen hat. :-) Es war eine gute Idee, diesen Bereich zu bekommen! Betreff: "In beiden als offener Abfluss gekennzeichnet" Also, wo immer Sie das gesehen haben, scheint zu verstehen, dass es Open-Drain verwenden sollte , aber der Scope-Trace bestätigt, dass SDA nicht wirklich auf Open-Drain eingestellt war. Der ganze Zweck von I2C mit Open-Drain-Treibern besteht darin, jedem I2C-Gerät zu ermöglichen, jedes Signal vollständig auf logisch niedrig zu ziehen - und Ihr Slave könnte dies nicht tun, um zu bestätigen. Da Sie ein Beispiel für einen "guten" I2C-Trace haben, wissen Sie, wann die "problematische" Konfiguration behoben ist, da sie mit dem "guten" Trace übereinstimmt (Ack ganz niedrig).
I2C-Problem auf dem STM32F303-Prozessor, was passiert mit SDA?
AntwortenHierDatenschutz-Bestimmungen1y, 0v