Neue Debug-Schnittstellen: weniger Leitungen, mehr Information

8. Dezember 2009, 13:31 Uhr |
Diesen Artikel anhören

Fortsetzung des Artikels von Teil 2

Neue Debug-Schnittstellen: weniger Leitungen, mehr Information

Aus Sicherheitsgründen ist die Debug-Schnittstelle bei den bisherigen Implementierungen im Standardfall nach einem Power-On-Reset abgeschaltet. Ein Einschalten ist durch eine entsprechende Reset-Beschaltung oder auch durch die Startup-Software möglich. Die gewünschte Reset-Beschaltung kann auf dem Target selbst oder auf dem Debug-Steckverbinder ausgeführt werden. Die Auswahl des gewünschten Debug-Modes (2-Pin-DAP, 3-Pin-DAP, JTAG) ist über die Pins durch das Debug-Werkzeug und auch wieder durch die Startup-Software möglich.

Die maximale DAP-Taktrate kann bis zu 80 MHz betragen. Damit sind trotz verringerter Leitungszahl mindestens die gleichen Übertragungsleistungen wie beim klassischen JTAG möglich. Die DAP-Schnittstelle hat zudem eine geringe Latenz im Mikrosekunden-Bereich. Und die Kommunikation ist sehr robust. Das wird durch eine im Protokoll integrierte, 6 bit breite Check-Summe (CRC) erreicht. Außerdem ist das Protokoll so aufgebaut, das z.B. ein Schreibbefehl vom Host zum Target rückbestätigt wird. Unverhoffte Änderungen im Target-Zustand oder Störungen in der Übertragung können vom Tool also sicher erkannt werden.

passend zum Thema

DAP und JTAG sind Schnittstellen zum On-Chip-Debug-System (OCDS), wobei dessen Funktionalität über beide Ports voll nutzbar ist. So kann beispielsweise auf den Speicher auch während der Laufzeit uneingeschränkt lesend und schreibend zugegriffen werden. Das erlaubt eine periodische Aufzeichnung von Applikationsdaten oder des Instruction-Pointers zur Laufzeit. Die implementierte Debug-Logik kann außerdem Code- und Daten-Breakpoints mit komplexen Triggerbedingungen erzeugen. Für Code- und Daten-Trace können spezielle „Emulation Devices“ eingesetzt werden, die sich hinsichtlich Platzbedarf und Funktionsumfang nicht vom Serienbaustein unterscheiden, aber zusätzliche Emulationslogik auf dem Chip enthalten. In Kombination mit speziellen Tools wie zum Beispiel dem Universal Emulation Configurator von pls sind mit diesen Emulation Devices auch komplexere Messungen wie Performance-Analyse, Profiling und Code-Coverage durchführbar.

Serial Wire Debug (SWD)

Einen interessanten Weg hat auch ARM mit der Serial-Wire-Debug-Schnittstelle beschritten. SWD ist Teil eines ganzen Pakets neuer Debug- und Trace-Techniken, die unter dem Oberbegriff „CoreSight“ zusammengefasst werden. Erste Implementierungen gibt es bereits in den Stellaris-Bausteinen mit Cortex-M3-Kern von Luminary Micro, jetzt Texas Instruments, und in der STM32-Familie von STMicroelectronics. Jedoch kann die CoreSight-IP auch in allen anderen ARM- und Cortex-Cores verwendet werden. Eine weitere Verbreitung ist schon aufgrund der vielfältigen Vorteile sehr wahrscheinlich.

Neben dem klassischen JTAG-Port, der auch hier alternativ weiter zur Verfügung steht, bietet der Serial-Wire-Modus ein Zwei-Pin-Debug-Interface. Die von ARM eingeführte strikte Trennung von Debug Port, wahlweise JTAG oder SWD, und dem eigentlichen Access Port, also dem Zugriff auf OnChip-Debug-Hardware, ermöglicht einen einfachen Austausch unter Beibehaltung sämtlicher Funktionen. Eine Besonderheit ist der kombinierte „Serial Wire JTAG Debug Port“ (SWJ-DP), der beide Schnittstellen über Pin-Multiplexing vereint. Im Serial-Wire-Modus fungiert TCK als Taktleitung, und über TMS werden bidirektional Daten ausgetauscht. Die Umschaltung erfolgt über definierte TMS-Sequenzen.

Sofern ein SWJ-DP durch den Mikrocontroller-Hersteller implementiert wird, kann das TDO-Signal zur Ausgabe von unterschiedlichen Trace-Ereignissen über einen einzigen Pin genutzt werden, was sich wiederum in minimalen Chip-Kosten niederschlägt.

Über den sog. Serial Wire Viewer (SWV) lassen sich unter anderem Instrumentierungs-Trace („printf“-Debugging), Watchpoint Trace, Instruction Pointer Trace (Bild 3) und Event Trace (Interrupt) darstellen, wobei man diese Art des Low Cost Trace hauptsächlich bei Mikrocontrollern auf Cortex-M-Basis vorfindet.

Die maximal mögliche Geschwindigkeit der SWD-Schnittstelle ist unabhängig vom verwendeten Core-Takt und praktisch nur durch die zugrundeliegende Technologie begrenzt. Die integrierte Paritätsprüfung der Telegramme garantiert eine sichere Übertragung. Ein zusätzliches, im SWD-Protokoll enthaltenes Acknowledge-Feld (ACK) sichert die korrekte Ausführung der Befehle zu.

9180203_af.jpg
Bild 3. Auf Instruction Pointer Trace basierendes Funktionen-Profiling zeigt, welche Funktion wieviel CPU-Zeit in Anspruch genommen hat.

  1. Neue Debug-Schnittstellen: weniger Leitungen, mehr Information
  2. Neue Debug-Schnittstellen: weniger Leitungen, mehr Information
  3. Neue Debug-Schnittstellen: weniger Leitungen, mehr Information
  4. Neue Debug-Schnittstellen: weniger Leitungen, mehr Information

Jetzt kostenfreie Newsletter bestellen!