JTAG-Implementierung in Arm-Core-Geräten

In diesem Artikel erfahren Sie mehr über die Schnittstelle zwischen JTAG- und Arm-Core-Geräten, wobei dem Arm Debug Interface oder ADI besondere Aufmerksamkeit gewidmet wird.

Bisher haben wir uns in unserer Serie zu JTAG mit dem IEEE 1149.1-Standard beschäftigt, einschließlich des Test Access Port (TAP)-Controllers und der TAP-Zustandsmaschine. Dann haben wir die verschiedenen physischen Schnittstellen überprüft, die für die Arbeit mit JTAG verfügbar sind, einschließlich der gemeinsamen Pinbelegung für Steckverbinder und der auf dem Markt erhältlichen JTAG-Schnittstellen und Debug-Probes.

In diesem Artikel weichen wir leicht vom JTAG-Standard ab und schauen uns stattdessen an, wie JTAG in den allgegenwärtigen ARM-Core-Geräten implementiert ist.

Was ist Arm?

Arm bezieht sich auf eine Prozessorarchitektur, zusammen mit einer großen Menge an geistigem Eigentum in Bezug auf Mikroprozessor- und Mikrocontroller-Schnittstellen. Wo Verbraucher-PCs dazu neigen, x86-abgeleitete Prozessoren oder PowerPC oder MIPS zu verwenden, wird eingebettete Elektronik meistens mit Arm-Core-Prozessoren implementiert.

Der „Kern“ der Prozessoren wird an Hersteller wie ST Microelectronics oder NXP verteilt, und diese Hersteller fügen dann zusätzliche Peripheriefunktionen wie I2C- und SPI-Schnittstellen, ADCs und DACs, USB-Schnittstellen usw. hinzu.

ARM-Architekturen werden als ARMv versioniert, Beispiele sind ARMv2 (von 1987), ARMv6 (Prozessoren, die 2002-2005 produziert wurden) und so weiter, und die Prozessorkerne, die diese Architekturen verwenden, werden als ARMx-Serie (ARM1, ARM6, ARM7) bezeichnet und neuerdings als ARM Cortex-A/R/M-Serie für Hochleistungs- (Cortex-A), Echtzeit- (Cortex-R) und Mikrocontroller- (Cortex-M) Anwendungen. Die Architekturversionierung folgt der Cortex-Suffixbenennung und wird zu Versionen wie ARMv6-M, ARMv7-R, ARMv7-A.

Die Debugging-Schnittstelle von Arm trägt den Namen Arm CoreSight Architecture; dazu gehören die Debug-Schnittstelle (Arm Debug Interface, ADI), eingebettete Trace-Makrozellen (ETM), serielle Hochgeschwindigkeits-Trace-Ports (HSSTP) und die CoreSight-Programmfluss-Trace-Architektur. Der ADI bildet die Basis für Debugging-Operationen mit Arm-Core-Prozessoren, und ein Teil dieses Standards umfasst eine JTAG-Schnittstelle sowie die Serial Wire Debug (SWD)-Alternative. Das Thema dieses Artikels ist die ADI und insbesondere die Hardware-Schnittstellenschichten.

Einführung in das Arm Debug Interface (ADI)

Das Arm Debug Interface (ADI) ist eine Spezifikation sowohl der Hardwareschnittstelle als auch der logischen Schnittstelle zum Debuggen zwischen einem Host und einem oder mehreren Geräten. Derzeit implementieren die meisten Prozessoren ADIv5 (spezifiziert in Arm IHI0031E), während der neuere ADIv6 (siehe Arm IHI0074C) langsam eingeführt wird. Da er beliebter ist, konzentrieren wir uns hier auf den ADIv5-Standard.

Der ADI definiert einen Debug-Access-Port (DAP), der aus einem Debug-Port (DP) und Access-Ports (APs) besteht. Der DAP ist die primäre „Einheit“ der Debug-Schnittstelle. Ein bestimmtes Gerät verfügt über einen Debug-Port, der die physische Verbindung mit einem Debugger verarbeitet, sowie über eine Reihe von Zugriffsports, die den Zugriff auf Systemressourcen wie Debug-Register, Trace-Port-Register, eine ROM-Tabelle oder den Systemspeicher ermöglichen. Somit enthält der DP die physikalische Verbindung (JTAG, SWD) sowie einige eingebaute Register, und jeder AP hat seine Verbindungen zum System und eine Reihe seiner eigenen Register.

In ADIv5 gibt es zwei Arten von Debug-Ports und (im Großen und Ganzen) drei Arten von Zugriffsports. Die DPs können entweder JTAG-DPs oder SWD-DPs sein, benannt nach der Schnittstelle, die für die Verbindung mit dem DAP von außerhalb des Geräts verwendet wird. Bei den APs kann es sich um MEM-APs handeln, die Zugriff auf Ressourcen durch Adressierung (analog zur Speicherzuordnung, daher der Name), JTAG-APs, die die Verbindung von JTAG-Scanketten mit der gesamten Debug-Einheit (dem DAP) ermöglichen, und herstellerspezifisch APs, die nicht von Arm spezifiziert werden. MEM-APs sind bei weitem die gebräuchlichsten und nützlichsten, daher werden wir die anderen Typen hier nicht behandeln.

Im Kontext von JTAG würden wir erwarten, dass die Debug-Schnittstelle JTAG-Befehlscodes sowie herstellerspezifische JTAG-Funktionen bereitstellt. Tatsächlich bietet der ADIv5-Standard die folgenden Anweisungen:

• EXTEST (0b00000000)
• MUSTER (0b00000001)
• VORLADEN (0b00000010)
• INTEST (0b000000100)
• KLEMME (0b00000101)
• HIGHZ (0b00000110)
• ABBRUCH (0b11111000)
• DPACC (0b11111010)
• APACC (0b11111011)
• IDCODE (0b11111110)
• BYPASS (0b1111111)

Außerdem umfassen die JTAG-Datenregister:

• ABORT (35 Bits), registrieren, um einen Abbruch des Access Ports zu erzwingen
• DPACC (35 Bits), Debug-Port-Lese-/Schreibzugriffsregister
• APACC (35 Bits), Zugriffs-Port-Lese-/Schreibzugriffsregister
• IDCODE (32 Bit)
• BYPASS (1 Bit)

Hervorzuheben sind hier die Befehle DPACC und APACC sowie die dazugehörigen Datenregister. DPACC (Debug Port Access) und APACC (Access Port Access) sind die Anweisungen/Register, die verwendet werden, um Befehle an die zugehörigen DPs und APs eines Geräts weiterzuleiten. Durch Einstellen unterschiedlicher Werte in den DPACC- oder APACC-Datenregistern kann der Debugger verschiedene Operationen ausführen, wobei er im Allgemeinen mit den Registern der DPs und APs selbst interagiert. Beachten Sie den Unterschied zwischen diesen DPACC- und APACC-Registern (JTAG-Registern) und den in die DPs und APs eingebauten Registern.

Die allgemeine Methodik hier ist, dass der Debugger die JTAG- oder SWD-Schnittstelle verwendet, um Befehle auszuführen, indem er die TAP-Zustandsmaschine durchläuft, dann nehmen die Befehle die Daten und laden sie in den DP oder einen AP, und je nach Daten, verschiedene Register innerhalb auf den DP oder AP zugegriffen wird, wodurch die gewünschte Verbindung zum System bereitgestellt wird.

Was sind also die DP- und AP-Register? Die verfügbaren DP-Register umfassen:

• CTRL/STAT, wird verwendet, um Statusinformationen über den DP zu steuern und zu erhalten
• DLCR, Data Link Control Register, steuert den Betriebsmodus des Data Link
• DLPIDR, Data Link Protocol Identification Register, Protokollversionsinformationen
• DPIDR, Debug-Port-Identifikationsregister, Debug-Port-Informationen
• EVENTSTAT, Ereignisstatusregister, das vom System verwendet wird, um dem externen Debugger ein Ereignis zu melden
• RDBUFF, Lesepufferregister, stellt eine Leseoperation bereit; abhängig von DP (JTAG oder SWD)
• SELECT, AP Select Register, wählt einen Zugangsport und die aktiven Registerbänke mit diesem AP aus; wählt die DP-Adressbank aus
• TARGETID, liefert Informationen über das Ziel, wenn der Host mit einem einzelnen Gerät verbunden ist

Während MEM-AP-Register sind:

• Steuer-/Statuswortregister (CSW, 0x00), enthält Steuer- und Statusinformationen
• Transfer Address Register (TAR, 0x04), enthält die Adresse für den nächsten Zugriff auf das Speichersystem oder die Systemressource
• Data Read/Write Register (DRW, 0x0C), setzt das Lesen oder Schreiben der Adresse im TAR – wenn Sie DRW lesen, wird der Zugriff auf Lesen gesetzt; Wenn Sie auf DRW schreiben, wird der Zugriff auf Schreiben gesetzt
• Banked Data-Register (BD0 bis BD3, 0x10, 0x14, 0x18, 0x1C), bieten direkten Lese- oder Schreibzugriff auf vier 32-Bit-Speicherblöcke, beginnend bei der Adresse in TAR
• Konfigurationsregister (CFG, 0xF4), Informationen zur MEM-AP-Konfiguration
• Debase-Basisadressenregister (BASE, 0xF8), Zeiger auf das Speichersystem, entweder der Anfang eines Satzes von Debug-Registern oder der Anfang einer ROM-Tabelle
• Identifikationsregister (IDR, 0xFC), identifiziert den MEM-AP.

Die Anschlüsse sind in Abbildung 1 unten schematisch dargestellt.

Abbildung 1. Arm Debug Interface-Diagramm, das die Verbindungen zusammenfasst. Hinweis:Für DPs und APs werden nicht alle Register angezeigt.

Einzelheiten zu den DP/AP-Registern und der Speicherzuordnung sind in der Spezifikation IHI 0031E zu finden. Anstatt weiter auf die Details einzugehen, möchte ich mich auf die andere Art von Debug-Port, den SWD-DP, konzentrieren und darauf, wie er JTAG mit nur zwei Drähten implementiert.

Serial Wire Debug (SWD)

Während JTAG-DP ein gängiges und bekanntes Beispiel für eine Debugging-Schnittstelle ist, ist für unsere Diskussion am relevantesten die JTAG-Alternative, die für Arm-Geräte definiert ist, das Arm Serial Wire Debug (SWD). SWD wurde als Zweidraht-Schnittstelle für Arm-Core-Geräte mit begrenzter Pinanzahl entwickelt. Da Mikrocontroller dazu neigen, in Peripheriegeräten ziemlich dicht zu sein, implementieren die meisten Cortex-M-Geräte SWD anstelle von vollständigem JTAG, um Pinplatz zu sparen. Wie funktioniert dieses Protokoll?

SWD ist in der ADIv5-Spezifikation (Kapitel B4) spezifiziert. Die TDI- und TDO-Pins von JTAG werden durch einen einzigen bidirektionalen Pin namens SWDIO ersetzt; der Testmodusauswahl-(TMS)-Pin wird vollständig entfernt; und die Uhr (TCK) bleibt gleich (umbenannt in CLK oder SWCLK). Somit verwendet SWD nur zwei Pins im Vergleich zu den vier Pins, die in JTAG verwendet werden. Damit dies funktioniert, verlässt sich SWD auf die sich wiederholende Natur von JTAG-Operationen:Die Zustandsmaschine wird manipuliert, Daten werden ein- oder ausgeschoben und der Prozess wiederholt sich. Der Unterschied zu SWD besteht darin, dass es keine Zustandsmaschine gibt. Stattdessen werden Befehle seriell über SWDIO ausgegeben und dann wird der gleiche Pin zum Lesen oder Schreiben von Daten verwendet.

Die SWD-Kommunikation besteht aus drei Phasen:Paketanforderung, Bestätigung und Datenübertragung. Während der Paketanforderung gibt die Host-Plattform eine Anforderung an den DP aus, der eine Bestätigungsantwort folgen muss. Wenn die Paketanforderung eine Datenlese- oder Datenschreibanforderung war und es eine gültige Bestätigung gab, tritt das System in die Datenübertragungsphase ein, in der Daten über SWDIO eingetaktet (schreiben) oder ausgetaktet (lesen) werden. Nach einer Datenübertragung ist der Host dafür verantwortlich, entweder eine Paketanforderung zu starten oder die SWD-Schnittstelle mit Leerlaufzyklen anzusteuern (Takt SWDIO LOW). Eine Paritätsprüfung wird auf Paketanforderungen und Datenübertragungsphasen angewendet.

Die Einzelheiten von SWD lassen sich am besten anhand eines Zeitdiagramms verstehen, das in Abbildung 2 dargestellt ist.

Abbildung 2. Timing-Diagramme, die Lese- und Schreibvorgänge für Serial Wire Debug zeigen. [Zum Vergrößern anklicken]

Die Lese- und Schreiboperationen beginnen beide gleich, beginnend damit, dass der Host die SWDIO-Leitung auf ein Startbit treibt, das ein HIGH-Signal ist. Es folgt die Konfiguration, einschließlich des AP- oder DP-Zugriffsbits (APnDP), des Lese- oder Schreibbits (RnW), der Adresse (A[2:3]), eines Paritätsbits (PAR) und eines Stoppbits ( ein LOW-Signal), gefolgt von einem Park-Bit, bei dem der Host die Leitung auf HIGH treibt, bevor die Leitung in den Turnaround geht. Während des Turnarounds darf weder das Ziel noch der Host die Linie fahren.

Abhängig vom Wert von RnW wird eine Lese- oder Schreiboperation ausgewählt. Beim Schreiben liefert das Ziel ein 3-Bit-ACK-Signal, dann gibt es eine weitere Turnaround-Periode, gefolgt von den zu schreibenden 32-Bit-Daten (WDATA) und einem Paritätsbit. Beim Lesen liefert das Ziel eine ACK und fährt dann die Leitung mit den 32-Bit-Lesedaten (RDATA) fort, gefolgt von einem Paritätsbit. Wenn ein Fehler aufgetreten ist, zeigen die ACK-Bits den Fehler an und der Host kann versuchen, den Vorgang neu zu starten. Beachten Sie, dass WDATA und RDATA zuerst das niedrigstwertige Bit (LSb) übertragen werden, was in Abbildung 2 durch Schreiben von WDATA[0:31] anstelle von WDATA[31:0] angezeigt wird.

Das Dokument Arm IHI0031E enthält weitere Zeitdiagramme, um verschiedene Fälle in der Kommunikation zu verdeutlichen, aber die oben genannten sind die Hauptanwendungsfälle. Es ist erwähnenswert, dass es (zum Zeitpunkt des Schreibens) zwei Versionen von SWD gibt; SWDv1 unterstützt nur eine Verbindung zwischen einem Host und einem Ziel (Point-to-Point), während SWDv2 eine Single-Host-Multi-Target-Kommunikation (Multidrop) implementiert. Version 2 ist, abgesehen von einigen Randfällen, nahezu abwärtskompatibel mit Version 1.

Andere Varianten von JTAG

SWD ist nicht die einzige Zweidrahtvariante des JTAG IEEE 1149.1 Standards. Insbesondere bietet der Standard IEEE 1149.7 eine JTAG-Schnittstelle mit reduzierter Pinanzahl (2-Draht). Andere 1149.x-Standards wie IEEE 1149.4 (Standard for Mixed-Signal Test Bus) und IEEE 1149.6 (Boundary-Scan Standard of Advanced Digital Networks) wurden in den letzten zwei Jahrzehnten entwickelt und bieten zusätzliche Funktionalität für komplexere Anwendungen. Dazu gehören Dinge wie analoge Boundary-Scan-Tests und verbesserte Funktionen für differentielle und AC-gekoppelte Leitungen.

Die aktuellsten Standards sind auf der Website der IEEE Standards Association verfügbar.

Schlussfolgerung

Damit ist unsere Berichterstattung über JTAG und SWD abgeschlossen. In dieser Serie haben wir gelernt, woher JTAG kommt, wie es funktioniert und wie es zum Debuggen und Programmieren von Geräten verwendet wird. Wir haben uns die physischen Verbindungen für JTAG angesehen, einschließlich der verfügbaren Anschlüsse und Schnittstellen, sowohl kommerziell als auch Open Source. Schließlich schlossen wir mit einem Überblick über die JTAG-Implementierung für die beliebten ARM-Prozessorkerntechnologien, einschließlich der SWD-Zweidrahtschnittstelle.

Von hier aus können wir die Debugging- und Programmierfunktionen unserer eingebetteten Geräte selbstbewusst nutzen, die Einzelheiten für verschiedene Implementierungen kennenlernen und unsere Zeit optimal nutzen.