Erweiterte Debug-Möglichkeiten bei ARM-Prozessoren mit Standard-Debug-Interface

ARM-Debugging – mit den On-Chip-Ressourcen leben

5. Oktober 2006, 10:22 Uhr | Dr.-Ing. Peter Sauer

Die Debug-Funktionen, die die ARM-Architektur von Hause aus mitbringt, weisen – verglichen mit anderen Architekturen – Limitierungen in Bezug auf Breakpoint-Einsatz und CPU-Zugriff auf. Außerdem erfolgt der Zugriff auf den ARM-Prozessor über die für andere Zwecke entwickelte JTAG-Schnittstelle, was weitere Einschränkungen mit sich bringt. Auf Seiten der Tool-Hersteller wurden mittlerweile Lösungen erarbeitet, diese Beschränkungen aufzuheben und die Funktionalität der Tools an die von den Emulatoren her bekannten Eigenschaften heranzuführen.

Erweiterte Debug-Möglichkeiten bei ARM-Prozessoren mit Standard-Debug-Interface

In Bild 1 ist ein typisches Beispiel für einen solchen Mikrocontroller mit ARM7TDMI-Prozessor gezeigt, wie er z.Zt. von einigen Herstellern (Philips, Atmel, STMicroelectronics, OKI etc.) als typisches Derivat einer Produktfamilie angeboten wird. Für den Zugriff auf die Adress- und Datenbusse der ARM-CPU und das Embedded-ICE-Modul [1] wird die JTAG-Schnittstelle mit drei zusätzlichen Scan-Chains erweitert. Über das Embedded-ICE-Modul werden der Zustand der CPU (Debug-Modus versus Normal-Modus) gesteuert und der Vergleich des Adress- und Datenbusses mit Breakpoint- bzw. Watchpoint-Registern durchgeführt.

Der Datentransfer zwischen Debug-Tool und JTAG-Schnittstelle erfolgt seriell durch Laden und Auslesen der Scan-Chains. Zur Optimierung des Zugriffs ist dabei die Scan-Chain 0 mit einem Abgriff für den Datenbus versehen, womit schneller auf den Datenbus zugegriffen werden kann, ohne den Adressbus bedienen zu müssen (Bild 2). Das Embedded-ICE-Modul enthält zwei Watchpoint-Register, die sich kombinieren lassen und die ARM-CPU dazu bringen können, eine Auswahl von Debug-Befehlen auszuführen. Die üblichen Debug-Funktionen für „Run“, „Halt“, „Singlestep“ und „Breakpoint“ lassen sich damit verwirklichen. Weiterhin können Programme und Daten in Speicherbereiche geladen und interner bzw. externer Flash-Speicher programmiert werden. Der Zugriff auf den Speicher erfolgt durch Einfügen von Instruktionen über die Scan-Chains, die dann entweder mit dem CPU-Takt oder mit einem, über den TAP-Controller einstellbaren Debug-Takt ausgeführt werden.

Die JTAG-Schnittstelle wird mit einem eigenen externen Takt versorgt und arbeitet damit asynchron und unabhängig zum CPU-Takt. Weiterhin wird üblicherweise das Reset-Signal des Systems vom Reset-Signal der JTAG-Schnittstelle getrennt. Das Startup-Verhalten eines Programms beim Reset lässt sich damit untersuchen, ohne dass die Debug-Einstellungen verlorengehen. Die zwei Watchpoint-Register erlauben zusammen mit den Adress- und Datenkomparatoren eine Überwachung der Speicherzugriffe mit den folgenden Einstellmöglichkeiten:

Ein Watchpoint auf einen Programm-Code-Bereich stellt einen (Hardware-)Breakpoint dar, der den Programmablauf anhält und die CPU in den Debug-Modus schaltet. Der Programmablauf wird dabei vor der auszuführenden Instruktion angehalten.
Ein Watchpoint auf einen Datenbereich hält den Programmablauf nach dem Zugriff auf das Datum an.
Ein (Software-)Breakpoint ersetzt die Programminstruktion durch einen „Undefined Instruction“-Opcode und setzt einen (Hardware-)Breakpoint auf die Interrupt-Adresse für „Undefined Instructions“. Die erlaubt das Setzen einer unbegrenzten Anzahl von (Software-)Breakpoints. Beim Auftreten des „Undefined Instruction“-Breakpoints muss jedoch die Programmadresse des (Software-)Breakpoints identifiziert werden.
Verknüpft man die zwei Watchpoint-Register, wie in Bild 3 dargestellt, so kann auch ein Programmbereich überwacht werden. Dazu wird eine Watchpoint-Maske definiert, die keinen Haltebefehl auslöst (WP1) und eine Maske mit überlappendem Adressbereich (WP0), die einen Haltebefehl auslöst. Damit sind allerdings beide Register belegt und es können keine weiteren Breakpoints definiert werden.