Herzlich Willkommen beim beam-Verlag in Marburg, dem Fachverlag für anspruchsvolle Elektronik-Literatur.


Wir freuen uns, Sie auf unserem ePaper-Kiosk begrüßen zu können.

Aufrufe
vor 9 Jahren

11-2012

  • Text
  • Industrie
  • Einsatz
  • Sensoren
  • Anwendungen
  • Serie
  • Sensor
  • Halle
  • Bild
  • Stellen
  • Electronic
  • Programmierbare
Fachzeitschrift für Industrielle Automation, Mess-, Steuer- und Regeltechnik

Software/Tools/Kits

Software/Tools/Kits Trace-Information trotz MCU ohne Trace-Port iSYSTEMs Slow-Run-Modus sammelt Debug-Trace-Informationen auch bei MCUs ohne Trace-Port Bild 1: Testaufbau über Nexus 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 bietet folgende Features • 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 46 Instruktionen e.g. Bibliotheksaufruf für cast Operation: int i; float fRet; i = fRet Bild 2: Trace-Ergebnisse über Nexus 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. Die Voraussetzung 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 Betrachtet wird eine Standardanwendung auf einem iSYSTEM MPC5554 Evaluierungsboard. 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 Memorybereichen ohne Stoppen der MCU ermöglicht. Im Vergleich zur JTAG/OnCE Schnittstelle ist die Datenübertragungsgeschwindigkeit bei Nexus ca. 15 mal so hoch. Debugtest „Step over“ über eine Funktion mit 7038 Instruktionen Interface ohne Slow-Run mit Slow-Run ohne Slow-Run mit Slow-Run Nexus 3 9,87 µs + 171 Kb Tracedatei Tabelle 1: Zeitvergleich mit und ohne Slow-Run 2 s + 171 Kb Tracedatei 522,7 µs + 190 Kb Tracedatei 85 s + 190 Kb Tracedatei 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 (siehe Bild 2). 40 PC & Industrie 11/2012

Software/Tools/Kits Bild 3: Testaufbau über JTAG „Trace“ über JTAG/OnCE Bild 4: Trace-Ergebnisse über JTAG (ohne Slow-Run) Details zur JTAG/OnCE-Schnittstelle Die JTAG/OnCE-Schnittstelle (siehe Bild 3) 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. 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 Disassemblycodes und der Registerinhalte während die Programmausführung manuell gestoppt wird z.B. über Breakpoints oder „Run Until“ (siehe Bild 4). „Trace“ über JTAG/OnCE – in Slow-Run-Modus 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 (siehe Bild 5). Vergleich des Zeitverhaltens ohne und mit Slow-Run-Modus Wie im vorangegangenen Beispiel wird wieder eine Standardanwendung auf einem MPC5554 Demonstration-Board verwendet. Als Debugwerkzeug wird ein iSY- STEM iC5000 On-Chip Debugger eingesetzt. Jetzt wird das das Zeitverhalten über die Nexusschnittstelle mit und ohne Slow- Run-Modus betrachtet. Deutlich wird in diesem Zeitvergleich, woher “Slow-Run” seinen Namen hat. Einschränkungen von Slow-Run Bild 5: Trace-Ergebnisse über JTAG (mit 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ändertes 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. Der 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. • iSYSTEM AG www.isystem.com PC & Industrie 11/2012 41

hf-praxis

PC & Industrie

© beam-Verlag Dipl.-Ing. Reinhard Birchel