I2C (TWI) Protokoll mit dem Rigol 1054 betrachtet

Das Rigol 1054Z bietet in der Firmware verschiedene Decoder an, beispielsweise für I2C (=TWI). Der Decoder ist ziemlich leistungsfähig. Kommunikationsprobleme können damit „spielend“ 🙂 gefunden werden.

Im folgenden einige Bilder von einer Analyse, die ich vorgenommen habe.

Obiges Bild zeigt drei Signale und unten die decodierten TWI Daten an. Wenn der decodierte Text wegen Platzmangel nicht darstellbar ist (Zeitbasis zu grob gewählt) wird „…“ dargestellt. Wird die Zeitbasis verfeinert, sind diese Daten dann im Klartext sichtbar.

Violett ist das SDA-Signal, blau das CLK-Signal. Das gelbe Signal stellt keine I2C Daten dar.

Das rote Fragezeichen nach dem „a“ bedeutet, dass der Empfänger kein ACK gesendet hat.

In obigem Bild wurde auf das erste Kommunikationsbyte gezoomt. Man sieht dass der Master versucht, an das Gerät mit der Adresse 0x2E zu schreiben. Dies wird als „W:2E“ dargestellt.  Man kann erkennen, dass der Slave ein ACK gesendet hat und auch der Rigol 1054 hat dieses ACK erkannt, er zeigt kein Fragezeichen an.

Und hier ist das Byte noch weiter vergrößert. Das ACK ist dadurch erkennbar, dass der Slave während der HI-Phase des 9. Taktes SDA auf LO hält. So ist ACK im Protokoll definiert.

Hier ein Datenbyte. Der Decoder zeigt leider den Datenwert bei dieser Zoomstufe nicht an, evtl. fehlt eine Start-Bedingung o.ä. zur Synchronisation. Wenn man herauszoomt, wird der Wert aber angezeigt.

Hier versucht der Master vom Slave mit der Adresse 0x2E zu lesen. er bekommt ein ACK, der Slave hat das Kommando also verstanden. Dann liest der Master vom Slave das Zeichen „0x0a“ ein.  Der Master gibt dem Slave kein ACK am Ende der Übertragung des  Bytes .

Der 1054Z kann den Datenwert auch anders als Hex darstellen, z.B. ASCII und binär.

In diesem Bild ist der „Event“-view des 1054 eingeblendet. Hier wird die Kommunikation zusammengefasst, alles zwischen einem Start und einem Stop kommt in eine Zeile einer Tabelle. Man sieht, dass der Master den Wert „0x37“ in den Slave mit der Adresse 0x07 schreibt. Dann liest der Master aus dem Slave 9 Bytes ein, das letzte Byte wird ohne ACK gelesen.

Konkret wird hier die Kommunikation zwischen einem Solarlademodul (Master) und einer „intelligenten“ Batterie (Slave) dargestellt. Der Master schickt das Kommando 0x37 (read measurement data) und das Batteriemodul sendet die Werte Batteriespannung, momentaner Ladestrom, Batterietemperatur und ein Statusbyte zurück.

In obigen Bild ist eine fehlerhafte Kommunikation zu sehen. Ein Master versucht vom Slave mit der Adresse  0x07 zu lesen, aber der Slave gibt für das „R:07“ Kommando kein ACK.  Der Master versucht daraufhin, die Kommunikation erneut zu starten, bekommt dann aber schon auf das „W:07“ keine Antwort mehr. Irgendetwas ist mit dem Slave passiert.

Obiges Bild zeigt eine weitere Fehlersituation. Der Slave quittiert das „W:07“ und das gesendete Byte 0x02 beides mit ACK,  produziert aber dann während der Master  die Sequenz „R:07“ – <Kommandobyte> schicken will, beim ersten Takt des Kommandobytes eine STOP-Condition. Dies interpretiert der Master (ein ATmega644 mit Hardware TWI) korrekt als Bus Error und bricht die Kommunikation ab.

Erstes Fazit

Die Möglichkeiten des Rigol 1054Z bei der Decodierung serieller Protokolle sind enorm. So wird z.B. auch RS232 und SPI unterstützt. Mit der Möglichkeit des fast beliebigen Hineinzoomens dank des riesigen Akquisitionsspeichers hat man ein mächtiges Hilfsmittel zur Fehlersuche an der Hand.

Durch die vorhandenen 4 Kanäle kann man sich einen dritten Kanal zur Generierung eines Triggers definieren. Auf diese Art kann man sich ganz gezielt auf problematische Situationen fokussieren, indem man z.B. beim Eintreten einer zu untersuchenden Situation einen Trigger erzeugt . Die gesamte „Geschichte“ um die Situation kann dann in Ruhe analysiert werden.

Schreibe einen Kommentar