I2C-Slave bestätigt nicht konsistent

Ich versuche, mit einem CapSense-Modul von Cypress, Modell CY8CMBR3106S, zu kommunizieren. Während der ersten Tests habe ich die USB-I2C-Bridge CY3240-I2USB von Cypress verwendet, die perfekt funktioniert. Ich wechselte dann zu einem Arduino für das Prototyping meiner eigenen Anwendung. Ich kann den Arduino jedoch nicht dazu bringen, zuverlässig mit dem CapSense-Controller zu kommunizieren. Mit der hier zu findenden I2C-Scanner-Skizze entdeckt der Arduino den CapSense-Controller vielleicht einmal von etwa 40 Versuchen.

Bei einem Versuch, dies zu debuggen, habe ich den Bus sowohl mit der Cypress USB-I2C-Brücke als auch mit dem Arduino untersucht. Ich habe festgestellt, dass der Controller mit der Cypress-Bridge immer ein ACK gibt und mit dem Arduino fast nie ein ACK generiert. Abgesehen von den unterschiedlichen Spannungen und Taktraten (mit denen ich vergeblich herumgespielt habe) kann ich jedoch keine größeren Unterschiede zwischen den von den beiden verschiedenen Quellen gesendeten Frames feststellen, die die inkonsistenten ACKs erklären würden.

An diesem Punkt bin ich etwas ratlos - für jeden Rat wäre ich sehr dankbar. Danke!

Hier sind ein paar Scope-Aufnahmen – beachten Sie, dass die Kanäle 1 und 2 SCL bzw. SDA sind.

Erfolgreiche Kommunikation über Cypress-Bridge (Beachten Sie ACK nach dem 8. Takt)Geben Sie hier die Bildbeschreibung ein

Fehlgeschlagene Kommunikation mit Arduino (beachten Sie das Fehlen von ACK)Geben Sie hier die Bildbeschreibung ein

Sehr seltene erfolgreiche Kommunikation mit ArduinoGeben Sie hier die Bildbeschreibung ein

Den Spuren nach zu urteilen, hat die Cypress I2C-Brücke steifere Pull-Up-Widerstände am I2C-Bus.
Mit welcher Spannung läuft der Sensor? Das Datenblatt besagt, dass die maximale Spannung an einem IO-Pin Vdd + 0,5 beträgt. Im ersten Trace erfolgt die Kommunikation bei 3,3 V, im zweiten Fall bei 5 V. Ist das in der Spezifikation?
Tom – ich glaube nicht, dass es an der Frequenz oder Spannung liegt; Ich habe einen 3,3-V-Arduino und höhere I2C-Taktraten ohne Änderung ausprobiert. Nick, die Zypressenbrücke hat 7,5K Klimmzüge und der Arduino ist derzeit mit 10Ks eingerichtet. Ich kann versuchen, sie für 7,5 Ks auszutauschen und zu sehen, ob das einen Unterschied macht.
Tom – bei der ersten Aufnahme mit der Cypress-Brücke liegen VDD und Kommunikation beide bei 3,3 V. Bei den letzteren Aufnahmen mit dem Arduino liegen VDD und Kommunikation beide bei 5 V (obwohl ich, wie oben erwähnt, auch einen 3,3-V-Arduino ausprobiert habe).
Ich ging weiter und probierte den Arduino mit 6,8K-Klimmzügen und einer höheren Taktrate aus - keine Würfel.
Wie Sie der Aufnahme entnehmen können, scheint das Ändern der Klimmzüge die Anstiegs- / Abfalleigenschaften nicht sehr beeinflusst zu haben.
Ich sehe nichts falsch mit dem Signal. Funktioniert der Chip noch zuverlässig mit dem USB zu I2C Adapter?
Ja, ich habe es gerade noch einmal mit der Bridge versucht und es funktioniert immer noch gut.
Nun, das Problem scheint gelöst zu sein, obwohl ich mir nicht sicher bin, warum ... Ich hatte zuvor eine Verzögerung von 5 Sekunden zwischen den Kommunikationsversuchen. Das Reduzieren dieser Verzögerung auf weniger als etwa 400 ms scheint das Problem zu beheben – der erste Frame schlägt fehl, aber alle nachfolgenden Frames werden mit einem ACK beantwortet. Das Einstellen der Verzögerung auf etwa 500 ms oder mehr bringt das Problem zurück. Dies erklärt das Problem, da die Bridge-Testsoftware von Cypress kontinuierlich Frames mit hoher Frequenz sendet. Ich bin mir jedoch nicht sicher, warum der CapSense-Controller empfindlich auf die Interframe-Verzögerung reagieren würde ... eine Art Eigenart mit der I2C-HW?
Soweit ich Seite 26 des Datenblatts entnehmen kann, müssen mindestens 1,3 Mikrosekunden busfreie Zeit zwischen Frames liegen, aber es sollte keine "maximale" Menge an busfreier Zeit geben.
Siehe Seite 32, Punkt 3, dort wird eine maximale Verzögerung von 340 ms erwähnt. Relevant?
Roger – toller Fang. Ich denke, das Problem ergibt sich sowohl daraus als auch aus Punkt 2 auf derselben Seite: Das Gerät gibt ein NACK für die erste I2C-Transaktion aus, nachdem es in den aktiven Zustand versetzt wurde. Da meine Transaktionen weiter voneinander entfernt waren als das Timeout vom aktiven Zustand zum Low-Power-Zustand, war jede Transaktion die erste Transaktion im aktiven Zustand, was bedeutet, dass ich nie ein ACK sehen würde. Dies erklärt auch, warum der erste Frame immer noch fehlschlägt, wie ich oben erwähnt habe. Danke für die Hilfe, alle!
Weiß aus Neugier auch jemand, was diese kleine "Kerbe" verursacht, die unmittelbar vor dem Start des Frames ständig auf der SCL-Leitung erscheint?
Induktionsspannung von der SDA-Leitung?
Ja, sieht nach kapazitiver Kopplung aus
Ich weiß, dass Sie das Problem gelöst haben, aber wenn Sie die Möglichkeit haben, sollten Sie der Vollständigkeit halber Ihre eigene detaillierte Antwort posten und akzeptieren.

Antworten (1)

Wie in den obigen Kommentaren besprochen, bestand die Lösung in diesem Fall darin, die Frequenz der I2C-Übertragungen zu erhöhen.

Laut Datenblatt gibt der CapSense-Controller von Cypress bei der ersten I2C-Transaktion nach dem Aufwachen in den aktiven Zustand ein NACK aus. Wie @Roger Rowland feststellte, wechselt der Controller nach etwa 340 ms Inaktivität auf dem Bus in einen Energiesparzustand. Da meine Übertragungen weiter voneinander entfernt waren als dieses Timeout, würde jede Übertragung das Gerät aus dem Niedrigleistungszustand in den aktiven Zustand wecken und ein NACK erhalten. Dieses Problem wird gelöst, indem die Häufigkeit der Übertragungen auf weniger als den Timeout-Wert erhöht wird oder indem eine gegebene Übertragung Rücken an Rücken wiederholt wird, bis eine ACK empfangen wird.

I2C-Slave bestätigt nicht konsistent
AntwortenHierDatenschutz-Bestimmungen1y, 0v