Warum wird mein I2C-Schreibvorgang NAK'd?

Ich versuche, eine Schnittstelle zu einem vorhandenen Gerät herzustellen, für das ich keine Dokumentation habe. Das Gerät stellt eine 5-V-I 2 C-Schnittstelle mit mehreren ICs auf dem Bus bereit. Ich habe einen Logikanalysator verwendet, um den Datenverkehr zu erfassen, und verstehe nicht, warum meine Schreibvorgänge nicht akzeptiert werden.

Arbeitssystem:

Unknown microcontroller  ==| connector |==+== PIC 12F509 with internal oscillator
                                          |== 24C16WI 2k EEPROM
                                          \== Logic analyzer

Die erste Kommunikation mit dem Gerät besteht darin, eine Schreibanforderung an die Adresse 0x49 zu senden, aber wenn ich versuche, dasselbe zu tun, erhalte ich keine Antwort. Es gibt offensichtliche zeitliche Unterschiede zwischen meiner und ihrer Anfrage, aber ich bin mir nicht sicher, ob sie signifikant sind. Die Kommunikation mit dem 24C16WI ist erfolgreich, aber ich bekomme keine Antwort vom PIC.

Arbeitsanforderung (Baudrate 36 kHz) ( Saleae-Erfassung ):I2C-Kommunikation vom Arbeitssystem

Meine Anfrage (Baudrate 31kHz) ( Saleae Capture ):Meine Anfrage

Unter der Annahme, dass die Differenz nicht auf einem anderen Signal als den I 2 C-Leitungen beruht, sind die Zeitdifferenzen in dem Signal signifikant? Wenn sie signifikant sind, wie kann ich das erforderliche Timing mit einem Atmel SAMD21J18 generieren?

Was vermisse ich?

Schließen Sie als schnelle Überprüfung ein Oszilloskop an die Logikleitungen an und stellen Sie sicher, dass die Pegel korrekt sind (oder stellen Sie die Saleae in den analogen Modus, wenn Sie einen haben, der dies kann). Ich wurde von einem Logikanalysator gebissen, der Übergänge zeigt, die nicht die erforderlichen Spezifikationen erfüllen.
Master (CLK-Anbieter) ist einfach, aber Slave nicht! 36 khz erforderlich 1 MHz Teiler zum Nachverfolgen, was ist passiert?
In der funktionierenden Aufnahme ist das Timing der Flanken schrecklich, aber das könnte ein Problem mit dem Bus sein. Dies erfordert wirklich eine Oszilloskop-Spur.
Du bumst einen I2C-Slave in PIC12F509? Vielleicht sollten Sie sich den Code ansehen. Haben Sie eine I2C-zugelassene Bus-Clearing-SCL/SDA-Sequenz ausprobiert? Könnte auch ein Power-Up Hang sein.
Ich werde mir in Kürze ein Oszilloskop anschließen lassen. @glen_geek, ich habe das Datenblatt des Slave-Geräts (PIC12F509) durchgelesen, aber keine Hardware-I2C-Implementierung gesehen. Ich kann nur vermuten, dass sie Bit-Banging sind. Ich habe nicht versucht, den Code zu entleeren, aber ich vermute, dass sie die Sicherung zum Schutz des Codes haben. Der PIC12F509 ist Teil eines Drittanbietergeräts, daher habe ich keinen Zugriff auf den ursprünglichen Quellcode.
@dsgdfg, ich verstehe nicht. Ich fungiere als Busmaster für den PIC12F509 des Drittanbietergeräts. Die gemessenen Frequenzen werden nur durch Messen der SCL-Periode auf dem Logikanalysator ermittelt.
Sie sind I2C'ing ein bisschen schneller als die erfolgreiche Transaktion - vielleicht kann der Bit-Bang 12F509 I2C-Code nicht mithalten. Haben Sie eine Transaktion etwas langsamer versucht?
@glen_geek, meine SCL wechselt langsamer als die Arbeitstransaktion. Ich stelle fest, dass es eine längere Verzögerung in der Startsequenz gibt, aber ich bin mir nicht sicher, wie ich das mit dem Atmel ASF I2C-Treiber erzeugen soll.
@mbrig, Low ist 0 V, High ist 3,36 V, 3,7 Vdd. Kein offensichtliches Rauschen während konstanter Perioden, 600 ns Anstiegszeit, 120 ns Abfallzeit, Klingeln beträgt ~1 Vpp für 100 ns.
Slave sind nicht einfach gemein, benötigen 2 Flanken (Anstieg, Abfall) Detektor und internen Timer für empfangene korrekte Daten. Wir sprechen von Edge-basierter Kommunikation, können also keine Daten verarbeiten, wenn die Edge-Erkennung lange dauert. Führen Sie alle meine Kommentare zusammen und überprüfen Sie dies

Antworten (2)

Zusammenfassung: Ich vermute, dass das neue I 2 C-Timing nicht nah genug am Original ist und mindestens eine „anormale“ I 2 C-Sequenz auf der „Arbeitsspur“ angezeigt wird, die für Sie möglicherweise schwer zu reproduzieren ist.

Einzelheiten:

Angenommen, der Unterschied beruht nicht auf einem anderen Signal als den I 2 C-Leitungen [...]
Was übersehe ich?

Die Aufnahmen des Logikanalysators sind sehr hilfreich, danke. Zusammen mit den anderen Informationen denke ich, dass wir einen guten "Verdächtigen" haben.

Es gibt offensichtliche zeitliche Unterschiede zwischen meiner und ihrer Anfrage, aber ich bin mir nicht sicher, ob sie signifikant sind.

Ich wette, die Zeitunterschiede sind erheblich, zumal:

Die Kommunikation mit dem 24C16WI ist erfolgreich

Wenn Sie also Ihren eigenen I 2 C-Master verwenden, können Sie mit dem Standard-I 2 C-Gerät (dem EEPROM) kommunizieren. Wie Sie sagten, besteht das Problem darin, eine Antwort vom PIC zu erhalten, und wie Sie in einem späteren Kommentar darauf hingewiesen haben, verfügt dieser PIC nicht über ein integriertes I2C-Modul:

Ich habe das Datenblatt des Slave-Geräts (PIC12F509) gelesen, aber keine Hardware-I2C-Implementierung gesehen. Ich kann nur vermuten, dass sie Bit-Banging sind.

Ja! Ich habe andere PIC-Geräte (ohne ein internes I 2 C-Modul) gesehen, die als I 2 C-Slaves programmiert waren, die erhebliche Zeitbeschränkungen für ihr I 2 C-Verhalten hatten.

Ich stelle fest, dass es eine längere Verzögerung in der Startsequenz gibt

Exakt. Ich habe nicht mit der Saleae-Software gemessen, aber "mit dem Auge" gibt es eine Verzögerung von ungefähr 0,8 ms zwischen der I 2 C-Startbedingung und dem ersten Umschalten des SCL-Signals auf der Arbeitsspur und keine solche Verzögerung auf der Fehlerspur .

Diese Verzögerung ist kein typisches I 2 C-Verhalten, aber ich vermute, dass die (unbekannte) PIC-Firmware die I 2 C-Startbedingung erkennen muss (z. Funktion, wenn sich das SDA-Signal als Teil der I 2 C-Startbedingung ändert).

Wenn ich in Ihrer Situation wäre, würde ich mit einer Hypothese beginnen, dass das gesamte ursprüngliche I 2 C-Timing wichtig ist (nicht nur die SCL-Taktgeschwindigkeit, bei der Sie bereits ähnlich der ursprünglichen Geschwindigkeit sind) und versuchen, das ursprüngliche Timing und zu duplizieren Verhalten komplett . Immerhin funktioniert diese Originalsequenz :-)

Es gibt noch andere ungewöhnliche Teile der "funktionierenden" I 2 C-Transaktion:

  • Im Adressbyte scheint es eine kleine Verzögerung zwischen dem Takt für Bit 8 und dem Takt für das (9.) ACK/NACK-Bit zu geben. Auch diese Verzögerung (die in Ihrem "fehlerhaften" Trace nicht vorhanden ist) könnte von der PIC-Firmware benötigt werden.

  • Im nächsten Byte sehe ich nur 8 Taktimpulse, nicht die erwarteten 9 Impulse, was den Kommentar der Saleae-Software zu "Missing ACK/NACK" erklärt. Auch dieses (anormale) I 2 C-Verhalten könnte erforderlich sein, um den Erwartungen der PIC-Firmware zu entsprechen, ist aber wahrscheinlich schwierig oder unmöglich zu reproduzieren, wenn „normaler“ I 2 C -Treiber-/Bibliothekscode verwendet wird, wie dies typischerweise erzeugt wird alle 9 normalen Taktimpulse.

Ich bin mir nicht sicher, wie ich das mit dem Atmel ASF I2C-Treiber erzeugen soll.

Ich habe diesen Treiber nicht verwendet. Sie können prüfen, ob Sie nach dem Senden der I 2 C-Startbedingung eine Verzögerung einfügen können , bevor Sie die Geräteadresse senden. Das ist getrennt von dem "Missing ACK/NACK"-Taktimpuls (der möglicherweise fehlen muss!), wenn der Master das zweite Byte im "Working Trace" gesendet hat.

Daher können Sie diesen Treiber möglicherweise nicht "wie er ist" verwenden und müssen stattdessen möglicherweise Ihren eigenen Low-Level-Code ("Treiber") schreiben, der Ihnen mehr Kontrolle gibt. Wenn alles andere Ihnen nicht die erforderliche Menge an Timing- und Taktimpulssteuerung bietet, müssen Sie möglicherweise die SDA- und SCL-Signale des Masters selbst für einige oder alle der benötigten I 2 C-Protokollsequenzen bitbangen .

Ich glaube, Sie sind hier an etwas dran. Das Hinzufügen einer Verzögerung zwischen der Startbedingung und dem ersten Datenbit durch Umschalten auf eine Software-I2C-Implementierung veranlasste den PIC, das Adressbyte zu bestätigen. Ich denke, dass die Schnittstelle möglicherweise falsch als I2C bezeichnet wird :) Die fehlende Bestätigung auf Byte 2 ist besonders interessant.

Warum verwenden Sie die Adresse 0X49?

Ich habe diese Daten auf dem 24C16 gefunden, was bedeutet, dass die Basisadresse 0x50 ist. Achten Sie auf die 7-Bit- oder 8-Bit-Darstellung der Adresse.

Das Timing der "Arbeitsanforderung" sieht schlecht aus. Sie müssen die Einrichtungszeit vor der positiven Flanke der Uhr haben.

Ihre Anfrage ist besser formuliert, hat aber die falsche Adresse.

Geben Sie hier die Bildbeschreibung ein

Kevin, ich versuche mit dem PIC zu kommunizieren, nicht mit dem 24C16. Ich kann erfolgreich mit dem 24C16 auf Adresse 0x50 kommunizieren.
Entschuldigung - mein Fehler. Trotzdem sieht das Timing für die Arbeitsanforderung schlecht aus. Die Daten ändern sich gleichzeitig mit der positiven Flanke der Uhr - das ist kein legales I2C. Wo ist der Start-Übergang?
Das sieht für den Komfort etwas eng aus. Beim Vergrößern werden Daten angezeigt, die etwa 1 μs vor dem Anstieg der Uhr eintreffen .
Warum wird mein I2C-Schreibvorgang NAK'd?
AntwortenHierDatenschutz-Bestimmungen1y, 0v