Mit dem Oszilloskop auf Fehlersuche in seriellen Bussen

Anbieter zum Thema

MES Electronic Connect GmbH & Co. KG

IBR Leiterplatten GmbH & Co. KG

DMB Technics AG

Teledyne GmbH

Jede Schaltung sollte auf Hardwarefehler überprüft werden

Jedes serielle Datenprotokoll hat seine eigenen Spezifikationen bezüglich den Informationen auf der physikalischen- und der Protokollebene. Die physikalische Ebene ist typischerweise als Toleranzbereich zum Idealzustand spezifiziert. Solche Ideale und die Toleranzen können für die Variation der Bit-Rate, das Timing von Daten/Takt, Spannungsstufen und für die Signalform angegeben sein. Die Maskenbildung in einem Oszilloskop stellt ein weiteres Hilfsmittel dar, um die physikalische Ebene zu überprüfen. In Bild 6 wird anhand eines FlexRay-Beispiels gezeigt, wie in einem Augendiagramm die Verstöße mit roten Kreisen hervorgehoben sind. Das bedeutet, dass die Signale nicht den FlexRay-Spezifikationen entsprechen und daher nicht konform sind. Solche Ereignisse bedürfen weiterer Untersuchungen. Jede Schaltung sollte auf Fehler der Hardware überprüft werden, bevor die Protokoll-Ebene geprüft wird. Es muss sichergestellt sein, dass die physikalischen Spezifikationen für Spannungsstufen, Pulsdauer, Bit-Rate oder Takt/Daten-Timing erfüllt werden.

Busse in verschiedenen Stadien der Entwicklung prüfen

Eine Decodierung der Spannung gegenüber der Zeit des Signals für die Fehlersuche auf der Protokollebene wird manchmal von Anwendern als unnötig angesehen. Ein Entwickler könnte vermuten, dass die von Silizium-Lieferanten bereitgestellten Busse und Bauteile in Ordnung sind, da der Händler die erforderlichen Spezifikationen kennt und einhalten wird. Das ist in der Praxis jedoch nicht immer der Fall. Protokoll-Trigger- und Decodiereigenschaften sind meist optionale Ergänzungen zu Oszilloskopen. Ein Oszilloskop kann daher mehrere unterschiedliche Decodieroptionen für serielle Protokolle integriert haben und erlaubt es dem Anwender, Busse in verschiedenen Stadien der Entwicklung zu überprüfen, oder sogar mehrere Busse gleichzeitig zu decodieren.

Der Einsatz von protokollorientierten Triggern

Ein Beispiel ist die Wartezeit im Datenverkehr zwischen verschiedenen Bussen. Die Protokolltriggerung und –decordierung mit dem Oszilloskop kann unterschiedlich ausgeprägt sein. Wird lediglich der Flankentrigger angewandt und dann das Signal decodiert zeigt das dem Anwender die decodierten Informationen an. Protokollorientierte-Trigger erlauben es dem Anwender, auf spezielle Address- oder Daten-Informationen oder bestimmte Fehlerbedingungen zu triggern. Die Protokoll-Decodierung unterscheidet sich zum Teil gravierend zwischen unterschiedlichen Oszilloskop-Herstellern im Markt.

In Bild 7 sieht man das Triggern auf der Protokollebene, eine Tabelle der Decodierung und das analoge Signal mit farbig hinterlegten decodierten und überlagerten Bereichen. Diese Darstellung erleichtert es erheblich, das Auftreten bestimmter Ereignisse im Bus besser zu verstehen.

* Thomas Stüber ist Leiter der Applikationsentwicklung bei LeCroy in Heidelberg.

(ID:32943640)