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.
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.
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: