ECKDATEN

Es zeigt sich, dass ein integriertes Betriebssystem wie Jedos die Testmöglichkeiten gerade in komplexen Designs erheblich erweitern kann. Im Zusammenspiel mit etablierten Testmethoden kann somit eine noch höhere, durchgängige Testabdeckung erreicht werden.

Ein erster Schritt in diese Richtung ist eine entsprechende Verwendung dieser Bauelemente für einzelne, spezifische Tests. Dazu zählen zum Beispiel Flash-Programmierung, Ansprechen von RAM-Bausteinen, Messen von Frequenzen oder Spannungen sowie das Betreiben einer Schnittstelle. Jeder dieser spezifischen Tests hat allerdings eine einzelne, spezifische Testaussage zum Ziel. Den Gegensatz dazu bildet der funktionale Test in der Endanwendung. Aufbauend auf Grundfunktionen validiert er die Baugruppe insgesamt. Die verwendeten Grundfunktionen können mit diesen Tests jedoch in der Regel nicht weiter analysiert werden. Strukturellen Tests wie Boundary Scan fehlen wiederum die dynamischen Möglichkeiten, um diesen Problemen auf den Grund zu gehen. Je nach Komplexität von Design und Funktion entsteht somit eine Testlücke zwischen den Verfahren, die oft nur mit erheblichem Aufwand reduziert werden kann.

Jedos

Bild 1: Mögliche Testschleifen beim Ethernet. Göpel

Mögliche Testschleifen beim Ethernet

Zur Verdeutlichung dieser Problematik kann das Ping-Testen einer Ethernet-Schnittstelle mit einem externen Tester herangezogen werden (Bild 1). Aufgrund von Kontaktierungsproblemen an der Schnittstelle oder unterbrochenen Leiterbahnen kann beispielsweise kein Ping vom externen Tester empfangen werden; genaue Fehleraussagen sind infolgedessen schwierig. Ebenso ist ein Szenario vorstellbar, in dem die native Firmware nicht oder nur teilweise geladen werden konnte oder sogar selber fehlerhaft ist. Darüber hinaus können Testausfälle verursacht werden, wenn andere Komponenten (zum Beispiel PHYs) zwischen Mikrocontroller und Tester liegen. Wenn sich schließlich alles in Geschwindigkeitsklassen wie 10/100/1000 Mbit/s abspielt, wird die Analyse noch schwieriger, da Übertragungsqualität und statistische Fehler immer bedeutender werden. Schließlich ist beim Einsatz eines externen Testers immer auch eine Firmware für den Mikrocontroller auf der Baugruppe notwendig. Firmware dieser Art beinhaltet oft weitaus mehr Funktionen, als für den Test überhaupt notwendig wäre. Solch große Softwareblöcke brauchen viel Zeit zum Laden und verlängern die Gesamttestzeit unnötig.

Bild 2: Das Embedded Diagnostic System.

Bild 2: Das Embedded-Diagnostic-System. Göpel

Jedos schließt der Lücke

Ein Ansatz zum Schließen dieser Lücke liegt in der stärkeren Nutzung der funktionalen Möglichkeiten der verwendeten Bausteine. Idealerweise sollte die Testsoftware die kompletten Potenziale des Mikrocontrollers nutzen, dabei jedoch nicht größer als nötig sein (Bild 2). Dieses Ziel verfolgt Jedos (Eigenschreibweise: JEDOS, JTAG Embedded Diagnostic Operating System). Ziel ist eine spezielle Erweiterung der Testmöglichkeiten in Richtung funktionaler Tests innerhalb der Software-Umgebung System Cascon. Über eine grafische Oberfläche können Tests mit wenig Aufwand ausgewählt und konfiguriert werden (Bild 3).

jedos

Bild 3: Die grafische Oberfläche zur Konfiguration.

Hinzukommend sind Erweiterungen und gänzlich spezifische Tests möglich. Je nach Anforderung stehen hierfür mittels Skript-Sprache Basisroutinen und erweiterte Funktionen zur Verfügung, über die zum Beispiel spezifische Funktionalitäten kontrollierbar sind, aber auch eine direkte Ergebnisvalidierung auf dem Baustein möglich ist. Aus diesen Angaben wird ein Prüfablauf generiert, welcher nur die tatsächlich notwendige Software enthält und somit die Gesamttestzeit im Rahmen bleibt.

Umfangreiche Testkonfigurationen

Bezogen auf das oben genannte Beispiel kann die Ethernet-Schnittstelle wie in der Endanwendung betrieben werden, wodurch umfangreiche Testkonfigurationen möglich sind. Nicht immer muss notwendigerweise die gesamte Verbindungsstrecke getestet werden, sondern auch Teilstrecken, wie zum Beispiel die Verbindung vom Mikrocontroller zum PHY (Bild 4). Dadurch können Analysemöglichkeiten für Fehlerfälle stark erhöht, beziehungsweise in manchen Fällen überhaupt erst ermöglicht werden. Weil die kompletten Prüfabläufe nun auf dem Mikrocontroller liegen ist kein externer Tester mehr vonnöten. Bereits ein einfacher Loopback-Stecker ist hinreichend, um die vielfältigen Testoptionen zu nutzen.

jedos

Bild 4: Die kompletten Prüfabläufe liegen auf dem Mikrocontroller, es ist kein externer Tester mehr nötig.

Sollen große Datenmengen in Flashbausteine programmiert werden, so sind die benötigten Programmierzeiten insbesondere in der Produktion von erheblicher Bedeutung. Durch die vollständige Kontrolle der Interfaces des Mikrocontrollers können mit Jedos die Daten auch über Highspeed-Schnittstellen wie Ethernet oder SD-Karte bereitgestellt werden. In der Konsequenz können die physischen Programmierzeiten der Flashbausteine nahezu komplett ausgereizt werden.

Prüfen von DDR-Komponenten

Das Prüfen von DDR-Komponenten ist ein weiteres, zunehmend relevantes Testthema. Bisherige Strukturtests wie Boundary Scan beschränken sich auf das Prüfen der Anschlüsse solcher Bausteine. Dabei wird ermittelt, ob alle verwendeten Adress-, Daten- und Kontrollleitungen angeschlossen und frei von Kurzschlüssen sind. Dynamische Eigenschaften bleiben komplett ungeprüft, können aber in späteren funktionalen Tests erheblichen Einfluss auf die Ergebnisse haben.

Da Jedos auch hier die komplette Funktionalität des Mikrocontrollers nutzt, stehen umfangreiche Prüfabläufe für die DDR-Analyse zur Verfügung (Bild 5). Diese umfassen ebenso Stress- und Noise-Tests wie Tests für verschiedene Burst-Modi. Da hierbei die volle Geschwindigkeit des Mikrocontrollers genutzt werden kann, sind die Prüfzeiten im Vergleich zu den strukturellen Tests entsprechen kurz.

jedos

Bild 5: Die Jedos-Teststruktur.

Ergänzend zur Anschlussprüfung kann Jedos die Einstellungen der DDR-Bausteine optimieren. Für den Einsatz von DDR-PHY-Registern werden häufig Standardwerte verwendet. Diese ermöglichen zwar den Betrieb, sind aber nicht optimal an die Gegebenheiten angepasst. Durch die DDR-Kalibrierung ist eine Anpassung an die Schaltung als auch an eventuelle spezifische Umgebungsbedingungen möglich. Gerade bei einem Betrieb in den Grenzbereichen des DDR-Bausteins wird dadurch eine erhebliche Steigerung in der Stabilität der Zugriffe möglich.