Software-Debugging
Langsam geht‘s auch ohne Port
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 nun während der Entwicklung (oder auch später) Probleme auf, fehlt ohne Trace-Port die Möglichkeit, detaillierte Informationen über die Ausführung der Anwendung zur Laufzeit zu erhalten. Die Sparsamkeit kostet dann zumindest Zeit.
Wenn kein Trace-Port zur Verfügung steht, bleibt natürlich immer noch die klassische »Zu Fuß«-Methode. Dabei führt man die Zielanwendung Schritt für Schritt aus und erfasst den Zustand des Mikrocontrollers. Auf diese Weise lässt sich eine Trace-Datei erstellen. Diese Vorgehensweise dauert ihre Zeit, weshalb dieser Modus »Slow Run« genannt wird. Seit Version 9.12.7 unterstützt iSystem diese Methode in ihrer Entwicklungs- und Debugger-Software »winIDEA«.
Der Slow-Run-Modus analysiert die kompletten Programm- und Daten-Traces, ermittelt also, welche Instruktion mit welchen Daten ausgeführt wurde. Außerdem prüft das Tool die Code-Abdeckung und zeigt so auf, welche Codepfade durchlaufen wurden und ob »tote« Codepfade vorliegen. Eine Einschränkung gibt es beim Profiling. Das Werkzeug stellt zwar fest, wann welche Funktion ausgeführt wird, allerdings sind im Slow-Run-Modus keine Echtzeitangaben möglich.
Effektiv arbeitet das Entwicklungstool je nach benutzter Architektur zwischen 30 und 50 Befehlen pro Sekunde ab. Dieser Modus ist kein Ersatz für leistungsfähige MCUs mit Trace-Port und entsprechende Debugger, eröffnet jedoch jedem Entwickler den Zugang zu den internen Abläufen der kompletten Anwendung, wo ohne Slow-Run nur winzig kleine Ausschnitte sichtbar wären.
Wie langsam ist »slow«?
Jobangebote+ passend zum Thema
Die Voraussetzungen für den Slow-Run-Modus sind der Einsatz einer Debugger-Hardware von iSystem wie etwa »iC5000« oder »iC3000« und der zugehörigen Entwicklungsumgebung »winIDEA«. Auf Seite der MCU ist lediglich die Unterstützung von Run-Control-Debug wie »Single Step«-Modus oder »Run Until« notwendig. Es sei nun auf dem Evaluierungsboard »MPC5554« eine Standardanwendung implementiert.
Dieses Board stellt zwei Schnittstellen zur Verfügung, einerseits einen JTAG/OnCE-Port (14 Pins), andererseits ein Nexus-Class-3-Interface (38 Pins). Als Debug-Werkzeug finde der On-Chip-Debugger »iC5000« Verwendung.
Die JTAG/OnCE-Schnittstelle stellt nur Run-Control-Debug-Funktionen zur Verfügung wie beispielsweise 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 Nexus-Schnittstelle gibt es in unterschiedlichen Ausführungen. Klasse 3 bedeutet, dass ein Trace-Port zur Verfügung steht, der zusätzlich zu Run-Control-Debug Daten-Trace und Lesen/Schreiben von Speicherbereichen in Echtzeit ohne Stoppen der MCU ermöglicht.
Im Vergleich zur JTAG/OnCE-Schnittstelle (On-Chip-Emulation) ist die Datenübertragungsgeschwindigkeit bei Nexus etwa 15mal so hoch.
Nun soll der iC5000 Debug-Daten über die jeweilige Schnittstelle erfassen.
Wird er über die Nexus-Schnittstelle verbunden (Bild 1) und der Trace gestartet, so zeigt winIDEA, noch während die Anwendung läuft, den kompletten Programm- und Datenfluss an (Bild 2).
Die Datenerfassung erfolgt in Echtzeit, also ohne Stoppen oder Verlangsamen der MCU und ohne Beeinflussung des Verhaltens der Anwendung. Zusätzlich lassen sich der Eingang und die Reaktion auf externe Signale wie AUX erfassen.
Auf dieser Basis sind sowohl Profiling (wann, wie lange welche Funktion ausgeführt wird) als auch Abdeckungsanalyse (welcher Quelltext wird abgearbeitet, und was sind »tote« Codepfade) verfügbar.
Verbindet man den iC5000 hingegen über die JTAG-Schnittstelle (Bild 3) und startet den Trace, so ist der Trace leer (Bild 4), enthält also keine Information zur Programmausführung oder irgendwelche Daten.
Die einzige Debug-Möglichkeit ist die Analyse des Disassembly-Codes und der Registerinhalte während die Programmausführung manuell gestoppt wird, etwa über Breakpoints oder »Run Until«.
Nun kommt der Slow-Run-Modus über JTAG/OnCE zum Einsatz. Diese Betriebsart findet sich im Menüpunkt »Debug« in winIDEA.
Unmittelbar nach Starten des Trace erhält man den kompletten Programm- und Datenfluss, vergleichbar dem Trace über Nexus (Bild 5).
Allerdings dauert im Slow-Run-Modus die Anzeige der Trace-Daten deutlich länger durch die schrittweise Programmausführung und die Datenerfassung (siehe Tabelle 1).
Deutlich wird in diesem Zeitvergleich, woher »Slow Run« seinen Namen hat.
Die resultierende Trace-Datei erlaubt eine komplette Programm- und Datenanalyse einschließlich Profiling und Code-Coverage. Allerdings fehlen, wie bereits bemerkt, die Echtzeitaspekte in der Zeitmessung.
| 46 Instruktionen | »Step over« | |
|---|---|---|
| Nexus 3 |
9,87 µs + 171 KByte |
522,7 µs + 190 IKByte |
| Slow-Run |
2 s + 171 KByte |
85 s + 190 KByte |
Tabelle 1: Zeitvergleich und Größe der Trace-Datei zwischen Nexus 3 und JTAG mit Slow-Run. Links kamen auch Bibliotheksaufrufe zum Einsatz, der »Step over« rechts ging über eine Funktion mit 7038 Instruktionen
Einschränkungen von Slow-Run
Slow-Run eignet sich gut zum Trace kleinerer Bereiche der Applikation. Werden jedoch Bibliotheksfunktionen aufgerufen (siehe Tabelle 1), kann Slow-Run sehr lange dauern, da teilweise viel Code eingefügt wird. Wie das »Step over«-Beispiel in der Tabelle zeigt, braucht auch die Ausführung einer Funktion in dieser Betriebsart vergleichsweise lange.
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 ist das möglicherweise veränderte Verhalten der Anwendung.
Durch die schrittweise Abarbeitung der Applikation kann die Reaktion auf externe Signale wie Timer und Interrupts deutlich verspätet oder im schlimmsten Fall gar nicht erfolgen, wenn etwa ein Interrupt verloren geht.
Lesen Sie mehr zum Thema
