Drei aktuelle On-Chip-Trace-Verfahren im Vergleich Auf den Spuren der Fehler

Spurensuche – auf sie müssen sich Entwickler begeben, wenn sie die Ursache eines Software-Fehlers ergründen wollen. Zentrales Werkzeug bei der Entwicklung von Mikrocontroller-Software ist dabei die Trace-Aufzeichnung. Je nach Controller gibt es mehrere Verfahren, die sich im Markt etabliert haben. Vom grundsätzlichen Ansatz her ähnlich, unterscheiden sie sich aber in den Details.

Drei aktuelle On-Chip-Trace-Verfahren im Vergleich

Spurensuche – auf sie müssen sich Entwickler begeben, wenn sie die Ursache eines Software-Fehlers ergründen wollen. Zentrales Werkzeug bei der Entwicklung von Mikrocontroller-Software ist dabei die Trace-Aufzeichnung. Je nach Controller gibt es mehrere Verfahren, die sich im Markt etabliert haben. Vom grundsätzlichen Ansatz her ähnlich, unterscheiden sie sich aber in den Details.


Neben den traditionellen Debug-Methoden stehen in modernen Mikrocontroller-Systemen für Kfz-Steuergeräte zunehmend auch On-Chip-Trace-Verfahren zur Verfügung. Mit diesem Werkzeug können die internen Zustände des Systems beobachtet werden, ohne das Echtzeit-Verhalten kritisch zu beeinflussen. Allerdings sind die Ressourcen auf dem Chip sehr teuer und damit limitiert. Deshalb ist außerhalb des Cores ein vergleichsweise hoher Aufwand erforderlich. Drei wesentliche Verfahren des On-Chip-Debugging werden im Folgenden untersucht:

  • IEEE-ISTO 5001 Nexus als herstellerunabhängiger Standard,
  • die Embedded Trace Macrocell von ARM,
  • Infineons Multi-Core Debug Solution (MCDS).

Alle drei Konzepte bieten weitreichende Möglichkeiten zur Beobachtung des Systemverhaltens während der Laufzeit. Insbesondere sind dies:

  • Programm-Trace-Eigenschaften,
  • Daten-Trace-Eigenschaften,
  • Trace-Control (Trigger, Filter),
  • Trace-Speicher,
  • Bandbreite der Aufzeichnung,
  • Mechanismen gegen Overrun.

Wie funktioniert eigentlich On-Chip-Trace?

Für On-Chip-Trace integriert der Halbleiterhersteller die dafür notwendige Logik direkt auf dem Produktions-Chip. Die On-Chip-Trace-Einheiten erhalten einen direkten Zugang zu den Cores und den Systembussen des jeweiligen Mikrocontroller-Systems. Mit den derzeit auf dem Markt verfügbaren Lösungen ist neben dem Programm-Trace, also der Aufzeichnung des Programmablaufs, auch eine gleichzeitige Beobachtung der Kommunikation auf den Systembussen möglich. Damit lässt sich ein Daten-Trace realisieren, der neben den Hauptspeicheradressen auch die Daten selbst, die auf den Bussen übertragen werden, erfasst. Je nach Komplexität des jeweiligen On-Chip-Trace-Verfahrens können auch weitere Informationen zum Laufzeitverhalten des Systems wie die aktuelle Task-ID oder die jeweiligen Zugriffsmodi auf die Systembusse gesammelt werden

Die enge Kopplung der On-Chip-Trace-Hardware an die eigentlichen Chip-Komponenten und der damit verbundene direkte und schnelle Zugriff auf die aufzuzeichnenden Daten erlaubt eine Trace-Datenerfassung in Echtzeit, also zu jedem Prozessortakt. Damit sind jedoch große Mengen an Trace-Daten verbunden, die auf geeignete Art und Weise aufgezeichnet werden müssen.

Eine Möglichkeit besteht darin, die Daten direkt vom Chip herunter auf den Debug-Host zu übertragen. Um die erforderlichen Datenraten zu erreichen, wird aber ein zusätzlicher, breitbandiger Debug-Zugang (Trace-Kanal) benötigt. Das für Debug-Zwecke vorhandene JTAG-Interface ist hierfür nicht geeignet. Der einzig gangbare Weg ist deshalb die Implementierung eines On-Chip-Trace-Speichers direkt auf dem Die. Die Bandbreite, die dadurch für die Aufzeichnung zur Verfügung steht, ist um das Zehnfache höher.

Für die Übertragung der Trace-Daten zum Debug-Host ist danach prinzipiell auch ein schmalbandiger Debug-Kanal (z.B. JTAG-Interface) ausreichend, da mit dem Transfer gewartet werden kann, bis die Trace-Aufzeichnung beendet ist. Prinzipiell, wie gesagt. Voraussetzung dafür ist nämlich ein On-Chip-Trace-Speicher ausreichender Größe. Der ist jedoch ein bedeutender Kostenfaktor im Chip-Design. Zurzeit können deshalb kaum Speicherkapazitäten über 1 Mbyte erwartet werden.

Bleibt als Ausweg faktisch nur die Reduzierung der Trace-Daten noch vor der Übertragung bzw. On-Chip-Speicherung. Nur so ist es möglich, die Kosten für einen schnellen Trace-Kanal bzw. großen Trace-Speicher in einem vertretbaren Rahmen zu halten. Betrachtet man ausschließlich den Programm-Trace, ist so eine Reduktion relativ leicht möglich. Um den Programmablauf auf dem Debug-Host zu rekonstruieren, müssen lediglich Sprünge bzw. Unterbrechungen in der sequenziellen Verarbeitung des Befehlsstroms (Interrupts, Traps) aufgezeichnet werden. Die restlichen Informationen kann der Debugger aus dem geladenen Programm selbst ermitteln.