Ich glaube, ich habe die Antwort gefunden. Es stellt sich heraus, dass dies ein bekanntes Problem ist, aber ich habe es erst gefunden, nachdem ich entschieden hatte, wo das Problem liegt, und danach gesucht habe!
Hier ist der Prozess, den ich durchlaufen habe, damit Sie ihm folgen können (und bei Bedarf können Sie Ihre Untersuchung anpassen, wenn Sie Ergebnisse sehen, die von meinen Annahmen abweichen). Unter dem Strich scheint es eine Inkompatibilität zwischen (zumindest einigen) MSP430-I²C-Verhalten und dem erforderlichen I²C-Verhalten des Geräts zu geben, von dem Sie vermuten, dass es der I²C-Slave ist, dem IDT ZSC31014 . Das Datenblatt für dieses Gerät ist wichtig, um dies zu verstehen. Vielen Dank, dass Sie es gefunden haben.
Die gute Nachricht ist, dass es (mindestens) 2 Problemumgehungen für dieses Problem gibt, die ich am Ende erläutern werde.
Die Darstellung wird dicker, es scheint, dass das Anschließen eines anderen Oszilloskops die Schaltung nicht richtig zum Laufen bringt, und es ist ersichtlich, dass der einzige Unterschied darin besteht, dass keine ACK übertragen wird.
Die neuen Spuren sind hilfreich, danke, obwohl ich sie etwas anders interpretiere.
(Das Unterschreiten des SCL-Signals, das mich auf der ersten Spur betroffen hat, ist auf der letzten Spur immer noch vorhanden. Es ist interessant, dass das Unterschießen auf SCL größer zu sein scheint als das Unterschießen auf SDA, insbesondere angesichts der unterschiedlichen vertikalen Skalen zwischen SCL- und SDA-Signalen auf der Ich würde immer noch vorschlagen, das SCL-Unterschießen irgendwann zu untersuchen, aber ich glaube nicht, dass es mit dem Hauptproblem zusammenhängt.)
Es gibt diese zwei "Pannen" bei SDA:
Ein Fehler kurz vor oder kurz nach dem ACK-Impuls ist nicht ungewöhnlich, wenn ein I²C-Master die Kontrolle über SDA freigibt, damit ein Slave die ACK ausführen kann, und der Master dann möglicherweise SDA erneut ansteuert. Deshalb ignoriere ich diesen.
Es ist der frühe SDA-Fehler vor dem ersten SCL-Impuls, der ungewöhnlicher ist. Aus der Amplitude dieses frühen SDA-Fehlers (siehe später) und der Tatsache, dass er nur vor diesem ersten SCL-Impuls (mit 0 bezeichnet) auftritt, jedoch nicht vor späteren SCL-Impulsen, bei denen wir einen Fehler auf SDA sehen könnten (wie SCL) Impulse mit der Bezeichnung 4, 5, 6 oder 7), wir wissen, dass es sich weder um ein Messartefakt noch um eine Kopplung von SCL handelt (zum Beispiel).
(Zur späteren Bezugnahme sieht der frühe SDA- Fehler in der letzten Kurve wie mindestens 2 V aus. Wenn also Vdd aus früheren Kommentaren bei 3,6 V liegt, beträgt die SDA-Fehleramplitude mindestens (2 / 3,6) = 0,55 x Vdd. Vergleichen Sie dies mit die relevanten I2C-Logikpegelschwellenwerte, die später erläutert werden.)
Wenn ich den ACK-Unterschied ignoriere, sehe ich in diesem zweiten Screenshot einen weiteren Unterschied zwischen den beiden Spuren. Die Amplitude dieses frühen SDA-Fehlers scheint etwas anders zu sein, wenn man die obere SDA-Spur mit der Markierung C1(gelblich?) Und die zweite mit der SDA-Spur markierte M3(blau) vergleicht. Ich glaube jetzt, dass Unterschiede in der Amplitude dieses frühen SDA-Fehlers dazu führen können, dass Ihr Problem auftritt oder verschwindet, wie ich weiter unten erläutere.
Eine noch genauere Lösung speziell für den Fehler würde helfen (dies ist eines der Probleme beim Versuch, Probleme "aus der Ferne" zu bearbeiten - ich kann das Zielfernrohr nicht selbst bedienen!). Ich gehe davon aus, dass es beim Vergrößern wie der Beginn einer normalen I²C-Logik "1" aussieht (dh einer RC-Kurve an der ansteigenden Flanke, insbesondere wenn Sie die Klimmzüge vorübergehend schwächer machen, z. B. 10k), außer dass dies nicht der Fall ist. t die volle positive Spannung erreichen, bevor sie wieder auf eine logische "0" gebracht wird. Dies wird auf einer anderen später verlinkten Webseite angezeigt. Wenn Sie eine andere Form als Ihre Panne sehen, trifft meine spätere Analyse möglicherweise nicht zu.
Der I²C-Master steuert den Bus an der Stelle dieses Fehlers zwischen dem I²C-Start und dem ersten SCL-Takt (den Sie mit "0" bezeichnet haben, obwohl es sich um das MSbit handelt). Das machte mich misstrauisch gegenüber dem MSP430-Verhalten, obwohl bei einem zu diesem Zeitpunkt niedrigen SCL-Wert ein SDA-Fehler keine Auswirkungen auf I²C-kompatible Geräte haben sollte, da diese darauf warten, dass der SCL-Wert hoch wird, bevor sie den Status von SDA das nächste Mal lesen.
Ist dieser I²C-Slave wirklich I²C-konform? Es stellt sich heraus, dass der ZSC31014 " pingelig " und weniger tolerant ist als einige andere I²C-Geräte, genau zu dem Zeitpunkt, an dem ich glaube, dass der MSP430 diesen Fehler verursacht!
Das Datenblatt ZSC31014 listet drei Bereiche auf, in denen das I²C-Verhalten des Geräts "unterschiedlich" ist. Sie könnten auch zu anderen Zeiten von den ersten beiden in dieser Liste betroffen sein (das ist nicht Teil dieser Analyse), aber es ist der dritte Punkt, den ich unten rot markiert habe, der mit diesem frühen SDA-Fehler zusammenhängt:
Die Amplitude dieses frühen SDA-Fehlers ist kritisch . Wenn dieser Fehler nicht genug ansteigt, um vom ZSC31014 als logische "1" erkannt zu werden, bevor er wieder abfällt, sind Sie in Ordnung - das Gerät muss eine fallende Flanke auf SDA sehen, um diese "Regel" zu brechen, und dies kann nur sein eine fallende Flanke, wenn sie bereits als logische "1" erkannt wurde.
Alles, was die Amplitude dieses SDA-Fehlers beeinflusst, wie die zusätzliche Belastung des SDA-Signals durch ein Oszilloskop oder einen Logikanalysator, kann ausreichen, um zu verhindern, dass der Fehler vom ZSC31014 als logisch "1" erkannt wird und daher nicht "abfällt" SDA-Kante ", dieser dritte Punkt in der Liste, kann auftreten (an einem guten Tag, abhängig von Spannungen, Temperaturen usw.). Wie Sie jedoch festgestellt haben, reicht die Variation zwischen verschiedenen Oszilloskopen aus, um zu bedeuten, dass einige von ihnen genügend Last hinzufügen, um das Problem zu stoppen, andere nicht. Dieses Setup muss sehr marginal sein!
Dies bestätigt meine Sorge, dass Ihre früheren "funktionierenden" Sensorstapel möglicherweise "nur" funktionieren, da die MSP430-MCUs in diesen "funktionierenden" Setups wahrscheinlich auch SDA-Störungen verursachen. Als nächstes wird meine Theorie über einen möglichen Unterschied zwischen Chargen von Sensoren erläutert, der das unterschiedliche Verhalten erklären könnte, das Sie gemeldet haben ("arbeitende" Charge vs. "nicht arbeitende" Charge).
Interessanterweise unterscheidet sich der ZSC31014 von Standard-I²C in einem anderen Bereich, der in dieser Liste vom Hersteller nicht erwähnt wird, und dies könnte erklären, warum Sie einen Unterschied zwischen Chargen von Sensoren zu sehen scheinen.
Standard-I²C-Logikschwellenwerte sind (vereinfacht) - unter 0,3 x Vdd für logische "0" und über 0,7 x Vdd für logische "1", wie in der I²C-Spezifikation gezeigt :
Der ZSC31014 hat jedoch unterschiedliche Schwellenwerte, 0,2 x Vdd und 0,8 x Vdd, was bedeutet, dass sein "undefinierter Bereich" zwischen diesen Schwellenwerten größer ist als bei typischen I²C-Geräten:
Die größere „undefined Region“ erhöht die Chance auf dem Glitch den undefinierten Spannungspegels Bereich betreten, wo es vielleicht als logisches erkannt werden „1“ (denken Sie daran, etwas über 0,2 x Vdd konnte durch die ZSC31014 als Logik erkannt werden „1“ , da im undefinierten Bereich alles erlaubt ist - es liegt nur über 0,8 x Vdd, wenn es als logische "1" erkannt werden muss ). Und wie bereits erläutert, haben Sie, wenn der ZSC31014 erkennt, dass der Fehler eine logische "1" erreicht hat, diese rot markierte "Regel" für das erforderliche I²C-Verhalten gebrochen, wenn sie wieder auf eine logische "0" fällt von der ZSC31014.
Da die Erkennung von Logikpegeln in diesem "undefinierten" Spannungsbereich nicht spezifiziert ist, bricht der Sensorhersteller die Spezifikation nicht, wenn er eine Charge erstellt, die die logische "1" nur erkennt, wenn sie 0,7 x Vdd erreicht, sondern eine andere Charge, die erkennt eine logische "1" von beispielsweise 0,4 x Vdd. Bei dieser hypothetischen zweiten Charge würde der SDA-Fehler eher als fallende SDA-Kante angesehen, was gegen diesen dritten Punkt in ihrer Liste verstößt, jedoch nicht gegen ihre Spezifikation verstößt.
(Viele der Probleme, an denen ich im Laufe der Jahre gearbeitet habe, waren wie folgt: Es gibt zwei Geräte, von denen keines einzeln eine Spezifikation mit Lücken bricht - aber eines ist pingelig und weniger tolerant, an einem Punkt, an dem die andere angeschlossene Geräte sein muss mehr wegen tolerant seiner obskuren Verhalten! Jede dieser beiden Geräte ist in Ordnung mit den meisten anderen Geräten eine Schnittstelle, sind aber unzuverlässig (oder komplett ausfallen) , wenn sie miteinander verbunden sind .)
Also, was kannst du machen? Ich dachte an zwei Möglichkeiten:
Verwenden Sie keinen MSP430 - verwenden Sie eine andere MCU, die diesen frühen SDA-Fehler nicht verursacht. Ich gehe jedoch davon aus, dass Sie viel Zeit in die Software investiert haben und den Code nicht auf eine andere MCU portieren möchten, wenn dies vermieden werden könnte.
"Bit-Bang" des I²C-Protokolls auf dem MSP430, anstatt das integrierte I²C-Hardwaremodul zu verwenden. Auf diese Weise haben Sie die vollständige Kontrolle über die I²C-Signale und können das Auftreten dieses Fehlers verhindern. Es wäre jedoch offensichtlich mühsam, eigene I²C-Routinen zu erstellen, diese zu debuggen, und der resultierende Code ist möglicherweise größer als bei Verwendung des MSP430 I²C-Hardwaremoduls. Dies kann selbst ein Problem sein, wenn Sie nicht über genügend Flash-Speicher verfügen.
Dann habe ich nach MSP430 I²C-Problemen gesucht und festgestellt, dass diese Kombination von MSP430 + ZSC31014 aufgrund des frühen SDA-Fehlers des MSP430 ein bekanntes Problem ist! Siehe diesen Thread im TI E2E MSP430-Forum:
TI E2E-Forum: MSP430 I2C-Störimpulse verursachen Probleme für den I2C-Peripherie-Chip
Die dort erwähnte Problemumgehung besteht darin, die I²C-Adresse des ZSC31014 so zu ändern, dass der SDA zu dem Zeitpunkt hoch ist, zu dem der positive Fehler auftreten könnte , und da der SDA dann ohnehin hoch ist, gibt es keinen tatsächlichen Fehler auf dem SDA:
Unsere Problemumgehung besteht darin, den ZSC-Chip so zu konfigurieren, dass eine Adresse mit gesetztem Bit 6 vorhanden ist (z. B. verwenden wir jetzt 0x42). Dadurch wird der Glitch-Impuls für die Dauer des Adressbits 6 in ein schönes sauberes "High" -Bit umgewandelt, das entfernt wird der problematischen Fallflanke.
Die gleiche Problemumgehung ist praktisch die Umkehrung des Vorschlags im Datenblatt ZSC31014 in dem von mir markierten roten Feld. Sie sagen, dass ein SDA-Fehler verhindert werden muss, wenn das erste Bit (das MSbit) der ZSC31014-I²C-Adresse 0 ist. Machen Sie das MSbit der I²C-Adresse also nicht zu einer "0", sondern zu einer "1" Setzen Sie Bit 6 in die 7-Bit-I²C-Adresse!
Da sich dieser TI E2E-Forenthread und das Datenblatt ZSC31014 beide auf die I²C-Adresse konzentrieren, tritt möglicherweise entweder der SDA-Fehler beim Senden anderer Daten auf dem Bus nicht auf oder ist kein Problem, wenn er auftritt. Sie müssen das untersuchen.
Wenn Sie also die erste Problemumgehung bei Verwendung einer anderen MCU ignorieren, sind die beiden (praktischeren) Problemumgehungen entweder:
- Bit-Bang den MSP430 I²C-Bus, indem Sie Ihren eigenen Code schreiben, damit Sie diesen Fehler nicht auf SDA oder erstellen
- Ändern Sie die I²C-Adresse des ZSC31014 so, dass Bit 6 seiner 7-Bit-Adresse gesetzt ist. Dies bedeutet, dass der SDA bereits hoch ist, wenn der Fehler andernfalls auftreten würde. Daher tritt auf dem SDA kein tatsächlicher Fehler auf, wenn der ZSC31014 angesprochen wird (vorausgesetzt, es handelt sich auch um einen SDA-Fehler tritt nicht nach anderen I²C-Startereignissen während der Datenübertragung auf oder wenn eines auftritt, wird der ZSC31014 nicht "verärgert").
Ich hoffe, das hilft!
