Die neue Trace-Welt jenseits von Code- und Daten-Trace

Anbieter zum Thema

ODU GmbH & Co. KG

MicroConsult Academy GmbH

congatec GmbH

PLS Programmierbare Logik & Systeme GmbH

Freescale nutzt bei der PowerPC-basierten Qorivva-MPC57xx-Familie Nexus [2] für die Trace-Unterstützung. Jede CPU, alle Systembusse, aber auch das GTM sind als Nexus-Clients in der Lage, Trace-Daten zu erzeugen und in einen gemeinsamen Trace-Strom zu schreiben. Anders als bei Infineon werden die Trace-Pakete direkt im Nexus-Client erzeugt und nicht erst als Datenwort an das Trace-System übergeben.

Der Debugger also direkt aus dem Trace-Paket die Herkunft und Bedeutung des Trace-Datums rekonstruieren. Einzige Einschränkung: Aufgrund der Fülle von Signalquellen gerade bei der GTM ist es trotzdem notwendig, für bestimmte Gruppen von GTM-Einheiten eine Vorselektion durchzuführen. Diese Vorselektion muss dann wiederum dem Debugger bekannt gemacht werden.

Verarbeitung im Rechenkern und Interaktion mit der Peripherie beobachten

Nun ist das GTM ja nicht das einzige Modul, dessen Signale für die Systemanalyse interessant sind. Auch andere Peripherie wie CAN-Controller, FlexRay-Controller, DMAs etc. haben Einfluss auf das Laufzeitverhalten. Deren Integration in das Trace-System und der damit verfügbare Signal-Trace erlaubt es erstmalig, die eigentliche Verarbeitung in den Rechenkernen und deren Interaktion mit den Peripherals zu beobachten.

Nur was anfangen mit der Unmenge an zusätzlichen Informationen im Trace, wenn die On-Chip-Debug-Hardware allein nicht die Leistungsfähigkeit besitzt, diese Fülle auch uneingeschränkt im Trace sichtbar zu machen? Das auf dem Chip selbst Signale bereits gefiltert werden, um die erforderliche Bandbreite für den Trace im erforderlichen Rahmen zu halten, gleicht dem berühmten Tropfen auf den heißen Stein. Gleichzeitig stellt sich die Frage nach der Beherrschbarkeit der Auswertung. Je größer die Informationsflut, desto schwieriger wird es am Ende für den Debugger und letztlich für den Anwender, etwaige funktionale Fehler oder Performance-Bugs zu finden.

Eine vergleichsweise einfache Möglichkeit zur Konfiguration der jeweiligen Hardware-Filter und Signalpfade für den Peripheral-Trace im Qorivva MPC57xx bzw. AURIX bietet der Universal Emulation Configurator (UEC) der Universal Debug Engine (UDE) von PLS, ein Werkzeug, dass schon seit längerem auch für die Konfiguration von Infineons MCDS Verwendung findet [3].

Datenfluten beherrschbar machen

Das flexible Bedienkonzept des UECs erlaubt die Kombination von „gewöhnlichem“ Programm- und Daten-Trace mit dem neu hinzugekommenen Signal-Trace (Bild 2). Eine Trace-Aufgabe lässt sich also komplett mittels eines einheitlichen Werkzeuges erstellen. Auch für die Trace-Auswertung sind natürlich eine Kombination der einzelnen Trace-Quellen und deren gemeinschaftliche Darstellung erforderlich. In Bild 3 ist ein Beispiel für einen solchen kombinierten Trace dargestellt.

Von großem Nutzen ist die Kombination der einzelnen Trace-Quellen natürlich vor allem dann, wenn bestimmte Ereignisse beobachtet werden sollen. Will man beispielsweise messen, wie lange ein Interrupt-Service benötigt, um vom Eintreffen einer bestimmten Message auf dem CAN-Bus mit einem Signal auf einem externen Pin zu reagieren, so lässt sich diese Aufgabe nun leicht mittels Trace lösen.

Der On-Chip-Trace „erkennt“ das Eintreffen einer CAN-Message – er kann dabei diese Nachrichten sogar nach deren Herkunft oder Typ filtern – und startet die Trace-Aufzeichnung. Das Schreiben eines Port-Pins ist ebenfalls für die Trace-Einheit sichtbar und kann als Endbedingung der Messung heran gezogen werden. Bild 4 zeigt die entsprechende Messaufgabe, die dafür über die grafische Oberfläche des Universal Emulation Configurator erstellt wurde.

Neben der Zeitmessung ist im Beispiel zusätzlich auch ein kompletter Code- und Datentrace eingestellt, der für die Laufzeitoptimierung sehr hilfreich ist. Über die Profiling-Funktion (Bild 5) lassen sich so zeitraubende Sequenzen der Interrupt-Service-Routinen leicht identifizieren.

Literaturhinweise:

[1] Robert Bosch GmbH: Product Information Generic Timer Module (GTM) IP, www.bosch-semiconductors.de

[2] The Nexus 5001 Forum Standard for a Global Embedded Processor Debug Interface Version 2.0; http://www.nexus5001.org

[3] PLS Development Tools: Universal Emulation Configurator (UEC) for TriCore Emulation Device; www.pls-mc.com

* * Jens Braunes ist Software-Architekt bei PLS Programmierbare Logik & Systeme in Lauta.

(ID:37541440)