EEPROM I2C-Treiber hängt während ESD-Test?

Obwohl wir wirklich nicht wissen können, was Ihr Auflegen verursacht, gibt es ein wahrscheinliches Szenario, in dem Sie wahrscheinlich zuerst nachsehen sollten.

Ein ESD-Impuls verursacht wahrscheinlich einen unbeabsichtigten Ein-Übergang bei digitalen Signalen. Wenn in einem I2C-System ESD dazu führt, dass ein Impuls auf SDA erscheint, wenn der Bus im Leerlauf ist, wird dies als Startbedingung interpretiert. Je nachdem, wie die uC- und peripheren I2C-Controller implementiert sind, können sie unbegrenzt auf den Abschluss der gestarteten Transaktion warten, bevor sie bereit sind, eine neue Transaktion auszuführen (z. B. eine von Ihrem Code generierte).

Natürlich könnte ein zusätzlicher Impuls auf SCL oder SDA, wenn eine I2C-Transaktion im Gange ist (möglicherweise nur von einem der beiden beteiligten Chips erkannt), dazu führen, dass die beiden Chips den Status der Transaktion verlieren und Probleme verursachen.

Wenn Sie also suchen, wo Ihre Hardware verbessert werden könnte, um diesen Fehler zu vermeiden, stellen Sie sicher, dass Ihre SDA- und SCL-Leitungen über ununterbrochene Masseebenen geführt werden, vermeiden Sie übermäßige Routing-Abstände und reduzieren Sie möglicherweise die Pull-up-Widerstandswerte. Stellen Sie außerdem sicher, dass der uC und das Peripheriegerät über ausreichende Bypass-Kondensatoren verfügen.

Wenn Sie nach Softwareumgehungen für diesen Fehler suchen und den hängengebliebenen Zustand erkennen können, können Sie versuchen, den I2C-Block des uC zurückzusetzen oder SCL-Impulse (8 oder 10 oder 16?) zu senden, wobei SDA hoch freigegeben wird, um den I2C zu löschen Zustandsmaschine in der Peripherie. Dies erfordert möglicherweise das Zurücksetzen der uC-I/Os auf GPIOs und Bit-Banging, wenn der uC-I2C-Block ebenfalls hängen bleibt.

Es hört sich so an, als würden Ihre Testbedingungen dazu führen, dass der I2C-Treibercode oder das I2C-Modul selbst in einen Zustand eintritt, aus dem sie sich nicht erholen können.

Versuchen Sie, eine Zeitüberschreitung für die Schleifen festzulegen, um einen Fehler zu erkennen. Wenn ein Fehler auftritt, setzen Sie sowohl die I2C-Hardware als auch die Treiber zurück.

Das einfachste zu implementierende Timeout wäre, zu zählen, wie oft Sie die verschiedenen Flags getestet haben, und wenn diese Zählung abläuft, mit einem Fehlercode zu beenden.

Ein komplizierterer (dh nützlicherer) Ansatz wäre die Überwachung eines Hardware-Timers, der im Hintergrund läuft. Wenn eine Schleife beginnt, zeichnen Sie den aktuellen Wert des Timers plus das gewünschte Timeout auf; Überprüfen Sie den Timer zu Beginn jeder Schleife und wenn er Ihren vorberechneten Wert überschreitet, beenden Sie ihn mit einem Fehlercode.

Was könnte mit dem Controller (MSP430F6438 I2c-Bus) oder dem Slave (I2c-basiertes EEPROM) schief gehen, was dazu führt, dass der Code in einer der Schleifen hängt, die auf Bus-Bus, Sende-Flag, Bestätigungs-Empfangs-Flag prüft?

Es ist schwer zu sagen, was dazu führt, dass Ihr System hängt. Aber Sie können etwas tun, um herauszufinden, wo Ihr Code hängt. Wenn möglich, können Sie über USART oder eine andere Schnittstelle eine Debug-Meldung auf dem Bildschirm oder Ihrem PC ausdrucken. Sie können Ihrem Code eine "Sonde" hinzufügen, wenn Sie eine Funktion eingeben oder eine Schleife eingeben, drucken Sie eine Nachricht auf Ihren PC, dann können Sie wissen, wo Ihr Code hängt.

Es ist jedoch eine gute Angewohnheit, ein Timeout zu einer Schleife hinzuzufügen, die möglicherweise "tot" ist.

Sortieren Sie den flockigen Code aus. Wenn der Code aufgrund eines unvorhergesehenen Umstands hängt, ändern Sie den Code so, dass der unvorhergesehene Umstand berücksichtigt wird. Versuchen Sie als letzten Ausweg einen Hardware-Watchdog-Timer - obwohl dies nur funktioniert (keine Codeänderung), wenn einige externe Leitungen decodiert werden können, die auf das Problem hinweisen. Sie könnten auch einen EMI-Schutz / Filterung der internen Verkabelung in Betracht ziehen und vielleicht sogar einen Blick auf die Masseebene um das Mikro und das EEPROM werfen.