Wie lassen sich Debug-Trace-Informationen auch bei MCUs ohne Trace-Port sammeln?

Anbieter zum Thema

ACTRON AG

EBV Elektronik GmbH & Co. KG

GLYN GmbH & Co. KG

iSYSTEM AG

Debugtest: Verbindet man nun den iC5000 über die Nexus-Schnittstelle und startet den Trace, so zeigt winIDEA (noch während die Anwendung läuft) den kompletten Programm- und Datenfluss an. Die Datenerfassung erfolgt in Echtzeit, d.h. ohne Stoppen oder Verlangsamen der MCU und ohne Beeinflussung des Verhaltens der Anwendung. Zusätzlich kann der Eingang und die Reaktion auf externe Signale (z.B. AUX) erfasst werden.

Auf dieser Basis ist sowohl Profiling (wann, wie lange welche Funktion ausgeführt wird) als auch Code-Coverage-Analyse verfügbar (welcher Quellcode wird abgearbeitet und was sind „tote“ Codepfade).

• Trace über JTAG/OnCE:

Details zur JTAG/OnCE-Schnittstelle: Die JTAG/OnCE-Schnittstelle stellt nur Run-Control-Debug-Funktionen zur Verfügung wie z.B. Start/Stopp der Programmausführung, Schreiben/Lesen der Register, Setzen von Breakpoints und Watches. Ein Trace des Programm- und Datenflusses ist nicht möglich. Die JTAG/OnCE-Schnittstelle ist ca. 15-mal langsamer als die Nexus-3-Schnittstelle.

Debugtest: Verbindet man den iC5000 über die JTAG-Schnittstelle und startet den Trace, so ist der Trace leer, d.h. er enthält keine Information zur Programmausführung oder irgendwelche Daten. Einzige Debugmöglichkeit ist die Analyse des Disassembly-Codes und der Registerinhalte während die Programmausführung manuell gestoppt wird z.B. über Breakpoints oder Run Unti“.

• Trace über JTAG/OnCE – im Slow-Run-Modus:

Details zur Schnittstelle: Die Schnittstelle ist dieselbe wie im Abschnitt „Trace über JTAG/OnCE“ beschrieben.

Debugtest: Verbindet man den iC5000 über die JTAG-Schnittstelle, wählt Slow-Run-Modus (im winIDEA-Debug-Menü) und startet den Trace, so erhält man den kompletten Programm- und Datenfluss (vergleichbar dem Trace über Nexus). Allerdings dauert im Slow-Run-Modus die Anzeige der Tracedaten deutlich länger durch die schrittweise Programmausführung und die Datenerfassung.

Die resultierende Tracedatei erlaubt eine komplette Programm- und Datenanalyse einschließlich Profiling und Code Coverage. Allerdings fehlen die Echtzeitaspekte in der Zeitmessung.

Vergleich des Zeitverhaltens ohne und mit Slow-Run-Modus

Wie im vorangegangenen Beispiel verwenden wir wieder eine Standardanwendung auf einem MPC5554-Demo-Board. Als Debugwerkzeug wird ein iSYSTEM iC5000 On-Chip Debugger eingesetzt. Tabelle 1 zeigt das Zeitverhalten über die Nexus-Schnittstelle mit und ohne Slow-Run-Modus. Deutlich wird in diesem Zeitvergleich, woher Slow Run seinen Namen hat.

Slow Run eignet sich gut zum Trace kleinerer Bereiche der Applikation. Werden Bibliotheksfunktionen aufgerufen (siehe Tabelle), kann Slow Run sehr lange dauern, da teilweise viel Code eingefügt wird. Auch die Ausführung einer Funktion braucht im Slow-Run-Modus Zeit (Step-over-Beispiel). Soll ein Trace einer kompletten Anwendung aufgezeichnet werden, ist es zu empfehlen, die Daten im Slow-Run-Modus über Nacht zu erfassen.

Eine weitere Einschränkung des Slow-Run-Modus ist das möglicherweise veränderte Verhalten der Anwendung. Durch die schrittweise Abarbeitung der Applikation kann die Reaktion auf externe Signale, z.B. Timer und Interrupts, deutlich verspätet oder im schlimmsten Fall gar nicht erfolgen, wenn z.B. ein Interrupt verloren geht.

(ID:33542060)