iSYSTEM unterstützt mit seiner Entwicklungs- und Debuggersoftware winIDEA (ab Version 9.12.7) den sogenannten Slow Run Modus. Slow Run erlaubt die Erfassung des kompletten Programmablaufs und Datentraces - auch wenn die MCU keinen Debug Trace Port besitzt!
Warum ist Slow Run Modus eine wichtige Neuerung?
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 (und auch später) Probleme auf, fehlt ohne Traceport die Möglichkeit, detaillierte Informationen über die Ausführung der Anwendung zur Laufzeit zu erhalten.
Hier hilft Slow Run Modus.
Slow Run Modus stellt zur Verfügung:
- 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
Wie funktioniert 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 ca. 30-50 Befehlen pro Sekunde - abhängig von der benutzten Architektur. Per Default ist "Slow Run" in winIDEA nicht aktiviert.
Voraussetzungen für Slow Run Modus
Die Voraussetzungen für Slow Run Modus ist der Einsatz einer iSYSTEM Debugger Hardware wie z.B. iC5000, iC3000 und der zugehörigen Entwicklungsumgebung winIDEA.
Auf Seite der MCU ist lediglich die Unterstützung von Run Control Debug wie z.B. "Single Step" Modus oder "Run Until" notwendig.
Vergleich von Tracemöglichkeiten ohne und mit Slow Run Modus
Betrachten wir eine Standardanwendung auf einem iSYSTEM MPC5554 Evaluierungs-board. Dieses Board stellt zwei Schnittstellen zur Verfügung, einerseits einen JTAG/OnCE Port (14 Pins), andererseits ein Nexus Class 3 Interface (38 Pins). Als Debugwerkzeug wird ein iSYSTEM iC5000 On-Chip Debugger eingesetzt.
Im Folgenden wird verglichen, welche Daten vom iC5000 über die jeweilige Schnittstelle erfasst werden können.
Trace über Nexus:
Details zur Nexus-Schnittstelle:
Die Nexus Schnittstelle 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 zur Verfügung steht, der zusätzlich zu Run Control Debug realtime Datentrace und realtime Lesen/Schreiben von Memoryberei-chen ohne Stoppen der MCU ermöglicht. Im Vergleich zur JTAG/OnCE Schnittstelle ist die Datenübertragungsgeschwindigkeit bei Nexus ca. 15mal so hoch.
Debugtest:
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, 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 (welcher Source Code wird abgearbeitet und was sind "tote" Codepfade) verfügbar.
"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/Stop 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. 15mal 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 Disassemblycodes und der Registerinhalte während die Programmausführung manuell gestoppt wird z.B. über Breakpoints oder "Run Until".
"Trace" über JTAG/OnCE - in 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 (in winIDEAs "Debug" Menu) 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 Demonstration Board. Als Debugwerkzeug wird ein iSYSTEM iC5000 On-Chip Debugger eingesetzt.
Wir betrachten das Zeitverhalten über die Nexusschnittstelle mit und ohne Slow Run Modus.
Deutlich wird in diesem Zeitvergleich, woher "Slow Run" seinen Namen hat.
Einschränkungen von Slow Run
Slow Run eignet sich gut zum Trace kleinerer Bereiche der Applikation.
Werden Bibliotheksfunktionen aufgerufen (siehe Tabelle oben), 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 (siehe Tabelle oben "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 von 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.
Zusammenfassung
Slow Run Modus ermöglicht das Debuggen und die Analyse des kompletten Programm- und Datenflusses inklusive Profiling und Code Coverage, auch wenn die MCU keinen Traceport zur Verfügung stellt.
Slow Run Modus ist kein Ersatz für leistungsfähige MCUs mit Traceport und entsprechende Debugger, aber öffnet jedem Entwickler den Zugang zu den internen Abläufen der kompletten Anwendung, wo ohne Slow Run Modus nur winzig kleine Ausschnitte sichtbar sind.
Warum ist Slow Run Modus eine wichtige Neuerung?
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 (und auch später) Probleme auf, fehlt ohne Traceport die Möglichkeit, detaillierte Informationen über die Ausführung der Anwendung zur Laufzeit zu erhalten.
Hier hilft Slow Run Modus.
Slow Run Modus stellt zur Verfügung:
- 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
Wie funktioniert 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 ca. 30-50 Befehlen pro Sekunde - abhängig von der benutzten Architektur. Per Default ist "Slow Run" in winIDEA nicht aktiviert.
Voraussetzungen für Slow Run Modus
Die Voraussetzungen für Slow Run Modus ist der Einsatz einer iSYSTEM Debugger Hardware wie z.B. iC5000, iC3000 und der zugehörigen Entwicklungsumgebung winIDEA.
Auf Seite der MCU ist lediglich die Unterstützung von Run Control Debug wie z.B. "Single Step" Modus oder "Run Until" notwendig.
Vergleich von Tracemöglichkeiten ohne und mit Slow Run Modus
Betrachten wir eine Standardanwendung auf einem iSYSTEM MPC5554 Evaluierungs-board. Dieses Board stellt zwei Schnittstellen zur Verfügung, einerseits einen JTAG/OnCE Port (14 Pins), andererseits ein Nexus Class 3 Interface (38 Pins). Als Debugwerkzeug wird ein iSYSTEM iC5000 On-Chip Debugger eingesetzt.
Im Folgenden wird verglichen, welche Daten vom iC5000 über die jeweilige Schnittstelle erfasst werden können.
Trace über Nexus:
Details zur Nexus-Schnittstelle:
Die Nexus Schnittstelle 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 zur Verfügung steht, der zusätzlich zu Run Control Debug realtime Datentrace und realtime Lesen/Schreiben von Memoryberei-chen ohne Stoppen der MCU ermöglicht. Im Vergleich zur JTAG/OnCE Schnittstelle ist die Datenübertragungsgeschwindigkeit bei Nexus ca. 15mal so hoch.
Debugtest:
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, 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 (welcher Source Code wird abgearbeitet und was sind "tote" Codepfade) verfügbar.
"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/Stop 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. 15mal 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 Disassemblycodes und der Registerinhalte während die Programmausführung manuell gestoppt wird z.B. über Breakpoints oder "Run Until".
"Trace" über JTAG/OnCE - in 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 (in winIDEAs "Debug" Menu) 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 Demonstration Board. Als Debugwerkzeug wird ein iSYSTEM iC5000 On-Chip Debugger eingesetzt.
Wir betrachten das Zeitverhalten über die Nexusschnittstelle mit und ohne Slow Run Modus.
Deutlich wird in diesem Zeitvergleich, woher "Slow Run" seinen Namen hat.
Einschränkungen von Slow Run
Slow Run eignet sich gut zum Trace kleinerer Bereiche der Applikation.
Werden Bibliotheksfunktionen aufgerufen (siehe Tabelle oben), 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 (siehe Tabelle oben "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 von 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.
Zusammenfassung
Slow Run Modus ermöglicht das Debuggen und die Analyse des kompletten Programm- und Datenflusses inklusive Profiling und Code Coverage, auch wenn die MCU keinen Traceport zur Verfügung stellt.
Slow Run Modus ist kein Ersatz für leistungsfähige MCUs mit Traceport und entsprechende Debugger, aber öffnet jedem Entwickler den Zugang zu den internen Abläufen der kompletten Anwendung, wo ohne Slow Run Modus nur winzig kleine Ausschnitte sichtbar sind.
