Software-Entwicklung
Software zum Laufen bringen
Fortsetzung des Artikels von Teil 1
Hardware-Debugger: Blick in den Chip
Hardware-Debugger wurden bereits erwähnt, etwa von Keil oder IAR, aber es gibt auch Hersteller, die sich auf das Hardware-Debugging spezialisiert haben. Ein Problem der Cross-Entwicklung ist, dass das Zielsystem während des Entwicklungsvorgangs so manipuliert werden muss, dass man nachvollziehen kann, was sich darin tut, um herauszubekommen, warum ein Programm nicht abläuft wie erwartet. Die meisten Mikrocontroller haben zu diesem Zweck Debug-Funktionseinheiten integriert.
ARM bietet den Chipdesignern z.B. verschiedene Funktionsblöcke an, von einfachen Einheiten, mit denen sich das Programm starten und stoppen lässt, bis hin zu kleinen Trace-Speichern, die den Programmablauf aufzeichnen und über bestimmte Pins ausgelesen werden können.
Das On-Chip-Debugging ist ein unverzichtbarer Bestandteil heutiger Software-Entwicklung, greift aber - wenn auch nur vergleichsweise wenig - in den Programmablauf ein. So muss etwa der Chip angehalten werden, damit Werte aus Registern ausgelesen werden können oder der Trace-Speicher ausgelesen werden kann oder es müssen zusätzlich kleine Monitor-Programme installiert werden, die Debug-Informationen sammeln und nach außen geben. Ob man damit sporadische oder Timing-Fehler findet, die nur bei voller und ununterbrochener Ablaufgeschwindigkeit auftreten, ist mehr oder weniger Zufall.
Mit einem Hardware-Debugger macht man sich noch unabhängiger und kann das Programm auf dem Zielsystem tatsächlich völlig unbeeinflusst ablaufen lassen. Die Hardware-Debugger haben eigene Prozessoren an Bord, um Trigger auszulösen und Daten aus dem Zielsystem auszulesen. Und sie haben einen größeren Trace-Speicher, der die Aufzeichnung des Programmablaufs über einen längeren Zeitraum erlaubt.
Lauterbachs TRACE32 ist ein modulares System aus Hardware und Software. Der Entwickler arbeitet mit der grafischen Oberfläche des TRACE32-Tools PowerView und die Verbindung zur Ziel-Hardware stellt ein Debug-Adapter her, der einen eigenen Mikroprozessor und einen Erweiterungsbus hat. Mit entsprechenden Zusatzgeräten sind Logikanalyse, Timinganalyse, Simulation, Programmierung von Zielsystem-Flash, Generierung von Signalmustern und Stimuli oder auch die Analyse von Kommunikationsprotokollen u.v.a.m. möglich. Gesteuert wird der gesamte Entwicklungsvorgang durch den Debugger PowerView. Über ihn kann das Zielsystem gestartet und gestoppt werden, Befehls- und Daten-Trace ausgelesen werden, Speicher- und Registerinhalte live zur Laufzeit betrachtet werden usw.
Jobangebote+ passend zum Thema
Auch das Verhalten der auf dem Chip integrierten Peripherie kann mit diesen Werkzeugen durchleuchtet werden. Da PowerView viele Betriebssysteme kennt, ist das Debugging RTOS-aware, d.h. es können z.B. Tasks für das Debugging ausgewählt oder die Stack-Belegung analysiert werden, Systemaufrufe können manuell gestartet werden usw.
Im Fall der neuen TriCore-Familie AURIX TC27X nutzt TRACE32 den AGBT Trace Port dieser Chips mit dem Aurora-Protokoll (Bild 3). Die Trace-Aufzeichnungsgeschwindigkeit beim TC27X beträgt 2,5 Gbit/s. Jedes Sample wird mit einem Timestamp versehen, mit dem statistische Auswertungen während der Laufzeit ohne Instrumentierung des Codes möglich ist. Der -TRACE32-Debugger unterstützt auch das General Timer Module (GTM) des AURIX.
Dieses Add-on wird in einer separaten Instanz der TRACE32-Software dargestellt und enthält auch einen Echtzeit-Trace des GTM. Weiterhin ist mit dem TRACE32 auch das Debugging des integrierten HSM (Hardware Security Module) des AURIX möglich. Das HSM erlaubt es Automotive-Entwicklern, die Sicherheitsanforderungen für einen besseren Schutz ihrer Applikation gegen Hacker-Angriffe zu erfüllen. Dies ist nur ein kleiner Ausschnitt aus dem Leistungsspektrum von TRACE32. Das Tool ist so komplex, dass eine komplette Aufzählung für alle Infineon-Architekturen den Rahmen sprengen würde.
Nicht viel anders hinsichtlich der Komplexität verhält es sich mit UDE von pls (Bild 4). Die Universal Debug Engine ist eine Entwicklungs-Software für das Debugging über die On-Chip-Hardware, die mit einem „Universal Access Device“ (UAD) erweitert werden kann. Auch mit UDE/UAD ist das Debugging der neuen TriCore-Bausteine „AURIX“ unter Nutzung des Aurora-Protokolls möglich. Damit kann der Trace-Speicher durch Anschluss externer Hardware drastisch vergrößert werden, wodurch die Bewältigung anspruchsvoller Trace-Aufgaben mit großen Datenmengen möglich wird, wie z.B. Code Coverage. Ein 2,5-GB/s-Aurora-Interface setzt allerdings eine entsprechend ausgelegte Hardware zur Signalaufnahme, Signalkonditionierung und Vorverarbeitung am Target voraus.
Mit der neuesten Generation 3+ des Universal Access Device stellt pls eine solche Hardware mit bis zu 4 GB Trace-Speicher zur Verfügung. Für jede CPU sind acht Hardware-Breakpoints für Programmadressen oder Datenzugriffe möglich. Jeder Core des TriCore kann getrennt gestoppt und gestartet werden. Über einen Trigger-Switch ist aber auch die Kontrolle mehrerer Cores oder des gesamten AURIX-Bausteins möglich. In der Universal Multi-Core Workbench von pls kann zielgerichtet ein bestimmter Teil des Bausteines als Debug Target ausgewählt werden. Für die feingranulare Steuerung der einzelnen Cores wurde im Werkzeug das Konzept der Run-Control-Gruppen umgesetzt. Ihre Definition erlaubt es, Cores für bestimmte Aspekte des Run-Control (Start/Stopp/Einzelschritt) quasi zusammenzuschalten, um mit Hilfe des auf dem Baustein integrierten Trigger-Switch eine nahezu synchrone Abarbeitung zu erreichen.
Für die XMC4500-Bausteine mit ihrem Cortex-M4-Kern bietet pls das UAD2 an, das auf die Debug-Ressourcen und Peripherie-Einheiten der ARM-Architektur abgestimmt ist. Während eines laufenden Programms ist ein Lesen und Schreiben des gesamten Hauptspeichers durch den Debugger ohne Einschränkung des Echtzeitverhaltens möglich. Das erlaubt die Animation von Variablen, Registern und Speicherinhalten während des Programmablaufs in der Universal Debug Engine. Darüber hinaus entsteht aus der periodischen Aufzeichnung des Befehlszählers ein „Profiling“ mit Darstellung des prozentualen Anteils von Funktionen an der Laufzeit der Applikation.
Als JTAG- und SWD-Debug-Interface (Serial Wire Debug) gibt es noch den J-Link von Segger für ARM-Chips, also auch für die XMC4000-Familie. Er wird über gängige Entwicklungsumgebungen wie IAR, Keil MDK u.a. angesprochen. Der J-Link ist ein Werkzeug zur Kommunikation mit der On-Chip-Debug-Infrastruktur von ARM- und anderen Controllern. Im J-Link läuft ein GDB-Server. mit dem ein GNU Debugger auf dem Entwicklungsrechner über TCP/IP kommunizieren kann. Über das serielle GDB-Fernzugriffsprotokoll lassen sich eine Reihe von Befehlen senden, die den Pro-gramm-ablauf steuern, elf/bin-Dateien öffnen, Speicher lesen oder schreiben.
- Software zum Laufen bringen
- Hardware-Debugger: Blick in den Chip
- Sicherheit einbauen
Lesen Sie mehr zum Thema
