Worauf es in der Praxis ankommt
On-Chip-Infrastrukturen für Debugging und Test
Fortsetzung des Artikels von Teil 2
Komplette Debug-IP: ARM CoreSight
Eine komplette Debug-IP mit Breakpoints, Watchpoints (Breakpoints für Datenzugriffe), Lesen und Schreiben von Speicherinhalten während laufendem System, Trace und Cross-Triggering-Funktionalität etc. bietet ARM mit ihrem bereits an anderer Stelle erwähnten CoreSight (Bild 2).. Welche Funktionen aus dem CoreSight-Baukasten aber letztendlich im tatsächlichen Chip zu finden sind, hängt vom jeweiligen Halbleiterhersteller ab, der hier sehr frei konfigurieren kann. Hier spielen sicherlich Kundenanforderungen, ganz entscheidend aber auch die Kosten eine Rolle.
Jobangebote+ passend zum Thema
Gänzlich proprietär ist der bei den Infineon-eigenen Architekturen (TriCore, C16x und Nachfolger) zum Einsatz kommende OCDS (On-Chip Debug Support). Die Unterstützung für Breakpoints, Daten-Breakpoints (zumindest für die Datenadresse) und den Zugriff auf Speicher und Register zur Laufzeit sind auch hier selbstverständlich. Mit der AURIX-Familie ist zudem noch eine Art Cross-Trigger-Mechanismus hinzugekommen, der hier aber als OCDS Trigger Switch bezeichnet wird (Biild 3).
Es liegt in der Natur der Dinge, dass bei allen On-Chip-Debug-Systemen die Anzahl der verfügbaren Hardware-Breakpoints begrenzt ist. Diese sind letztlich nichts anderes als Adresskomparatoren für Code- und gegebenenfalls auch für Datenadressen. Signalisiert einer der Komparatoren einen Treffer, so wird eine oftmals konfigurierbare Debug-Aktion, beispielsweise, ein HALT-Signal ausgelöst. Der Debugger verbirgt die Konfiguration der Komparatoren und bietet dem Anwender einen Breakpoint zur Benutzung an. Sind alle Hardware-Breakpoints bereits verwendet, muss auf Software-Breakpoints zurückgegriffen werden. Diese basieren im Grunde darauf, dass die Instruktion an der gewünschten Breakpoint-Position durch eine spezielle Breakpoint-Instruktion oder manchmal auch durch eine illegale Instruktion temporär ersetzt wird. Ein bei der Ausführung dieser Instruktion ausgelöster Trap kann der Debugger abfangen, den Code-Patch rückgängig machen und dem Benutzer das System, stehend am Breakpoint, anbieten. Das funktioniert aber nur, wenn der Code aus dem RAM heraus ausgeführt wird, denn nur dort ist ein Code-Patch leicht durchführbar. Für FLASH-lokatierte Applikationen ist der Aufwand dafür ungleich höher. Dort muss ich der Entwickler dann mit den tatsächlich verfügbaren Hardware-Breakpoints begnügen.
Alles Synchron – Run-Control für Multicore
Mit dem Einzug von Multicore in eingebettete Systeme ging natürlich auch der Bedarf an erweiterten Debug-Funktionen einher. Insbesondere das Run-Control – Anhalten, Steppen, Loslaufen – verdient hier besonderes Augenmerk. Abhängig von der Applikation, müssen mehrere Kerne miteinander synchronisiert werden, damit z.B. ein gleichzeitiges Anhalten am Breakpoint möglich ist. Aufgrund der großen Unterschiede zwischen den Taktfrequenzen der Kerne und der Geschwindigkeit der Debug-Schnittstellen ist eine externe Synchronisierung durch den Debugger nicht zielführend. Die Signalisierung, dass beispielsweise alle Kerne gleichzeitig anhalten sollen, muss direkt auf dem Chip erfolgen. Dafür ist das bereits im vorherigen Abschnitt erwähnte Cross-Triggering zuständig. Aufgrund von Signallaufzeiten, unterschiedlichen Taktfrequenzen und -domänen der einzelnen Kerne und auch der Pipelines können Latenzen jedoch nie ausgeschlossen werden. So ist ein Anhalten, Single-Stepping oder wieder loslaufen lassen mehrerer Kerne nur quasi-synchron, wobei der „Schlupf“ mit wenigen Takten bzw. Instruktionszyklen gering ist.
Hier muss allerdings erwähnt werden, dass das Cross-Triggering für das Run-Control bei CoreSight und in bestimmten Nexus-Konstellationen mit dem Trace konkurriert. So nutzt CoreSight für das Triggering von HALT-Signalen und Trace-Aufzeichnungen die gleiche Cross-Trigger-Matrix. Man muss also damit rechnen, dass eine Trace-Aufzeichnung und das gleichzeitige Debuggen mit Breakpoints nur eingeschränkt möglich ist.
- On-Chip-Infrastrukturen für Debugging und Test
- Funktionale Schnittstellen – die bessere Lösung?
- Komplette Debug-IP: ARM CoreSight
- Spurensuche – Systembeobachtung durch Trace
Lesen Sie mehr zum Thema
Das könnte Sie auch interessieren
Systemdesign / Debug & Trace
Universalwerkbank für Mikrocontroller
DESIGN&ELEKTRONIK TechTalk
MCUs werden immer komplexer, was tun?
Debugging für Profis
Branch Coverage für optimierten Code
