I2C-Slave-Adresse nicht bestätigt (manchmal)

Ich versuche, über I2C mit einem remote verbundenen FRAM (FM24C04 von Ramtron) zu kommunizieren. Dieser Speicher ist in eine Karte eingebettet, die jederzeit zum / vom System eingelegt und entfernt werden kann (die Kommunikation wird ordnungsgemäß beendet, bevor der Speicher entfernt wird).

Das Problem ist: Unmittelbar nach dem Einsetzen der Karte, die den FRAM enthält, wird die Adresse manchmal nicht bestätigt.

Signalmessungen

Ich habe die Signale gemessen, um zu sehen, was passiert, und es scheint, dass die Timings in beiden Fällen in Ordnung sind (funktionieren und nicht funktionieren).

Richtige I2C-Kommunikation (3 Bytes Lesen):

I2C-FRAM-Adresse nicht bestätigt (Slave-Adresse wird korrekt gesendet):

Bereits durchgeführte Maßnahmen zur Lösung dieses Problems (ohne Erfolg)

• Verzögerung hinzugefügt, nachdem die Karte mit dem eingebetteten FRAM eingelegt wurde, um sicherzustellen, dass die Stromsequenz eingehalten wird.
• I2C stoppt die Generierung nach Erkennung einer Slave-Adresse nicht quittiert

I2C-Buskonfiguration

• Ein Master (STM32F205 Mikrocontroller von ST)
• Drei Slaves (EEPROM 24AA1025 von Microchip, RTC DS1339C von Maxim IC und der Remote-FRAM FM24C04 von Ramtron
• Ein I2C-Pegelumsetzer (MAX3373E von Maxim IC) ermöglicht die Kommunikation zwischen dem Master und dem FRAM
• Busfrequenz auf 100 kHz eingestellt

EDITIERT (2013-04-17)

Zunächst einmal vielen Dank für Ihre Kommentare.

Da es viele Vorschläge gibt, finden Sie hier die Beschreibung der Untersuchungen, die ich durchgeführt habe.

Schema

Das folgende Bild zeigt ein vereinfachtes Schema des I2C-Busses:

I2C_SDA- und I2C_SCL-Signale sind direkt mit dem Mikrocontroller verbunden, und FRAM_SDA- und FRAM_SCL-Signale sind mit dem FRAM verbunden. Beachten Sie, dass die an den FRAM angeschlossenen SDA- und SCL-Signale mithilfe von BLM18-Ferriten von Murata gefiltert werden.

Der FRAM ist wie folgt angeschlossen:

• NC (Pin 1) -> nicht angeschlossen
• A1 (Pin 2) -> GND
• A2 (Pin 3) -> GND
• VSS (Pin 4) -> GND
• SDA (Pin 5) -> FRAM_SDA
• SCL (Pin 6) -> FRAM_SCL
• WP (Pin 7) -> GND (nicht schreibgeschützt)
• VDD (Pin 8) -> + 5V

Beschreibung der FRAM-Karte

Diese Karte ist eine "ISA-ähnliche" Karte, in die nur der FRAM eingebettet ist.

Untersuchungen

Die Frequenz verlangsamen

Ich habe Tests mit einer SCL-Frequenz von 50 kHz und 10 kHz durchgeführt. Ich habe das SCL-Signal mit einem Oszilloskop gemessen, um sicherzustellen, dass es die erwartete Frequenz hat.

Diese Änderungen haben das Problem nicht gelöst. Ich habe die Timings überprüft und sie liegen innerhalb der FRAM-Datenblattspezifikationen.

Sicherstellung der Stromfolge

@ Jippie.

1. Der I2C-Pegelumsetzer wird in den Drei-Status-Modus versetzt, bevor die Karte, in die der FRAM eingebettet ist, eingesetzt wird. FRAM_SDA- und FRAM_SCL-Signale werden niedrig gezogen.
2. Nach dem Einsetzen der "FRAM-Karte" wird eine Verzögerung von 100 ms hinzugefügt, um sicherzustellen, dass die Stromversorgung stabilisiert ist (mindestens 11 ms vor der ersten Startbedingung gemäß Datenblatt erforderlich).
3. Der I2C Level Shifter ist aktiviert.
4. Eine Verzögerung von 1 ms wird hinzugefügt, um sicherzustellen, dass der I2C-Pegelumsetzer aktiviert ist und die Leitungen hochgezogen werden (~ 4us gemäß Datenblatt erforderlich). FRAM_SDA- und FRAM_SCL-Signale werden abgerufen.
5. Auf den FRAM wird zugegriffen.

Nach jedem Schritt wurden die Signale FRAM_SDA und FRAM_SCL gemessen.

Das Problem tritt immer noch auf.

Stopp / Start-Bedingung statt wiederholten Start

@ gbarry.

Ich habe versucht, vor dem wiederholten Start während der Byte-Übertragung einen Stopp zu setzen. Ich habe die Byteübertragung mit dem Oszilloskop gemessen: Die STOP-Bedingung gefolgt von der START-Bedingung ist OK.

Leider löst diese Lösung das Problem nicht.

Gedanken

Dieses Problem tritt erst auf, nachdem die in den FRAM eingebettete Karte angeschlossen wurde. Ich habe einige Tausend erfolgreiche Lesezugriffe (Slave-Adressierung und Lesen) ausgeführt, nachdem die "FRAM-Karte" eingelegt und korrekt adressiert wurde.

Es klingt für mich immer mehr nach einem Hardwareproblem. Ich weiß jedoch nicht, ob dies mit dem I2C-Pegelumsetzer oder den anderen Slaves am I2C-Bus zusammenhängen könnte.

Haben Sie weitere Ideen oder Vorschläge?

EDITIERT (2013-04-18)

Das Problem scheint gelöst zu sein

Ich habe den FRAM-Modulstecker ausgetauscht und einen Weg gefunden, Messungen direkt am FRAM durchzuführen. Es scheint, dass mit diesem neuen Anschluss alles gut funktioniert.

Ich werde weitere Tests durchführen, um sicherzugehen, dass das Problem auf einen schlechten Zusammenhang zurückzuführen ist.

Obwohl Sie sagen, dass Ihre Kommunikation vor dem Einsetzen oder Entfernen ordnungsgemäß beendet wurde, kann es sich lohnen, diese Lösung auszuprobieren, da der I2C-Bus nach einem Zurücksetzen nur eines der Geräte am Bus Probleme verursachen kann.

Stellen Sie vor dem Initialisieren der Master-I2C-Hardware SDA als Eingang ein und testen Sie, ob SDA niedrig ist.

Wenn es niedrig ist, setzen Sie den SCL-Pin hoch.

Schalten Sie dann den SCL-Pin auf Low und High um, bis SDA auf High geht (dh stempeln Sie alle verbleibenden Bits aus, die Peripheriegeräte möglicherweise noch zu senden versuchen). Dies kann nicht länger als 8 Taktzyklen dauern. Wenn dies der Fall ist, liegt ein anderes Problem vor.

Ich kann nicht garantieren, dass dies Ihr Problem lösen wird, aber es hat meins gelöst!

Für den FRAM:

• Verbinden Sie zuerst GND und Vcc.
• Stellen Sie dann sicher, dass A1, A2 und WP den richtigen Pegel haben.
• Erst dann verbinden sich die Datenpins.

Das Anschließen anderer Pins als der Stromversorgung vor dem Einschalten des Chips kann zu Problemen führen.

10k scheinen für Ihre Klimmzüge etwas groß zu sein, und Ihre Vorderkanten sehen langsam aus. Reduzieren Sie die Widerstände auf ca. 3k und prüfen Sie, ob dies hilft.

Warum driftet die Ausschaltspannung mit der Zeit?

Gibt es eine Chance, dass noch etwas versucht, mit diesem Board zu sprechen? Ich hatte einmal so ein Problem; Ich könnte 60% der Zeit eine Bestätigung bekommen, aber ich kann mich nicht erinnern, jemals eine Kollision gesehen zu haben. Ich vermute, dass der mir zur Verfügung gestellte i2c irgendwie vom echten internen Bus isoliert war. Ich könnte es kontinuierlich ausführen und es würde nur 30% der Nachrichten löschen. Das Problem verschwand in dem Moment, als wir direkt mit dem Gerät (einem Netzteil) ohne die dazwischenliegende "Rückwandplatine" sprachen.

Nach Ihrem NAK-Fehler wird keine Stoppsequenz angezeigt. Ich vermute, Sie haben einen Haltepunkt, der das Programm an diesem Punkt anhält?

Wenn Sie der Meinung sind, dass Sie der einzige im Bus sind, können Sie auch versuchen, den wiederholten Start durch einen Stopp / Start zu ersetzen. Ich habe Geräte (insbesondere benutzerdefinierte FPGAs) gesehen, die nicht genau wussten, wie sie mit RS umgehen sollen.

[Antwort auf den Kommentar]: Es gibt eine Menge, die Sie nicht über die FRAM-Karte gesagt haben, zum Beispiel, ob es sich nur um Speicher oder ein ganzes Subsystem handelt. Aber wenn Sie das Zielfernrohr direkt auf die Kabel des i2c-Geräts legen können, das Ihnen Probleme bereitet, und Sie immer noch sehen, was abgebildet ist, würde ich Interferenzen ausschließen. I2C ist so einfach, dass der Chip ordnungsgemäß abgespielt werden sollte, wenn Sie die richtigen Signale am Eingang sehen, es sei denn, es liegt ein internes Problem vor.

Insbesondere möchten Sie auf die FRAM-Seite dieses Level-Shifters gelangen. Eine Unterbrechung des Signals ist wahrscheinlicher als etwas, das normalerweise als Kollision angesehen wird.

Ich werde darauf hinweisen, dass ein NAK-Zyklus nicht von einem Chip zu unterscheiden ist, der einfach nicht vorhanden ist. EEPROMs tun dies, um anzuzeigen, dass sie beschäftigt sind. Ich habe die Schreibzeit auf FRAM nachgeschlagen und sie ist schneller als ein einzelnes i2c-Datenbit ... das ist also kein Problem.

Da das Problem bei der Wiedergabe ein dauerhafter Fehler ist, der nur durch Entfernen und erneutes Einsetzen des Geräts behoben wird, ist es eines von zwei Dingen: Das Gerät befindet sich in einem fehlerhaften Zustand, von dem es sich nur beim Aus- und Einschalten erholt. oder es besteht ein schlechter Kontakt.

Wenn das Gerät in einen schlechten Zustand versetzt wird, aus dem es sich beim Aus- und Einschalten erholt, können Sie über eine zusätzliche Schaltung verfügen, über die Ihre MCU das Gerät ausschalten kann. Die Firmware kann dann, nachdem sie keine Bestätigung vom Gerät erhalten hat, einen Wiederherstellungsvorgang ausführen, bei dem sie den Chip für einige Zeit herunterfährt, ihn wieder hochfährt und es dann erneut versucht.

Wenn es sich um einen schlechten Kontakt handelt, müssen Sie möglicherweise die Zuverlässigkeit des Steckverbinders überprüfen und etwas Besseres finden. Wenn Sie denselben Anschluss verwenden, um mehr von diesen Karten herzustellen, können Probleme vor Ort auftreten. In jedem Fall kann es ein menschliches Verfahren geben, um mit der Situation umzugehen. Der Bediener, der mit dem Gerät arbeitet, muss sich des potenziellen Problems beim Einsetzen der Karte bewusst sein und muss möglicherweise neu eingesetzt werden, um ordnungsgemäß zu funktionieren.

Ihr Hauptgerät kann einen Alarm auslösen, der darauf hinweist, dass es nicht mit dem FRAM sprechen kann: eine "Fehler" -LED auf einem Bedienfeld und / oder ein Piepton oder was auch immer. Oder umgekehrt: Ein Licht, das aufleuchtet und dem Benutzer Feedback gibt, dass der FRAM akzeptiert und die Kommunikation hergestellt wurde. Wenn der FRAM weit vom Master-Gerät entfernt ist, kann sich das Licht auf dem FRAM-Modul befinden: einem weiteren I2C-Chip, der eine LED ansteuert.

Die sporadische Natur des Problems legt nahe, dass es sich um ein Timing-Problem handeln könnte.

Das Datenblatt enthält zwei Zeitreihen, eine für den "Standardmodus" und eine für den "Schnellmodus". Aus Ihren Messungen geht hervor, dass Sie sich am Rande des Timings "Standardmodus" befinden. Ich kann anhand des Datenblattes nicht erkennen, wie genau der Chip in einen der beiden Modi versetzt wird.

Ich würde nicht davon ausgehen, dass sich Ihr Gerät im Schnellmodus befindet. Können Sie die Timings um den Faktor 2-4 reduzieren, sicherstellen, dass Sie sich innerhalb der Standardmodus-Timings für Startbedingung Haltezeit, Takthochperiode und Taktunterperiode befinden und prüfen, ob dieses Problem weiterhin auftritt?

Haben Sie a 24c04a, b oder c? Wenn es ein c04a ist, war es ein robustes Design. Der Teil b ist empfindlich gegenüber Stromversorgungsrampen. Welche Entkopplung haben Sie an Pin8 zu gnd? Ich wollte etwas über Signalpegel sagen, aber ich sehe, dass Sie einen Pegelübersetzer verwenden. Vielleicht möchten Sie überprüfen, ob Sie bei SCL keinen Fehler bekommen, den der Chip als zusätzliche Uhr interpretieren würde.