Bei der Auswahl einer MCU ist oftmals der Preis ein entscheidender Faktor. Um die Chipkosten niedrig zu halten, verzichten viele Hersteller auf Trace-Schnittstellen. Treten während der Entwicklung oder auch später Probleme auf, fehlt ohne Traceport die Möglichkeit, detaillierte Informationen über die Ausführung der Anwendung zur Laufzeit zu erhalten. Und genau hier hilft der Slow-Run-Modus, indem er folgende Features zur Verfügung stellt:
– Analyse des kompletten Programm- und Datentraces (welche Instruktion wurde mit welchen Daten ausgeführt).
– Code Coverage (welcher Codepfad wurde durchlaufen und was sind „tote“ Codepfade).
– Profiling (wann wird welche Funktion ausgeführt) – allerdings sind im Slow-Run-Mode keine Echtzeitangaben möglich.
Funktionsweise des Slow-Run-Modus
Im Slow-Run-Modus führt winIDEA die Zielanwendung Schritt für Schritt aus und erfasst so den MCU-Status. Aus diesem Inhalt erstellt winIDEA eine Tracedatei, die dann ausgewertet wird. Das Sammeln und die Analyse all dieser Daten braucht Zeit, weshalb dieser Modus auch „Slow Run“ genannt wurde. Die effektive Rate liegt bei etwa 30 bis 50 Befehlen pro Sekunde, abhängig von der benutzten Architektur. Per Default ist Slow Run in winIDEA nicht aktiviert.
Voraussetzungen für den Slow-Run-Modus
Die Voraussetzung für den Slow-Run-Modus ist der Einsatz einer Isystem-Debugger-Hardware wie zum Beispiel iC5000, iC3000 und der zugehörigen Entwicklungsumgebung winIDEA. Seitens der MCU ist lediglich die Unterstützung von Run Control Debug wie beispielsweise Single-Step-Modus oder Run Until notwendig.
Bei einer Standardanwendung auf einem MPC5554-Evaluierungsboard stellt das Board zwei Schnittstellen zur Verfügung, einerseits einen JTAG/OnCE-Port (14 Pins), andererseits ein Nexus-Class-3-Interface (38 Pins). Als Debug-Werkzeug wird ein iC5000-On-Chip-Debugger eingesetzt. Im Folgenden wird verglichen, welche Daten vom iC5000 über die jeweilige Schnittstelle erfasst werden können.
Trace über Nexus
Die Nexusschnittstelle gibt es in unterschiedlichen Ausführungen. Auf dem MPC5554-Demonstration-Board steht eine Nexus-Class-3-Schnittstelle (38 Pin) zur Verfügung. Nexus-Class-3 bedeutet, dass ein Traceport vorhanden ist, der zusätzlich zu Run Control Debug realtime Datentrace und realtime Lesen/Schreiben von Memorybereichen ohne Stoppen der MCU ermöglicht. Im Vergleich zur JTAG/Once-Schnittstelle ist die Datenübertragungsgeschwindigkeit bei Nexus etwa 15 Mal so hoch.
Verbindet man nun den iC5000 über die Nexusschnittstelle 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, das heißt, die MCU wird weder gestoppt noch verlangsamt und das Verhalten der Anwendung wird auch nicht beeinflusst. Zusätzlich lassen sich der Eingang und die Reaktion auf externe Signale (zum Beispiel AUX) erfassen. Auf dieser Basis ist sowohl Profiling (wann, wie lange welche Funktion ausgeführt wird) als auch Code-Coverage-Analyse (welcher Source-Code wird abgearbeitet und was sind „tote“ Codepfade), verfügbar.
Trace über JTAG/OnCE im Slow-Run-Modus
Beim Trace über JTAG/Once im Slow-Run-Modus ist die Schnittstelle dieselbe wie im Abschnitt Trace über JTAG/Once beschrieben. Verbindet man den iC5000 über die JTAG-Schnittstelle, wählt den Slow-Run-Modus 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 Trace-Daten deutlich länger durch die schrittweise Programmausführung und die Datenerfassung. Die resultierende Trace-Datei erlaubt eine komplette Programm- und Datenanalyse einschließlich Profiling und Code Coverage. Es fehlen jedoch die Echtzeitaspekte in der Zeitmessung.
Vergleich des Zeitverhaltens ohne und mit Slow-Run-Modus
Wie im vorangegangenen Beispiel wird wieder eine Standardanwendung auf einem MPC5554-Demonstration-Board verwendet. Als Debug-Werkzeug kommt ein iC5000-On-Chip-Debugger zum Einsatz. Beim Betrachten des Zeitverhaltens über die Nexusschnittstelle mit und ohne Slow-Run-Modus wird deutlich, woher Slow Run seinen Namen hat.
Einschränkungen von Slow Run
Slow Run eignet sich gut zum Trace kleinerer Bereiche einer Applikation. Werden Bibliotheksfunktionen aufgerufen, kann Slow Run sehr lange dauern, da teilweise viel Code eingefügt wird. Auch die Ausführung einer Funktion braucht im Slow-Run-Mode Zeit. Soll ein Trace einer kompletten Anwendung aufgezeichnet werden, ist es empfehlenswert, 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 zum Beispiel Timer und Interrupts deutlich verspätet oder im schlimmsten Fall gar nicht erfolgen, wenn zum Beispiel ein Interrupt verloren geht.
Der Artikel beruht auf Presseinformationen von Isystem.
(ah)
