Ich versuche, die Kommunikation zwischen einem msp430fr5847 (Master) und einem Slave-Sensor mit unbekanntem I2C-Chip (Teil eines Industriesensors) zu beheben.
Ich habe Probleme mit einer neuen Reihe von Sensoren, bei denen meine Daten mit allen Nullen zurückgegeben werden. Wenn ich jedoch versuche, Fehler mit meinem Saleae Logic Pro (2Mohm, 10pf) oder meinem Oszilloskop (10Mohm, 50pf) zu beheben, funktioniert das System beim Prüfen einwandfrei der SDA-Pin.
Bei der weiteren Fehlerbehebung funktioniert die Schaltung ordnungsgemäß, wenn ich einen 1-Ohm-Widerstand zwischen SDA und Masse hinzufüge, aber nicht, wenn nur ein 10pf- oder 100pf-Kondensator hinzugefügt wird.
Ich verwende 4,7k Pull-up-Widerstände für meine 3,3V-Schiene.
Was könnte dieses Problem verursachen und was kann zur Fehlerbehebung getan werden, ohne das Problem unbeabsichtigt zu beheben?
EDIT: 19/07/2017 Hier ist eine kurze Übersicht über meine Signale.
Etwas anderes, das ich vergessen habe zu erwähnen, ist, dass nur das Prüfen von SDA dazu führt, dass die Karte funktioniert, das Prüfen von SCL oder meiner Interrupt-Leitung es nicht richtig zum Laufen bringt.
EDIT: 21/07/2017
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.
In der obigen Abbildung sind die blauen und grünen Spuren SCL und SDA, wenn die Schaltung nicht richtig funktioniert. Die gelben und rosa Spuren stammen von dem Zeitpunkt, an dem ich meine Saleae-Logik auch an den SDA-Pin und die Erdung anschließe, ohne jedoch USB anzuschließen (um Erdungsschleifen zu vermeiden).
Um dem Sensor etwas mehr Hintergrundwissen zu verleihen, handelt es sich um einen industriellen Drucksensor, den wir vom Hersteller kaufen. Wir haben diese Leiterplatten zuvor mit unserer ersten Charge von Sensoren entworfen und getestet. Wir haben kürzlich eine neue Charge erhalten und stoßen nun auf diese Probleme. Ich habe einige Nachforschungen angestellt und vermute stark (nachdem ich einzigartig aussehende Sätze aus dem Datenblatt gegoogelt habe), dass der Sensor intern HIER ein ZSC31014 oder ähnliches PDF-Datenblatt verwendet
EDIT: 26/07/2017
Hoffentlich die letzte Rate bei der Lösung dieses Problems. Gemäß der detaillierten Antwort von SamGibson habe ich den Fix implementiert, das hohe Bit der Adresse zu setzen, um die Störung am Ende des Startbits zu maskieren.
Dies hat hauptsächlich mit Daten funktioniert, die wie erwartet eingehen. Jetzt scheint es jedoch so zu sein, dass der Slave im ersten Lesebefehl nach einem Schreibvorgang (wenn dies der richtige Begriff für eine Gruppe von i2c-Bits ist) versucht, ein Bit früher (in) zu bestätigen die Position des Schreibbits). Ich kann sagen, dass es der Slave ist, der die Leitung nach unten zieht, indem er einen kleinen Widerstand (47 Ohm) in Reihe mit der SDA-Leitung hinzufügt.
Normalerweise beginne ich dies als neue Frage, aber wenn ich denselben Bereich anhänge, der bei der obigen Fehlerbehebung keine Auswirkungen hatte, scheint dieses Problem zu verschwinden. Dies scheint wirklich ein Grenzproblem zu sein, selbst wenn ich den Bereichssonden anbringe. Ohne es mit dem Bereich zu verbinden, ist das Problem gelöst, daher gehe ich davon aus, dass es sich um ein Kapazitätsproblem handelt.
Problemplot ohne Umfang
Problemdiagramm mit angeschlossener, aber nicht am Oszilloskop angeschlossener Oszilloskop-Sonde, wobei die etwas höhere Spannung festgestellt wird, wenn der Slave das Schreibbit anstelle des ACK-Bits herunterzieht.
quelle
Antworten:
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 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 markierteM3(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:
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:
Ich hoffe, das hilft!
quelle