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

11

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): Geben Sie hier die Bildbeschreibung ein

I2C-FRAM-Adresse nicht bestätigt (Slave-Adresse wird korrekt gesendet): Geben Sie hier die Bildbeschreibung ein

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-Busschema

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.

johsey
quelle
Können Sie bitte den Schaltplan posten? Versuchen Sie eine langsamere Busfrequenz, um festzustellen, ob dies einen Unterschied macht.
Suirnder
Ist das Problem erst kurz nach dem Einfügen aufgetreten und nicht zu anderen Zeiten? Wie schnell ist "kurz danach"?
Kaz
Zusätzlich zu den anderen Experimenten können Sie versuchen, die anderen Slaves zu entfernen und festzustellen, ob sich dies auf das Verhalten auswirkt.
Ben Gartner
Sind die beiden Adresspins richtig nach unten gezogen oder schweben sie?
fm_andreas
@Suirnder Ich habe den Schaltplan in meiner Antwort gepostet.
Johsey

Antworten:

6

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!

Buzby
quelle
Es ist keine schlechte Idee, diesen "Bus-Wiederherstellungsalgorithmus" hinzuzufügen, bevor der Master initialisiert wird. Ich werde es implementieren. Vielen Dank.
Johsey
2

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.

Jippie
quelle
2

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?

Scott Seidman
quelle
Ich habe die Pull-up-Widerstände auf 3,3k reduziert und das hilft nicht. Ich habe keine Ahnung von diesem Driften.
Johsey
Auf dem Bildschirm sieht es klein aus, aber es sind ungefähr 250 mV, denke ich. Möglicherweise haben Sie ein Problem mit der Stromversorgung auf der 3,3-V-Seite
Scott Seidman,
Sie haben Recht, die Drift beträgt auf beiden Seiten des I2C-Pegelschiebers etwa 300 mV. Das + 3,3-V-Netzteil scheint einwandfrei zu funktionieren (keine Drift in seinem Ausgang, wenn die Drift des SCL-Signals auftritt). Könnte es mit dem I2C Level Shifter zusammenhängen?
Johsey
Ich bin mir überhaupt nicht sicher. Woher kommen 3,3 V? Konverter schalten? Auf jeden Fall ist es verdächtig. Ziehen Sie einen Mindeststrom, der von dem Gerät benötigt wird, das 3,3 V pro Datenblatt liefert? Wenn nicht, laden Sie Ihre Versorgung mit einem Widerstand. Was passiert, wenn Sie ein oder zwei Sekunden warten, bevor Sie mit der Kommunikation beginnen?
Scott Seidman
3,3 V kommen von einem SMPS (LM3103MH von TI). Ich bin kein Experte für Netzteile, aber wie ich verstanden habe, ist bei diesem Gerät kein Mindeststrom erforderlich, da es bei geringer Last im diskontinuierlichen Leitungsmodus betrieben werden kann. Das gleiche Problem tritt auf, wenn ich zwei Sekunden warte, bevor ich mit der Kommunikation beginne.
Johsey
2

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.

gbarry
quelle
Es gibt nur einen Master am I2C-Bus und die Karte, in die der FRAM eingebettet ist, ist nur mit diesem Bus verbunden. Daher denke ich, dass es keine Chance gibt, dass etwas anderes versucht, mit ihm zu sprechen. Ja, ich habe vor der Stoppsequenz einen Haltepunkt gesetzt. Ich werde versuchen, diesen wiederholten Start durch einen Stopp / Start zu ersetzen, wie Sie vorschlagen, und werde ihn erneut testen. Laut Datenblatt sollte der FRAM einen wiederholten Start unterstützen. Denken Sie, dass dies das Problem möglicherweise lösen könnte, wenn ich den FRAM isoliere (z. B. auf einem dedizierten I2C-Bus)?
Johsey
Die FRAM-Karte bettet nur den FRAM ein. Es ist ein "ISA-ähnliches" Board. Es ist schwierig, die Signale direkt an den FRAM-Pins zu messen, da diese Karte in ein Kunststoffteil eingebettet ist. Wie auch immer, ich werde versuchen, einen Weg zu finden, um diese Signale so nah wie möglich am FRAM zu messen.
Johsey
Es wäre ein großer Schritt, auf die FRAM-Seite von U13 zu gelangen.
Gbarry
2

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.

Kaz
quelle
0

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?

Ben Gartner
quelle
Mein Gerät befindet sich im "Standardmodus" (SCL-Frequenz von 100 kHz). In der Tat liegt diese Frequenz an der Grenze dieses Modus. Ich werde versuchen, es um den Faktor zwei zu reduzieren und einige Tests durchzuführen.
Johsey
0

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.

gman
quelle
3
Haben Sie dies auf einem alten Mobiltelefon mit nur neun Tasten eingegeben?
Angelatlarge
Der verwendete FRAM ist der FM24C04B . Woher haben Sie diese Informationen über die Leistungsempfindlichkeit dieses Gedächtnisses? Kannst du mir mehr Inputs geben? Es gibt keine Entkopplung an Pin 8. Das Design dieses Moduls wurde vor einigen Jahren durchgeführt und wir müssen die gesamte Produktion verbrauchen. Nach den mit dem Oszilloskop durchgeführten Messungen scheint es keinen Fehler in der SCL-Leitung zu geben, wenn das FRAM-Modul angeschlossen und der Pegelumsetzer aktiviert ist.
Johsey
1
Mir ist klar, dass diese Antwort sehr spät ist, aber meine Informationen zur Vcc-Empfindlichkeit stammen aus der Unterstützung von Apps für Ramtron vor Jahren. Ich erinnere mich nicht an die genauen Details, aber unter bestimmten Rampenraten und Temperaturen blockiert der Chip im Wesentlichen und erlaubt keine I2C-Kommunikation, bis Sie mit einer "guten" Rampe hochfahren. Es ist nicht gut, keine Entkopplungskappe in der Nähe des Chips zu haben. Sie können feststellen, dass die Verwendung der Entkopplung von 0,1 uF gegenüber 10 uF die Vcc-Rampe dort ändert, wo eine funktioniert und die andere nicht. @angelatlarge, ja, tut mir leid, ich habe meine erste Antwort von einem Telefon aus eingegeben.
Gman