Startseite > Embedded > Hardware > Eine unterschätzte Debugging-Technik

Hardware-Tracing

Eine unterschätzte Debugging-Technik

3. November 2021, 8:30 Uhr | Von Felix Martin

▶ Diesen Artikel anhören

Fortsetzung des Artikels von Teil 2

Resets auf der Spur

Das zweite Beispiel macht die Vorteile von Trace deutlich. Das Debuggen eines Embedded-Systems ist besonders schwierig, wenn dem Entwickler der Kontext fehlt, was die Anwendung vor dem Fehler getan hat. Passieren kann das, wenn der Stack beschädigt ist, oder wenn, wie in diesem Beispiel, die Anwendung aus unbekannten Gründen neu startet.

Auf den ersten Blick läuft die Anwendung – Vector MICROSAR – mit einem Infineon Aurix-TC399XE-Mikrocontroller auf einem iSystem Evaluierungsboard – einwandfrei, jedoch vermutet der Entwickler, dass es sporadische Resets gibt. Um den Verdacht zu bestätigen, setzt der Anwender einen Haltepunkt am Startsymbol innerhalb von winIDEA. Tatsächlich bleibt die Anwendung nach ein paar Augenblicken an der Reset-Vektor-Adresse stehen. Der Call-Stack ist nach einem Reset leer und deshalb nicht hilfreich für die Ursachensuche. Wie ebenfalls das Register der Reset Control Unit (RCU) bestätigen würde, handelt es sich um einen Applikations-Reset, dessen Ursache mit interaktivem Debugging lediglich schwer zu finden wäre. Hier hilft wiederum Tracing.

Jobangebote+ passend zum Thema

MACNICA ATD EUROPE - Ihre berufliche Zukunft

MACNICA ATD Europe GmbH, Ingolstadt

Alle Jobangebote im Elektroniknet Karrierebereich anzeigen

Auf dem Aurix-MCU ist es möglich, eine Technik namens »Post-Mortem-Debugging« zu verwenden. Hier wird die Trace-Einheit angewiesen, im Emulationsspeicher im Rundlauf-Verfahren aufzuzeichnen. Erst wenn die Anwendung einen bestimmten Trigger erreicht, stoppt das Aufzeichnen und der Debugger liest die Daten aus. Es ist sogar möglich, die Konfiguration so zu gestalten, dass Anwender die Daten sowohl vor als auch nach dem betreffenden Ereignis aufzeichnen können (Bild 4).

Standardmäßig sortiert der Profiler die Code- und Task-Objekte in alphabetischer Reihenfolge, jedoch erlaubt eine nützliche Funktion innerhalb von winIDEA ein Sortieren der Objekte nach Eintritts- oder Austrittszeiten und macht somit das Verhalten nach dem Reset sichtbar. Mit Hilfe des Cursors kann der Anwender die ausgeführten Anweisungen im Trace-Fenster synchron mit der Profiler-Zeitleiste und den Trace-Ereignisse anzeigen lassen. In dem beschriebenen Beispiel löst, wie erwartet, die Anwendung selbst den Reset aus. Mit einem Zurückgehen in der Zeit kann der Entwickler sehen, dass der Reset entweder auftritt, wenn ein bestimmtes Signal auf Eins gesetzt wird, oder wenn eine CAN-Nachricht mit einer bestimmten Nutzlast eintrifft. In dem konkreten Fall scheint letzteres der Fall zu sein, was die Funktion »CAN Receive Signal« anzeigt, die vor dem Runnable lief. Mithilfe von Hardware-Tracing konnte der Anwender hier also die Fehlersuche für ein Problem, das sonst sehr schwierig zu finden gewesen wäre, in kurzer Zeit abschließen.

Fehler schnell finden

Das Debuggen einer Embedded-Anwendung ist nicht nur zeitaufwendig, sondern mit Standardmethoden, die beim Testen das Echtzeitverhalten stören, auch oftmals sehr schwer. Hardware-Tracing unterstützt den Entwickler beim Auffinden von Fehlern, deren Ursachenklärung mit anderen Techniken sehr herausfordernd gewesen wäre. Speziell für das Hardware-Tracing sind zwar zusätzliche Hardware und entsprechende Tools erforderlich – das zahlt sich jedoch durch schnelle Debugging-Ergebnisse vollkommen aus. Möglich ist das dank tiefgreifender Erkenntnisse über die Anwendungsausführung.