Schwerpunkte

Drei aktuelle On-Chip-Trace-Verfahren im Vergleich

Auf den Spuren der Fehler

14. November 2007, 15:37 Uhr   |  Heiko Riessland und Jens Braunes


Fortsetzung des Artikels von Teil 1 .

Nur die Daten aufzeichnen, die auch benötigt werden

Schwieriger gestaltet sich das Ganze beim Daten-Trace. Hier ist meistens die Aufzeichnung des kompletten gelesenen oder geschriebenen Datenwortes und dessen Adresse auf dem Adressbus erforderlich. Viele zeitlich dicht aufeinander folgende Datenzugriffe verursachen indes eine so große Menge an Trace-Informationen, dass diese nicht mehr über den in seiner Bandbreite doch recht beschränkten Debug-Kanal übertragen werden können. Der On-Chip-Trace-Speicher wäre in so einem Fall schon nach wenigen Millisekunden gefüllt, ein typischer „Overrun“ also. Zudem würde eine anschließende Auswertung – unabhängig, ob manuell durch den Benutzer oder mittels automatischer Werkzeuge – erschwert, wenn nicht gar unmöglich. Es ist daher sinnvoll, nur die Daten aufzuzeichnen, die auch später zur Analyse wirklich benötigt werden.

Je nach On-Chip-Trace-Lösung lassen sich hierfür mehr oder weniger komplexe Filter- und Triggerbedingungen definieren, die entweder die Trace-Aufzeichnung starten oder stoppen. Üblicherweise sind dies Adress- und Daten-Bereiche sowie Break- und Watchpoints. Die Auswertung der programmierten Filter- und Triggerbedingungen erfolgt dabei in Echtzeit durch die On-Chip-Trace-Hardware selbst. Die eigentlichen Core-Komponenten sind nicht involviert, so dass keine Mehrbelastung der Systemressourcen entsteht und das Laufzeitverhalten unbeeinflusst bleibt.

Neben der reinen Trace-Datenaufzeichnung besteht auch die Möglichkeit, steuernd in das Laufzeitverhalten einzugreifen. So lassen sich typische Debug-Funktionen wie das Anhalten des Gesamtsystems oder das bedingte Unterbrechen der Programmabarbeitung an bestimmten Positionen oder unter bestimmten Bedingungen (Breakpoints/ Watchpoints) realisieren.

IEEE-ISTO 5001: der Nexus-Standard

Im Nexus-5001-Forum haben sich verschiedene Chip-Hersteller und Tool-Anbieter zusammengeschlossen, um die Debug-Schnittstellen für eingebettete Systeme zu vereinheitlichen. Daraus hervorgegangen ist der Nexus-Standard IEEE-ISTO 5001. Mit ihm sind zunächst keine Implementierungsdetails für die On-Chip-Debug-Unterstützung festgelegt. Vielmehr definiert der Standard Eigenschaften und Debug- Features. Eine Mindestmenge von Eigenschaften muss der Chip-Hersteller implementieren, weitere Fähigkeiten kann er einbauen – je nachdem, welche „Compliance Class“ er erreichen will. Mikrocontroller, deren Debug-Schnittstelle nach dem Nexus-Standard implementiert ist, müssen sich in mindestens eine der vier „Compliance Classes“ einordnen lassen, wobei für Klasse 1 die wenigsten Debug-Features zu implementieren sind und die Klasse 4 die umfangreichste Implementierung erfordert (Tabelle 1). Speziell für Trace sind die Eigenschaften in [1] zusammengefasst. Mikrocontroller, die den Anforderungen der Klasse 2 und aufwärts genügen, unterstützen sowohl den Programm- als auch den Ownership-Trace. Letzterer erlaubt es, das Gesamtsystem auf Prozessebene bzw. Task-Ebene zu beobachten. Der Ownership-Trace liefert für diesen Zweck die jeweilige Prozess-ID bzw. die ID des jeweiligen Betriebssystem-Tasks. Ab Klasse 3 wird außerdem Daten-Trace unterstützt.

Da im Nexus-Standard kein On-Chip-Trace-Speicher vorgesehen ist, wird zur Übertragung der Trace-Daten neben dem JTAG-Interface ein breitbandiger Debug-Kanal benötigt. Diese, als Auxiliary-Port bezeichnete Schnittstelle überträgt bei Upload und Download theoretisch maximal 1,6 Gbit/s. Die Kommunikation erfolgt mittels Messages, welche sowohl Steuerinformationen für die Trace-Aufzeichnung in Richtung Zielsystem als auch die aufgezeichneten Trace-Daten für den Debug-Host enthalten. Quellen für Trace-Messages können unterschiedliche Komponenten wie Cores, Busse etc. sein, die jeweils eigene Buffer mitbringen, um Spitzen im Message-Aufkommen zu glätten. Trotzdem kann es vorkommen, dass die Bandbreite des Auxiliary-Ports nicht ausreicht, einen Burst an Trace-Daten an den Debug-Host zu übertragen. Ein damit verbundener Datenverlust im Trace-Datenstrom wird durch spezielle Messages, so genannte Overrun-Messages, gekennzeichnet. Das System wird jedoch nicht angehalten und somit das Echzeit-Verhalten nicht beeinflusst. Die „Compliance Class“ 4 sieht diese optionale Möglichkeit allerdings für den Fall vor, dass Trace-Daten nicht verloren gehen dürfen und die Einhaltung von Echtzeit-Bedingungen keine Rolle spielt.

Eine Reduktion der erforderlichen Trace-Bandbreite kann durch differenzielles Abspeichern der Adressen erreicht werden. Dabei werden nur die sich ändernden Anteile der Adressen in den Messages gespeichert. Datenverluste durch Overruns können auf diese Weise verringert werden.

Für die einzelnen Trace-Arten müssen jeweils entsprechende Steuerregister zur Realisierung der Filter- und Triggerfunktionalität implementiert werden. Neben der vom Debug-Host direkt zu startenden oder stoppenden Trace-Aufzeichnung lassen sich Adressbereiche sowie Vergleiche auf Daten- bzw. Befehlsmuster definieren, die ihrerseits die Trace-Aufzeichnung abhängig vom jeweiligen Programm- und Datenfluss beeinflussen. Diese Trace-Steuerung über Watchpoints wird nur durch Prozessoren unterstützt, die die Compliance Class 4 implementieren.

tabelle1_25.jpg
©

Tabelle 1. IEEE-ISTO 5001 Nexus Compliance Classes (Auszug)

Seite 2 von 4

1. Auf den Spuren der Fehler
2. Nur die Daten aufzeichnen, die auch benötigt werden
3. Neue Möglichkeiten erfordern neuartige Werkzeuge
4. Für ARM-Cores: Emdedded Trace Macrocell (ETM)

Auf Facebook teilenAuf Twitter teilenAuf Linkedin teilenVia Mail teilen