Fehlersuche in seriellen Protokollen mit einem Oszilloskop

Oszilloskop versus Logikanalysator

Zur Protokoll-Decodierung kann ein Oszilloskop, ein Logikanalysator oder ein spezieller Protokollanalysator eingesetzt werden. Doch welches Gerät eignet sich am besten? Hier ist ein kurzer Vergleich der drei Alternativen.

Die Kanäle eines Logikanalysators sind im Grundsatz digitale Komparatoren. Daher geben sie nur an, ob ein Signal auf HIGH- oder LOW-Pegel ist. Typische Logikanalysatoren haben mindestens acht Kanäle, einige Modelle bieten 32 oder mehr. Protokollanalysatoren sind Logikanalysatoren ähnlich, verfügen aber über protokollspezifische Hard- und Software zur Decodierung der seriellen Daten.

Demgegenüber bieten Oszilloskope eine hohe Bitauflösung, sind jedoch normalerweise auf zwei oder vier Kanäle beschränkt. Dank der höheren Bittiefe lassen sich auch die analogen Eigenschaften von Signalen analysieren.

Zum Glück ist es mit modernen Oszilloskopen nur noch selten erforderlich, sich für eine dieser drei Optionen zu entscheiden. Viele Oszilloskope, darunter alle Modelle von Rohde & Schwarz, bieten sowohl analoge als auch digitale Logikkanäle. Solche Oszilloskope werden „Mixed-Signal-Oszilloskope“ genannt.

Manche Oszilloskope verfügen sogar über spezielle Protokolldecodierungstools für serielle Busse. Beispielsweise verfügen das R&S®RTB2000, R&S®MXO 4 oder R&S®RTO 6 über eine integrierte Protokoll-Decodierung und Trigger für häufig verwendete serielle Protokolle.

Das Oszilloskop glänzt insbesondere dann, wenn ein Protokollfehler erkannt wird. Ein (oder mehrere) analoge Kanäle, die den Bus abtasten, können aufklären, ob zum Zeitpunkt des Protokollfehlers (oder in zeitlicher Nähe) ein analoges Problem vorliegt. Diese Möglichkeit besteht bei einem Logikanalysator nur selten.

Da es viele verschiedene serielle Protokolle gibt, die nicht immer von allen Oszilloskop-Modellen unterstützt werden, finden Sie hier einige Hinweise und Tricks zur Fehlersuche in Schaltungen für die gängigsten Busse.

UART

UART (Universal Asynchronous Receiver/Transmitter) wird manchmal auch als „seriell“ bezeichnet. Die Sende- und Empfangssignale sind Leitungen ohne diskreten Takt. Es handelt sich um eine Punkt-zu-Punkt-Verbindung – es sind also normalerweise nur zwei Geräte beteiligt.

In manchen Fällen ist UART am einfachsten zu debuggen, da unter Umständen nur ein Signal untersucht werden muss: TX oder RX. In der Praxis müssen Sie jedoch meist beide Richtungen betrachten, um den Kommunikationsablauf zu verstehen.

UART verwendet ein flexibles Framing-Verfahren. Es gibt eine variable Anzahl von Start- und Stoppbits und ein optionales Paritätsbit. Die Datennutzlast beträgt normalerweise 8 Bit. Da UART asynchron ist, müssen sich Host und Gerät über diese Parameter sowie über die Baudrate verständigen. Für ein Oszilloskop gelten bei der Fehlersuche die gleichen Anforderungen.

Tipp: Bei Decodern können Sie normalerweise die Baudrate nach der Erfassung ändern. Passen Sie diese Einstellung an, wenn die Decodierung Datenmüll liefert. Ansonsten ist keine ordnungsgemäße Decodierung (oder Triggerung) möglich.

SPI & QSPI

SPI steht für „Serial Peripheral Interface“. Dieses Bus-System funktioniert wie ein Schieberegister. Sämtliche beteiligten Geräte teilen sich den Takt, die MOSI- (Main Output, Secondary Input) und die MISO-Signale (Main Input, Secondary Output). Diese entsprechen „TX“ und „RX“ bei UART. Sie geben jedoch eindeutig an, in welche Richtung sich die Daten bewegen. Beispielsweise werden die Daten bei MOSI vom Host zum Gerät übertragen und bei MISO vom Gerät zum Host. Dadurch wird es unwahrscheinlicher, dass versehentlich das falsche Signal abgetastet wird.

Das SPI-Protokoll unterstützt neben dem Host mehrere Teilnehmer auf demselben Bus. Für jedes Gerät ist ein Chip-Select-Signal (CS) vorgesehen, mit dem zwischen den beteiligten Geräten unterschieden wird. Bei Designs mit nur einem Teilnehmer kann das CS-Signal jedoch entfallen (oder immer aktiviert sein). Wenn außerdem die Daten nur in eine Richtung gehen, wird lediglich das entsprechende MOSI- bzw. MISO-Signal benötigt.

Dasselbe Prinzip gilt für die Fehlersuche mit einem Oszilloskop. Wenn sich nur ein Teilnehmer am Bus befindet, kann das CS-Signal ignoriert werden. Und wenn sich die Daten nur in eine Richtung bewegen, kommen die meisten Decoder mit nur einem Signal zurecht. Das Taktsignal wird jedoch immer benötigt.

Was ist QSPI?

Ein weit verbreiteter Schnittstellenstandard für Flash-Speicherchips ist das Quad-SPI-Protokoll (QSPI). Wie auch bei SPI sind ein Takt-, Aktivierungs- und Datenpin vorgesehen.

Inter-Integrated Circuit (I2C)

Der Inter-Integrated Circuit (I²C) wurde ursprünglich von Philips Semiconductors entwickelt. Die Sparte wurde später von Philips ausgegliedert und ist heute als NXP Semiconductors bekannt. Manchmal verwenden Geräte, die I²C unterstützen, die Bezeichnung „two-wire“, um Marken- oder Lizenzprobleme zu vermeiden.

Alle Geräte am Bus teilen sich die Takt- und Datenleitung, und jedes Gerät benötigt eine eindeutige Adresse. Im Allgemeinen haben Sensoren oder Geräte, die I²C nutzen, eine Basisadresse mit einigen Bits, um die niederwertigsten Bits ihrer Adresse festzulegen. Diese Technik ist nützlich, wenn sich mehrere gleiche Sensoren mit einer minimalen Anzahl von Pins am Bus befinden.

Um bei I²C eine Fehlersuche mit dem Oszilloskop durchzuführen, werden zwei Kanäle benötigt. Der Takt läuft nur, wenn der Host mit einem Busteilnehmer kommuniziert. Daher muss das Oszilloskop sowohl das Takt- als auch das Datensignal erfassen.

I²C: 7 bit oder 8 bit (oder 10 bit)

I²C-Adressen können aufgrund von zwei verschiedenen Adressmodi zu Verwechslungen führen: 7 bit und 10 bit. Der 7-bit-Modus ist weiter verbreitet – weist jedoch eine verwirrende Besonderheit auf: Er wird manchmal als 8-bit-Adresse interpretiert.

Der Übeltäter ist das R/W-Bit, das auf die Adresse folgt. Bei READ-Transaktionen ist der Wert „1“ und bei WRITE-Transaktionen „0“. Wenn also beim Debuggen von I2C an der erwarteten Adresse nicht getriggert wird, empfiehlt es sich, die Adresse um ein Bit nach links zu verschieben und den R/W-Wert einzuschließen.

CAN-Bus

Das Controller Area Network (CAN) wurde für den Einsatz in Fahrzeugen entwickelt und ist in der Transportbranche bis heute weit verbreitet. Die differenzielle Signalübertragung sorgt für eine gute Störfestigkeit gegenüber elektrischem Rauschen, sodass sich der Bus ideal für industrielle Anwendungen eignet.

Trotz des differenziellen Ansatzes ist in den meisten Fällen kein differenzieller Oszilloskop-Tastkopf erforderlich. Stattdessen reicht ein massebezogener Tastkopf am „CANH“- oder „CANL“-Signal aus, um die Decodierung durch einen Oszilloskop-Decoder zu ermöglichen.

Es gibt zwei CAN 2.0-Versionen: Base (11-bit-Adresse) und Extended (29-bit-Adresse). Die jeweiligen Datenrahmen unterscheiden sich geringfügig in den Arbitrierungs- und Steuerfeldern, ansonsten sind ihre Pakete jedoch gleich.

Der CAN-Bus verwendet nur zwei Signalleitungen, die beide kein Takt sind. Wenn eine Decodierung fehlerhaft erscheint, versuchen Sie daher, den Abtastpunkt anzupassen, damit der Decoder die Daten korrekt erfassen kann.

Decodieren versus Triggern

Die Decodierung stellt ein Nachverarbeitungsverfahren dar, bei dem die erfasste Signalform analysiert und das Protokoll in eine für Menschen lesbare Form übertragen wird. Normalerweise stehen die decodierten Daten als Overlay in der Messkurvenanzeige oder als Tabelle zur Verfügung. (Einige Oszilloskope, wie das R&S RTE, RTO6 und RTP, bieten auch zusätzliche Analysetools etwa für die Bus-Auslastung.) Oszilloskope mit tiefem Speicher können lange Zeiträume erfassen und im Nachgang nach relevanten Ereignissen suchen (oder ermitteln, wie oft solche Ereignisse auftreten). Bei dieser Technik handelt es sich in erster Linie um ein Software-Verfahren.

Bei einer Triggerung verhält es sich anders – sie erfolgt innerhalb des Triggersystems des Oszilloskops. Ein Protokolltrigger überwacht kontinuierlich den seriellen Bus, um festzustellen, wann bestimmte Ereignisse auftreten. Zwei gängige Trigger sind etwa I2C-Adressen und Fehlerzustände (NAK- oder Paritätsfehler). Die Trigger-Optionen sind im Allgemeinen auf einige protokollspezifische Transaktionen beschränkt und können auch auf die Bittiefe von Adresse, Daten oder Nutzlast beschränkt sein. Diese Technik stellt primär einen Hardware-Ansatz dar.

Manchmal kombinieren Oszilloskope die beiden Techniken: Das Triggersystem kann „auto-triggern“, während der Protokoll-Decoder das relevante Ereignis findet und es dann in der Mitte des Bildschirms platziert. Falls Ihr Oszilloskop bestimmte Ereignisse nicht erfasst, lesen Sie im Handbuch nach, welche Trigger-Bedingungen hardware- und welche softwarebasiert sind.