JTAG- JTAG

JTAG (benannt nach der Joint Test Action Group, die es kodifiziert hat) ist ein Industriestandard für die Überprüfung von Designs und das Testen von Leiterplatten nach der Herstellung.

JTAG implementiert Standards für die On-Chip-Instrumentierung in der Electronic Design Automation (EDA) als ergänzendes Werkzeug zur digitalen Simulation . Es spezifiziert die Verwendung eines dedizierten Debug-Ports , der eine serielle Kommunikationsschnittstelle für den Zugriff mit geringem Overhead implementiert, ohne dass ein direkter externer Zugriff auf die Systemadressen- und Datenbusse erforderlich ist. Die Schnittstelle ist mit einem Testzugriffsport (TAP) auf dem Chip verbunden, der ein zustandsbehaftetes Protokoll implementiert , um auf einen Satz von Testregistern zuzugreifen , die die Logikebenen des Chips und die Gerätefähigkeiten verschiedener Teile darstellen.

Die Joint Test Action Group wurde 1985 gegründet, um eine Methode zur Überprüfung von Designs und zum Testen von Leiterplatten nach der Herstellung zu entwickeln. 1990 kodifizierte das Institute of Electrical and Electronics Engineers die Ergebnisse der Bemühungen im IEEE-Standard 1149.1-1990 mit dem Titel Standard Test Access Port and Boundary-Scan Architecture .

Die JTAG-Standards wurden von vielen Halbleiterchipherstellern um spezialisierte Varianten erweitert, um herstellerspezifische Funktionen bereitzustellen.

Geschichte

In den 1980er Jahren wurden mehrschichtige Leiterplatten und integrierte Schaltkreise (ICs) unter Verwendung von Ball Grid Arrays und ähnlichen Montagetechnologien zum Standard, und es wurden Verbindungen zwischen ICs hergestellt, die für Sonden nicht verfügbar waren. Die meisten Herstellungs- und Feldfehler bei Leiterplatten waren auf schlechte Lötverbindungen auf den Leiterplatten, Unvollkommenheiten zwischen Leiterplattenverbindungen oder die Bonds und Bonddrähte von IC-Pads zu Pin-Leiterrahmen zurückzuführen. Die Joint Test Action Group (JTAG) wurde 1985 gegründet, um eine Pin-Out-Ansicht von einem IC-Pad zum anderen bereitzustellen, damit diese Fehler entdeckt werden konnten.

Der Industriestandard wurde 1990 als IEEE Std zum IEEE- Standard. 1149.1-1990 nach vielen Jahren Ersteinsatz. Im selben Jahr veröffentlichte Intel seinen ersten Prozessor mit JTAG (den 80486 ), was zu einer schnelleren Industrieakzeptanz bei allen Herstellern führte. 1994 wurde ein Supplement hinzugefügt , das eine Beschreibung der Boundary Scan Description Language (BSDL) enthält. Weitere Verfeinerungen in Bezug auf die Verwendung von Nullen für EXTEST, die Trennung der Verwendung von SAMPLE von PRELOAD und eine bessere Implementierung für OBSERVE_ONLY-Zellen wurden 2001 vorgenommen und veröffentlicht. Seit 1990 wird dieser Standard von Elektronikunternehmen auf der ganzen Welt übernommen. Boundary Scan ist heute meist gleichbedeutend mit JTAG, aber JTAG hat über solche Fertigungsanwendungen hinaus wesentliche Verwendungszwecke.

Debuggen

Obwohl die frühen Anwendungen von JTAG auf das Testen auf Leiterplattenebene abzielten, wurde der JTAG-Standard hier entwickelt, um beim Testen, der Diagnose und der Fehlerisolierung von Geräten, Leiterplatten und Systemen zu helfen . Heute wird JTAG als primäres Mittel für den Zugriff auf Unterblöcke integrierter Schaltkreise verwendet , was es zu einem wesentlichen Mechanismus zum Debuggen von eingebetteten Systemen macht, die möglicherweise keinen anderen Debug-fähigen Kommunikationskanal haben. Auf den meisten Systemen ist JTAG-basiertes Debugging ab der allerersten Anweisung nach dem Zurücksetzen der CPU verfügbar, sodass es bei der Entwicklung von Early-Boot-Software unterstützt wird, die ausgeführt wird, bevor etwas eingerichtet wird. Ein In-Circuit-Emulator (oder richtiger ein "JTAG-Adapter") verwendet JTAG als Transportmechanismus, um auf On-Chip- Debugging- Module innerhalb der Ziel- CPU zuzugreifen . Diese Module ermöglichen es Softwareentwicklern, die Software eines eingebetteten Systems bei Bedarf direkt auf Maschineninstruktionsebene oder (typischer) in Bezug auf den Quellcode der Hochsprache zu debuggen .

Die Unterstützung von Systemsoftware-Debugging ist für viele Softwareentwickler der Hauptgrund, sich für JTAG zu interessieren. Viele Siliziumarchitekturen wie PowerPC, MIPS, ARM, x86 haben eine komplette Software-Debug-, Instruction-Tracing- und Data-Tracing-Infrastruktur um das grundlegende JTAG-Protokoll herum aufgebaut. Häufig implementieren einzelne Siliziumhersteller jedoch nur Teile dieser Erweiterungen. Einige Beispiele sind ARM CoreSight und Nexus sowie Intels BTS (Branch Trace Storage), LBR (Last Branch Record) und IPT (Intel Processor Trace) Implementierungen. Es gibt viele andere herstellerspezifische Erweiterungen dieser Art, die möglicherweise nicht dokumentiert sind, außer unter NDA . Die Einführung des JTAG-Standards half dabei, JTAG-zentrierte Debugging-Umgebungen von frühen prozessorspezifischen Designs zu entfernen. Prozessoren können normalerweise angehalten, einzeln gestuft oder frei laufen gelassen werden. Man kann Code-Breakpoints setzen, sowohl für Code im RAM (oft unter Verwendung einer speziellen Maschinenanweisung) als auch im ROM/Flash. Datenhaltepunkte sind oft verfügbar, ebenso wie das Herunterladen von Massendaten in den RAM. Die meisten Designs verfügen über ein "Halt-Modus-Debugging", aber einige erlauben Debuggern, auf Register und Datenbusse zuzugreifen, ohne dass der Kern beim Debuggen angehalten werden muss. Einige Toolchains können ARM Embedded Trace Macrocell (ETM)-Module oder äquivalente Implementierungen in anderen Architekturen verwenden, um Debugger- (oder Tracing-)Aktivitäten bei komplexen Hardwareereignissen auszulösen, wie ein Logikanalysator, der so programmiert ist, dass er die ersten sieben Zugriffe auf ein Register von einer bestimmten Subroutine ignoriert .

Manchmal verwenden FPGA- Entwickler auch JTAG, um Debugging-Tools zu entwickeln. Dieselben JTAG-Techniken, die zum Debuggen von Software verwendet werden, die in einer CPU ausgeführt wird, können beim Debuggen anderer digitaler Designblöcke in einem FPGA helfen. Beispielsweise können benutzerdefinierte JTAG-Befehle bereitgestellt werden, um das Lesen von Registern zu ermöglichen, die aus beliebigen Signalsätzen innerhalb des FPGA erstellt wurden, wodurch Verhaltensweisen sichtbar werden, die für Boundary-Scan-Operationen unsichtbar sind. In ähnlicher Weise könnte das Schreiben solcher Register eine Steuerbarkeit bereitstellen, die sonst nicht verfügbar ist.

Firmware speichern

JTAG ermöglicht es der Hardware des Geräteprogrammierers , Daten in den internen nichtflüchtigen Gerätespeicher (zB CPLDs ) zu übertragen. Einige Geräteprogrammierer dienen einem doppelten Zweck zum Programmieren und Debuggen des Geräts. Bei FPGAs können auch flüchtige Speicherbausteine ​​über den JTAG-Port programmiert werden, normalerweise während der Entwicklungsarbeit. Darüber hinaus kann über den JTAG-Port auf interne Überwachungsfunktionen (Temperatur, Spannung und Strom) zugegriffen werden.

JTAG-Programmierer werden auch verwendet, um Software und Daten in Flash-Speicher zu schreiben . Dies erfolgt normalerweise unter Verwendung des gleichen Datenbuszugriffs, den die CPU verwenden würde, und wird manchmal von der CPU gehandhabt. In anderen Fällen verfügen die Speicherchips selbst über JTAG-Schnittstellen. Einige moderne Debug-Architekturen bieten internen und externen Busmasterzugriff, ohne dass eine CPU angehalten und übernommen werden muss. Im schlimmsten Fall ist es in der Regel möglich, externe Bussignale über die Boundary-Scan-Funktion anzusteuern.

In der Praxis ist bei der Entwicklung eines eingebetteten Systems das Emulieren des Befehlsspeichers der schnellste Weg, um den "Debug-Zyklus" (editieren, kompilieren, herunterladen, testen und debuggen) zu implementieren. Dies liegt daran, dass der In-Circuit-Emulator, der einen Befehlsspeicher simuliert, sehr schnell vom Entwicklungshost beispielsweise über USB aktualisiert werden kann. Die Verwendung eines seriellen UART-Ports und eines Bootloaders zum Hochladen von Firmware auf Flash macht diesen Debug-Zyklus ziemlich langsam und möglicherweise teuer in Bezug auf Tools; Das Installieren von Firmware in Flash (oder SRAM anstelle von Flash) über JTAG ist eine Zwischenlösung zwischen diesen Extremen.

Boundary-Scan-Tests

Die JTAG- Boundary-Scan- Technologie bietet Zugriff auf viele logische Signale einer komplexen integrierten Schaltung, einschließlich der Gerätepins. Die Signale werden in dem über den TAP zugänglichen Boundary Scan Register (BSR) dargestellt. Dies ermöglicht sowohl das Testen als auch das Steuern der Zustände der Signale zum Testen und Debuggen. Daher können sowohl Software- als auch Hardware-(Fertigungs-)Fehler lokalisiert und ein Betriebsgerät überwacht werden.

In Kombination mit integriertem Selbsttest ( BIST ) ermöglicht die JTAG-Scankette eine eingebettete Lösung mit geringem Overhead, um einen IC auf bestimmte statische Fehler (Kurzschlüsse, Unterbrechungen und logische Fehler) zu testen. Der Abtastkettenmechanismus hilft im Allgemeinen nicht bei der Diagnose oder Prüfung auf Timing-, Temperatur- oder andere dynamische Betriebsfehler, die auftreten können. Testfälle werden häufig in standardisierten Formaten wie SVF oder dem binären Geschwister XSVF bereitgestellt und in Produktionstests verwendet. Die Möglichkeit, solche Tests an fertigen Leiterplatten durchzuführen, ist ein wesentlicher Bestandteil von Design for Test in heutigen Produkten und erhöht die Anzahl von Fehlern, die gefunden werden können, bevor Produkte an Kunden ausgeliefert werden.

Elektrische Eigenschaften

Eine JTAG-Schnittstelle ist eine spezielle Schnittstelle, die einem Chip hinzugefügt wird. Je nach JTAG-Version werden zwei, vier oder fünf Pins hinzugefügt. Die vier- und fünfpoligen Schnittstellen sind so ausgelegt, dass die JTAG-Leitungen mehrerer Chips auf einer Platine unter bestimmten Bedingungen verkettet werden können. Die zweipolige Schnittstelle ist so ausgelegt, dass mehrere Chips in einer Sterntopologie verbunden werden können . In beiden Fällen muss eine Testsonde nur an einen einzigen "JTAG-Port" angeschlossen werden, um Zugriff auf alle Chips auf einer Leiterplatte zu haben .

Daisy-chained JTAG (IEEE 1149.1)

Die Steckerstifte sind:

1. TDI (Testdateneingang)
2. TDO (Testdatenausgang)
3. TCK (Testuhr)
4. TMS (Testmodusauswahl)
5. TRST (Test-Reset) optional.

Der TRST-Pin ist ein optionaler Active-Low-Reset für die Testlogik, normalerweise asynchron, aber manchmal synchron, je nach Chip. Wenn der Pin nicht verfügbar ist, kann die Testlogik zurückgesetzt werden, indem mit TCK und TMS synchron in den Reset-Zustand geschaltet wird. Beachten Sie, dass das Zurücksetzen der Testlogik nicht unbedingt das Zurücksetzen von etwas anderem impliziert. Es gibt im Allgemeinen einige prozessorspezifische JTAG-Operationen, die den gesamten oder einen Teil des zu debuggenden Chips zurücksetzen können.

Da nur eine Datenleitung zur Verfügung steht, ist das Protokoll seriell . Der Takteingang liegt am TCK-Pin. Pro steigender Taktflanke des TCK wird ein Datenbit vom TDI ein- und aus dem TDO übertragen. Es können verschiedene Anweisungen geladen werden. Anweisungen für typische ICs können die Chip-ID lesen, Eingangspins abtasten, Ausgangspins des Laufwerks (oder Float) lesen, Chipfunktionen manipulieren oder umgehen (TDI an TDO weiterleiten, um Ketten mehrerer Chips logisch zu verkürzen).

Wie bei jedem getakteten Signal müssen dem TDI präsentierte Daten für eine bestimmte chipspezifische Setup- Zeit vor und für eine Haltezeit nach der entsprechenden (hier steigenden) Taktflanke gültig sein . TDO-Daten sind für einige chipspezifische Zeit nach der fallenden Flanke von TCK gültig.

Die maximale Betriebsfrequenz von TCK variiert in Abhängigkeit von allen Chips in der Kette (es muss die niedrigste Geschwindigkeit verwendet werden), beträgt jedoch typischerweise 10-100 MHz (100-10 ns pro Bit). Auch die TCK-Frequenzen hängen vom Platinenlayout und den Fähigkeiten und dem Zustand des JTAG-Adapters ab. Ein Chip kann einen JTAG-Takt von 40 MHz haben, aber nur, wenn er einen 200-MHz-Takt für Nicht-JTAG-Operationen verwendet; und es könnte einen viel langsameren Takt benötigen, wenn es sich im Energiesparmodus befindet. Dementsprechend haben einige JTAG-Adapter eine adaptive Taktung unter Verwendung eines RTCK-(Rückkehr-TCK-)Signals. Schnellere TCK-Frequenzen sind am nützlichsten, wenn JTAG verwendet wird, um viele Daten zu übertragen, beispielsweise beim Speichern eines ausführbaren Programms im Flash-Speicher .

Taktänderungen auf TMS durchlaufen eine standardisierte JTAG- Zustandsmaschine . Die JTAG-Zustandsmaschine kann rücksetzen, auf ein Befehlsregister zugreifen oder auf durch das Befehlsregister ausgewählte Daten zugreifen.

JTAG-Plattformen fügen der Handvoll, die in der IEEE 1149.1-Spezifikation definiert ist, oft Signale hinzu. Ein System-Reset-Signal (SRST) ist weit verbreitet und ermöglicht es Debuggern, das gesamte System zurückzusetzen, nicht nur die Teile mit JTAG-Unterstützung. Manchmal gibt es Ereignissignale, die verwendet werden, um Aktivitäten durch den Host oder das Gerät auszulösen, das über JTAG überwacht wird; oder vielleicht zusätzliche Steuerleitungen.

Auch wenn einige Consumer - Produkte einen expliziten JTAG - Port - Anschluss zur Verfügung stellen, sind die Verbindungen oft auf der Leiterplatte als Überbleibsel von der Entwicklung Prototyping und / oder Produktion. Wenn diese Verbindungen ausgenutzt werden, stellen sie oft die praktikabelsten Mittel für das Reverse Engineering dar .

Reduzierte Pinanzahl JTAG (IEEE 1149.7)

Reduzierte Pinanzahl JTAG verwendet nur zwei Drähte, einen Taktdraht und einen Datendraht. Dies ist als Teil des Standards IEEE 1149.7 definiert. Die Steckerstifte sind:

1. TMSC ( Testseriendaten )
2. TCKC ( Testuhr )

Es heißt cJTAG für kompaktes JTAG.

Die Zweidrahtschnittstelle reduziert den Druck auf die Anzahl der Pins und Geräte können in einer Sterntopologie angeschlossen werden . Die Sterntopologie ermöglicht es, einige Teile des Systems herunterzufahren, während auf andere weiterhin über JTAG zugegriffen werden kann; eine Daisy-Chain erfordert, dass alle JTAG-Schnittstellen mit Strom versorgt werden. Es gibt auch andere Zweidrahtschnittstellen, wie z. B. Serial Wire Debug .

Kommunikationsmodell

In JTAG, belichten Geräte einen oder mehrere Testzugriffs - Ports (TAPs). Das Bild oben zeigt drei TAPs, die einzelne Chips oder Module innerhalb eines Chips sein können. Eine Daisy-Chain von TAPs wird als Scan-Kette oder (lose) als Ziel bezeichnet. Scan-Ketten können beliebig lang sein, aber in der Praxis sind zwanzig TAPs ungewöhnlich lang.

Um JTAG zu verwenden, wird ein Host über eine Art JTAG-Adapter mit den JTAG-Signalen des Ziels (TMS, TCK, TDI, TDO usw.) verbunden , der möglicherweise Probleme wie Pegelverschiebung und galvanische Trennung bewältigen muss . Der Adapter wird über eine Schnittstelle wie USB, PCI, Ethernet usw. mit dem Host verbunden.

Primitive

Der Host kommuniziert mit den TAPs, indem er TMS und TDI in Verbindung mit TCK manipuliert und die Ergebnisse über TDO (die einzige hostseitige Standardeingabe) liest. TMS/TDI/TCK-Ausgangsübergänge erstellen das grundlegende JTAG-Kommunikationsprimitiv, auf dem Protokolle höherer Schichten aufbauen:

• Zustandsumschaltung ... Alle TAPs befinden sich im gleichen Zustand, und dieser Zustand ändert sich bei TCK-Übergängen. Diese JTAG-Zustandsmaschine ist Teil der JTAG-Spezifikation und umfasst sechzehn Zustände. Es gibt sechs "stabile Zustände", bei denen die Stabilität des TMS verhindert, dass sich der Zustand ändert. In allen anderen Zuständen ändert TCK diesen Zustand immer. Außerdem erzwingt das Anlegen von TRST den Eintritt in einen dieser stabilen Zustände (Test_Logic_Reset) auf eine etwas schnellere Weise als die Alternative, TMS hoch zu halten und TCK fünfmal zyklisch zu durchlaufen.
• Shifting ... Die meisten Teile der JTAG-Zustandsmaschine unterstützen zwei stabile Zustände, die zum Übertragen von Daten verwendet werden. Jeder TAP hat ein Befehlsregister (IR) und ein Datenregister (DR). Die Größe dieser Register variiert zwischen TAPs, und diese Register werden durch TDI und TDO kombiniert, um ein großes Schieberegister zu bilden. (Die Größe des DR ist eine Funktion des Werts im aktuellen IR dieses TAP und möglicherweise des durch einen SCAN_N-Befehl angegebenen Werts.) Für dieses Schieberegister sind drei Operationen definiert:
  • Erfassen eines temporären Wertes
    • Der Eintritt in den stabilen Zustand Shift_IR erfolgt über den Zustand Capture_IR, der das Schieberegister mit einem teilweise festen Wert lädt (nicht die aktuelle Anweisung)
    • Der Eintritt in den stabilen Zustand Shift_DR erfolgt über den Zustand Capture_DR, wobei der Wert des Datenregisters geladen wird, der durch die aktuelle IR des TAP spezifiziert wird.
  • Bitweises Verschieben dieses Wertes in den stabilen Zustand Shift_IR oder Shift_DR; TCK-Übergänge verschieben das Schieberegister um ein Bit von TDI in Richtung TDO, genau wie bei einer SPI- Modus-1-Datenübertragung durch eine Daisy-Chain von Geräten (wobei TMS=0 wie das Chipauswahlsignal wirkt, TDI als MOSI usw.).
  • Aktualisieren von IR oder DR von dem eingeschobenen temporären Wert beim Übergang durch den Status Update_IR oder Update_DR. Beachten Sie, dass es nicht möglich ist, ein Register zu lesen (zu erfassen), ohne es zu schreiben (zu aktualisieren) und umgekehrt. Ein übliches Idiom fügt Flag-Bits hinzu, um anzugeben, ob die Aktualisierung Nebeneffekte haben soll oder ob die Hardware bereit ist, solche Nebeneffekte auszuführen.
• Running ... Ein stabiler Zustand wird Run_Test/Idle genannt. Die Unterscheidung ist TAP-spezifisch. Das Takten von TCK im Idle-Zustand hat keine besonderen Nebenwirkungen, aber das Takten von TCK im Run_Test-Zustand kann den Systemzustand ändern. Einige ARM9- Kerne unterstützen beispielsweise einen Debugging-Modus, bei dem TCK-Zyklen im Run_Test-Zustand die Befehlspipeline steuern.

Grundsätzlich umfasst die Verwendung von JTAG also das Lesen und Schreiben von Befehlen und ihren zugehörigen Datenregistern; und beinhaltet manchmal das Ausführen einer Reihe von Testzyklen. Hinter diesen Registern steht Hardware, die nicht von JTAG spezifiziert ist und ihre eigenen Zustände hat, die von JTAG-Aktivitäten beeinflusst werden.

Die meisten JTAG-Hosts verwenden den kürzesten Weg zwischen zwei Zuständen, möglicherweise eingeschränkt durch Eigenarten des Adapters. (Beispielsweise verarbeitet ein Adapter nur Pfade, deren Länge Vielfache von sieben Bit beträgt.) Einige auf JTAG aufbauende Schichten überwachen die Zustandsübergänge und verwenden ungewöhnliche Pfade, um Operationen auf höherer Ebene auszulösen. Einige ARM-Kerne verwenden solche Sequenzen, um in einen Zweidraht-(Nicht-JTAG-) SWD- Modus einzutreten und ihn zu verlassen . Eine Zero Bit Scan (ZBS)-Sequenz wird in IEEE 1149.7 verwendet, um auf erweiterte Funktionen zuzugreifen, wie z. B. das Umschalten von TAPs in und aus Scan-Ketten, Energieverwaltung und einen anderen Zweidrahtmodus.

Anweisungen für JTAG IEEE Std 1149.1 (Boundary Scan)

Befehlsregistergrößen neigen dazu, klein zu sein, vielleicht vier oder sieben Bit breit. Mit Ausnahme von BYPASS und EXTEST werden alle Befehls-Opcodes vom TAP-Implementierer definiert, ebenso wie ihre zugehörigen Datenregister; undefinierte Befehlscodes sollten nicht verwendet werden. Zwei wichtige Anweisungen sind:

• Der BYPASS-Befehl, ein Opcode aller Einsen, unabhängig von der Befehlsregistergröße des TAP, muss von allen TAPs unterstützt werden. Der Befehl wählt ein Einzelbit-Datenregister (auch BYPASS genannt) aus. Die Anweisung ermöglicht, dass dieses Gerät umgangen wird (nichts tun), während andere Geräte im Scanpfad ausgeführt werden.
• Die optionale IDCODE-Anweisung mit einem vom Implementierer definierten Opcode. IDCODE ist einem 32-Bit-Register (IDCODE) zugeordnet. Die Daten verwenden ein standardisiertes Format, das einen Herstellercode (abgeleitet vom JEDEC Standard Manufacturer's Identification Code Standard, JEP-106), eine vom Hersteller zugewiesene Teilenummer und einen Teileversionscode enthält. IDCODE wird weit verbreitet, aber nicht universell unterstützt.

Beim Verlassen des RESET-Zustands wird das Befehlsregister entweder mit BYPASS oder IDCODE vorgeladen. Dadurch können JTAG-Hosts die Größe und zumindest teilweise den Inhalt der Scan-Kette erkennen, mit der sie verbunden sind. (Sie können in den RESET-Zustand wechseln und dann das Datenregister scannen, bis sie die von ihnen geschriebenen Daten zurücklesen. Ein BYPASS-Register hat nur ein Null-Bit, während ein IDCODE-Register 32 Bit lang ist und mit einer Eins beginnt. Die Bits werden also nicht von geschrieben der Host kann leicht auf TAPs abgebildet werden.) Eine solche Identifizierung wird oft verwendet, um die manuelle Konfiguration auf ihre Richtigkeit zu überprüfen, da IDCODE oft unspezifisch ist. Es könnte beispielsweise einen ARM Cortex-M3-basierten Mikrocontroller identifizieren, ohne den Hersteller oder das Modell des Mikrocontrollers anzugeben; oder ein bestimmtes FPGA, aber nicht wie es programmiert wurde.

Ein übliches Idiom beinhaltet das Verschieben von BYPASS in die Befehlsregister aller TAPs außer einem, der einen anderen Befehl empfängt. Auf diese Weise legen alle TAPs außer einem ein Einzelbit-Datenregister offen, und Werte können selektiv in das oder aus dem Datenregister dieses einen TAPs verschoben werden, ohne irgendeinen anderen TAP zu beeinflussen.

Der Standard IEEE 1149.1 (JTAG) beschreibt eine Reihe von Anweisungen zur Unterstützung von Boundary-Scan-Anwendungen. Einige dieser Anweisungen sind "obligatorisch", aber TAPs, die für das Debuggen anstelle von Boundary-Scan-Tests verwendet werden, bieten manchmal nur minimale oder keine Unterstützung für diese Anweisungen. Diese "obligatorischen" Befehle arbeiten mit dem Boundary Scan Register (BSR), das in der BSDL- Datei definiert ist, und umfassen:

• EXTEST für externe Tests, z. B. die Verwendung von Pins zum Testen des Verhaltens auf Platinenebene
• PRELOAD lädt Pin-Ausgangswerte vor EXTEST (manchmal kombiniert mit SAMPLE)
• SAMPLE Lesen von Pin-Werten in das Boundary-Scan-Register

Zu den IEEE-definierten "Optional"-Anweisungen gehören:

• CLAMP eine Variante von BYPASS, die die Ausgangspins mit den PRELOAD-Werten ansteuert
• HIGHZ deaktiviert die Ausgänge aller Pins
• INTEST für interne Tests, z. B. die Verwendung von Pins zum Testen von On-Chip-Verhalten
• RUNBIST versetzt den Chip in einen Selbsttestmodus
• USERCODE gibt einen benutzerdefinierten Code zurück, um beispielsweise zu erkennen, welches FPGA-Image aktiv ist

Geräte können weitere Anweisungen definieren, und diese Definitionen sollten Teil einer vom Hersteller bereitgestellten BSDL-Datei sein. Sie sind oft nur als PRIVAT gekennzeichnet.

Boundary-Scan-Register

Geräte kommunizieren mit der Welt über eine Reihe von Eingangs- und Ausgangspins. An sich bieten diese Stifte eine eingeschränkte Sicht auf die Funktionsweise des Geräts. Geräte, die Boundary-Scan unterstützen, enthalten jedoch eine Schieberegisterzelle für jeden Signalpin des Geräts. Diese Register sind in einem dedizierten Pfad um die Gerätegrenze herum verbunden (daher der Name). Der Pfad schafft eine virtuelle Zugriffsfähigkeit, die die normalen Ein- und Ausgänge umgeht und eine direkte Kontrolle des Geräts und eine detaillierte Sichtbarkeit der Signale bietet.

Der Inhalt des Boundary-Scan-Registers, einschließlich der Signal-I/O-Fähigkeiten, wird normalerweise vom Hersteller mithilfe einer teilespezifischen BSDL- Datei beschrieben. Diese werden mit Design-"Netzlisten" von CAD/EDA-Systemen verwendet, um Tests für die Leiterplattenherstellung zu entwickeln. Kommerzielle Testsysteme kosten oft mehrere tausend Dollar für ein komplettes System und beinhalten Diagnosemöglichkeiten, um Fehler wie Unterbrechungen und Kurzschlüsse zu lokalisieren. Sie können auch Schaltplan- oder Layout-Viewer anbieten, um den Fehler grafisch darzustellen.

Um Boundary-Scanning zu ermöglichen, fügen IC-Anbieter jedem ihrer Geräte Logik hinzu, einschließlich Scanzellen für jeden der Signalpins. Diese Zellen werden dann miteinander verbunden, um das Boundary-Scan-Schieberegister (BSR) zu bilden, das mit einem TAP-Controller verbunden ist. Diese Designs sind Bestandteil der meisten Verilog- oder VHDL-Bibliotheken. Der Aufwand für diese zusätzliche Logik ist minimal und im Allgemeinen den Preis wert, um effiziente Tests auf Board-Ebene zu ermöglichen.

Beispiel: ARM11-Debug-TAP

Ein Beispiel hilft, den Betrieb von JTAG in realen Systemen zu veranschaulichen. Das Beispiel hier ist der Debug-TAP eines ARM11- Prozessors, des ARM1136-Kerns. Der Prozessor selbst verfügt über umfangreiche JTAG-Fähigkeiten, ähnlich wie bei anderen CPU-Kernen, und ist in Chips mit noch umfangreicheren Fähigkeiten integriert, auf die über JTAG zugegriffen wird.

Dies ist ein nicht triviales Beispiel, das für einen bedeutenden Querschnitt von JTAG-fähigen Systemen repräsentativ ist. Darüber hinaus wird gezeigt, wie Kontrollmechanismen unter Verwendung der Register-Lese-/Schreib-Primitive von JTAG aufgebaut werden und wie diese kombiniert werden, um das Testen und Debuggen komplexer Logikelemente zu erleichtern; CPUs sind weit verbreitet, aber FPGAs und ASICs enthalten andere komplexe Elemente, die debuggt werden müssen.

Lizenznehmer dieses Kerns integrieren ihn in Chips und kombinieren ihn in der Regel mit anderen TAPs sowie zahlreichen Peripheriegeräten und Speicher. Einer dieser anderen TAPs übernimmt Boundary-Scan-Tests für den gesamten Chip; es wird vom Debug-TAP nicht unterstützt. Beispiele für solche Chips sind:

• Der OMAP2420 , der einen Boundary-Scan-TAP, den ARM1136-Debug-TAP, einen ETB11-Trace-Buffer-TAP, einen C55x-DSP und einen TAP für eine ARM7- TDMI-basierte Imaging-Engine umfasst, wobei der Boundary-Scan-TAP ("ICEpick-B") mit die Fähigkeit, TAPs in und aus der JTAG-Scankette zu spleißen.
• Der i.MX31- Prozessor ist ähnlich, obwohl sein "System JTAG"-Boundary-Scan-TAP, der sich stark von ICEpick unterscheidet, und er enthält einen TAP für seine DMA-Engine anstelle eines DSP und einer Imaging-Engine.

Diese Prozessoren sind beide für den Einsatz in drahtlosen Handsets wie Mobiltelefonen vorgesehen, was einer der Gründe dafür ist, dass sie TAP-Controller enthalten, die die JTAG-Scan-Kette modifizieren: Das Debuggen des Betriebs mit geringem Stromverbrauch erfordert den Zugriff auf Chips, wenn sie weitgehend ausgeschaltet sind, und wenn nicht alle TAPs sind betriebsbereit. Diese Scan-Ketten-Modifikation ist ein Thema eines bevorstehenden IEEE 1149.7-Standards.

JTAG-Einrichtungen

Dieses Debug-TAP stellt mehrere Standardanweisungen bereit, und einige wurden speziell für das hardwareunterstützte Debuggen entwickelt , bei dem ein Softwaretool (der "Debugger") JTAG verwendet, um mit einem zu debuggenden System zu kommunizieren:

• BYPASSund IDCODE, Standardanweisungen wie oben beschrieben
• EXTEST, INTEST, Standardanweisungen, die jedoch auf dem Kern statt einer externen Boundary-Scan-Kette arbeiten. EXTESTdient nominell zum Schreiben von Daten in den Kern, INTESTdient nominell zum Lesen desselben; Ausnahmen von dieser Regel sind jedoch zwei Scan-Ketten.
• SCAN_NARM-Befehl zur Auswahl der nummerierten Scan-Kette, die mit EXTESToder verwendet wird INTEST. Es gibt sechs Scan-Ketten:
  • 0 - Geräte-ID-Register, 40 Bit schreibgeschützte Identifikationsdaten
  • 1 - Debug Status and Control Register (DSCR), 32 Bit zum Betreiben der Debug-Einrichtungen
  • 4 - Instruction Transfer Register (ITR), 33 Bit (32 Instruktionen plus ein Statusbit) zur Ausführung von Prozessorbefehlen in einem speziellen "Debug Mode" (siehe unten)
  • 5- Debug Communications Channel (DCC), 34 Bit (ein langes Datenwort plus zwei Statusbits) für die bidirektionale Datenübertragung zum Core. Dies wird sowohl im Debug-Modus als auch möglicherweise zur Laufzeit verwendet, wenn mit Debugger-fähiger Software gesprochen wird.
  • 6- Embedded Trace Module (ETM), 40 Bit (7 Bit Adresse, ein 32 Bit langes Datenwort und ein R/W Bit) zur Steuerung des Betriebs eines passiven Befehls- und Datenverfolgungsmechanismus. Dies speist entweder einen On-Chip Embedded Trace Buffer (ETB) oder einen externen Hochgeschwindigkeits-Trace-Datenerfassungs-Pod. Die Ablaufverfolgung unterstützt passives Debugging (Untersuchung des Ausführungsverlaufs) und Profilerstellung zur Leistungsoptimierung.
  • 7- Debug-Modul, 40 Bit (7 Bit-Adresse, ein 32 Bit langes Datenwort und ein R/W-Bit) für den Zugriff auf Hardware-Breakpoints, Watchpoints und mehr. Diese können bei laufendem Prozessor geschrieben werden; es muss sich nicht im Debug-Modus befinden.
• HALTund RESTARTARM11-spezifische Anweisungen zum Anhalten und Neustarten der CPU. Wenn es angehalten wird, wird der Kern in den "Debug-Modus" versetzt, in dem der ITR verwendet werden kann, um Anweisungen auszuführen, einschließlich der Verwendung des DCC, um Daten zwischen dem Debug-Host (JTAG) und der CPU zu übertragen.
• ITRSEL, ARM11-spezifischer Befehl zur Beschleunigung einiger Operationen mit ITR.

Dieses Modell ähnelt dem Modell, das in anderen ARM-Kernen verwendet wird. Nicht-ARM-Systeme haben im Allgemeinen ähnliche Fähigkeiten, die möglicherweise unter Verwendung der Nexus- Protokolle zusätzlich zu JTAG oder anderer herstellerspezifischer Schemata implementiert werden .

Ältere ARM7- und ARM9- Kerne enthalten ein EmbeddedICE- Modul, das die meisten dieser Funktionen kombiniert, aber einen umständlichen Mechanismus für die Befehlsausführung hat: Der Debugger muss die CPU-Befehlspipeline Takt für Takt steuern und direkt auf die Datenbusse zugreifen, um Daten zu lesen und zu schreiben die CPU. Der ARM11 verwendet dasselbe Modell für die Trace-Unterstützung (ETM, ETB) wie diese älteren Kerne.

Neuere ARM-Cortex-Kerne ähneln diesem Debug-Modell stark, bauen aber auf einem Debug Access Port (DAP) anstelle von direktem CPU-Zugriff auf. In dieser Architektur (genannt CoreSight Technology ) sind Kern und JTAG-Modul völlig unabhängig. Sie sind auch von JTAG entkoppelt, sodass sie über die zweiadrige SWD- Schnittstelle von ARM (siehe unten) statt nur über die sechsadrige JTAG-Schnittstelle gehostet werden können. (ARM nimmt die vier Standard-JTAG-Signale und fügt das optionale TRST sowie das RTCK-Signal für die adaptive Taktung hinzu.) Der CoreSight JTAG-DP ist asynchron zu den Kerntakten und implementiert kein RTCK. Außerdem verfügen die neueren Kerne über eine aktualisierte Trace-Unterstützung.

Debug-Modus anhalten

Ein grundlegender Weg zum Debuggen von Software besteht darin, ein Single-Thread-Modell zu präsentieren, bei dem der Debugger die Ausführung des Programms periodisch stoppt und seinen Zustand untersucht, wie er durch Registerinhalte und Speicher (einschließlich peripherer Controller-Register) offengelegt wird. Wenn sich interessante Programmereignisse nähern, möchte eine Person möglicherweise Einzelschrittanweisungen (oder Quellcodezeilen) verwenden, um zu beobachten, wie ein bestimmtes Fehlverhalten auftritt.

So könnte beispielsweise ein JTAG-Host den Kern HALTEN, in den Debug-Modus wechseln und dann CPU-Register mit ITR und DCC lesen. Nach dem Speichern des Prozessorzustands könnte er diese Register mit den benötigten Werten schreiben, dann beliebige Algorithmen auf der CPU ausführen und auf Speicher und Peripheriegeräte zugreifen, um den Systemzustand zu charakterisieren. Nachdem der Debugger diese Operationen ausgeführt hat, kann der Zustand wiederhergestellt und die Ausführung unter Verwendung des RESTART-Befehls fortgesetzt werden.

Der Debug-Modus wird auch asynchron dadurch betreten, dass das Debug-Modul einen Watchpoint oder Breakpoint auslöst oder einen BKPT-Befehl (Breakpoint) von der Software ausgibt, die debuggt wird. Wenn er nicht für die Befehlsverfolgung verwendet wird, kann der ETM auch den Eintritt in den Debug-Modus auslösen; Es unterstützt komplexe Trigger, die auf Status und Historie reagieren, sowie die einfachen Adressvergleiche, die vom Debug-Modul bereitgestellt werden. Asynchrone Übergänge in den Debug-Modus werden durch Abfragen des DSCR-Registers erkannt. So wird Single-Stepping implementiert: HALT den Kern, setze einen temporären Breakpoint bei der nächsten Anweisung oder der nächsten High-Level-Anweisung, RESTART, Poll DSCR, bis du einen asynchronen Einstieg in den Debug-Zustand erkennst, entferne diesen temporären Breakpoint, wiederhole.

Debugging im Überwachungsmodus

Moderne Software ist oft zu komplex, um mit einem solchen Single-Thread-Modell gut zu funktionieren. Beispielsweise kann ein Prozessor, der zum Steuern eines Motors verwendet wird (vielleicht einer, der ein Sägeblatt antreibt), möglicherweise nicht sicher in den Stoppmodus wechseln; es muss möglicherweise weiterhin Unterbrechungen verarbeiten, um die physische Sicherheit von Personen und/oder Maschinen zu gewährleisten. Die Ausgabe einer HALT-Anweisung mit JTAG kann gefährlich sein.

ARM-Prozessoren unterstützen einen alternativen Debug-Modus namens Monitor Mode , um mit solchen Situationen zu arbeiten. (Dies unterscheidet sich vom Secure Monitor Mode , der als Teil von Sicherheitserweiterungen auf neueren ARM-Kernen implementiert wird; er verwaltet Debug-Operationen, keine Sicherheitsübergänge.) In diesen Fällen lösen Breakpoints und Watchpoints eine spezielle Art von Hardware-Ausnahme aus, die die Kontrolle an ein " Debug-Monitor", der als Teil der Systemsoftware ausgeführt wird. Dieser Monitor kommuniziert mit dem Debugger unter Verwendung des DCC und könnte beispielsweise dafür sorgen, dass nur ein einzelner Prozess in einem einzelnen Schritt ausgeführt wird, während andere Prozesse (und Interrupt-Handler) weiterlaufen.

Gängige Erweiterungen

Mikroprozessorhersteller haben oft ihre eigenen kernspezifischen Debugging-Erweiterungen definiert. Zu diesen Anbietern gehören Infineon , MIPS mit EJTAG und mehr. Wenn der Anbieter keinen Standard übernimmt (wie er von ARM-Prozessoren oder Nexus verwendet wird), muss er seine eigene Lösung definieren. Wenn sie Boundary-Scan unterstützen, bauen sie im Allgemeinen das Debugging über JTAG auf.

Freescale verfügt über COP und OnCE (On-Chip Emulation). OnCE enthält einen JTAG-Befehl, der einen TAP in einen speziellen Modus versetzt, in dem das IR OnCE-Debugging-Befehle für Operationen wie Einzelschritt, Breakpointing und Zugriff auf Register oder Speicher hält. Es definiert auch EOnCE (Enhanced On-Chip Emulation) als Lösung für Echtzeitprobleme.

ARM verfügt über eine umfangreiche Prozessorkern-Debug-Architektur (CoreSight), die mit EmbeddedICE (einer Debug-Funktion, die auf den meisten ARM-Kernen verfügbar ist) begann und jetzt viele zusätzliche Komponenten wie eine ETM (Embedded Trace Macrocell) mit einem Hochgeschwindigkeits-Trace-Port umfasst, der Multicore- und Multithread-Tracing. Beachten Sie, dass das Tracing nicht-invasiv ist. Systeme müssen den Betrieb nicht einstellen, um verfolgt zu werden. (Allerdings sind Trace-Daten zu umfangreich, um JTAG als mehr als nur einen Trace-Steuerkanal zu verwenden.)

Nexus definiert eine Prozessor-Debugging-Infrastruktur, die weitgehend herstellerunabhängig ist. Eine seiner Hardwareschnittstellen ist JTAG. Es definiert auch eine Hochgeschwindigkeits-Hilfs-Port-Schnittstelle, die für Tracing und mehr verwendet wird. Nexus wird mit einigen neueren Plattformen wie den Prozessoren der Atmel AVR32- und Freescale MPC5500-Serie verwendet.

Verwendet

• Mit Ausnahme einiger der untersten Endsysteme verfügen im Wesentlichen alle eingebetteten Systemplattformen über einen JTAG-Port zur Unterstützung von In-Circuit-Debugging und Firmware-Programmierung sowie für Boundary-Scan-Tests:
  • Prozessoren mit ARM-Architektur werden mit JTAG-Unterstützung geliefert und unterstützen manchmal eine Zweidraht-"SWD"-Variante oder die Hochgeschwindigkeitsverfolgung des Datenverkehrs auf Befehls- oder Datenbussen.
  • Moderne 8-Bit- und 16-Bit- Mikrocontroller- Chips wie Atmel AVR- und TI MSP430- Chips unterstützen JTAG-Programmierung und -Debugging. Die kleinsten Chips haben jedoch möglicherweise nicht genügend Pins übrig (und neigen daher dazu, sich auf proprietäre Single-Wire-Programmierschnittstellen zu verlassen); Wenn die Pinanzahl über 32 liegt, gibt es wahrscheinlich eine JTAG-Option.
  • Fast alle heute verwendeten FPGAs und CPLDs lassen sich über einen JTAG-Port programmieren. Eine Standardtest- und Programmiersprache ist durch den JEDEC-Standard JESD-71 für die JTAG-Programmierung von PLDs definiert.
  • Viele MIPS- und PowerPC- Prozessoren verfügen über JTAG-Unterstützung
  • Intel Core-, Xeon-, Atom- und Quark-Prozessoren unterstützen alle den JTAG-Probe-Modus mit Intel-spezifischen Erweiterungen von JTAG unter Verwendung des sogenannten 60-pin eXtended Debug Port [XDP]. Darüber hinaus unterstützt der Quark Prozessor traditionellere 10-Pin-Anschlüsse.
  • Verbraucherprodukte wie Netzwerkgeräte und integrierte Empfänger/Decoder für Satellitenfernsehen verwenden oft Mikroprozessoren, die JTAG unterstützen, was ein alternatives Mittel zum Neuladen von Firmware bietet, wenn der vorhandene Bootloader in irgendeiner Weise beschädigt wurde.
• Der PCI- Bus-Anschlussstandard enthält optionale JTAG-Signale an den Pins 1–5; PCI Express enthält JTAG-Signale an den Pins 5–9. Eine spezielle JTAG-Karte kann verwendet werden, um ein beschädigtes BIOS neu zu flashen .
• Boundary-Scan-Tests und systeminterne (Geräte-)Programmieranwendungen werden manchmal mit dem Serial Vector Format programmiert , einer Textdarstellung von JTAG-Operationen unter Verwendung einer einfachen Syntax. Andere Programmierformate sind 'JAM' und STAPL sowie neuerdings auch IEEE Std. 1532 definiertes Format 'ISC' (kurz für In-System Configuration). Das ISC-Format wird in Verbindung mit erweiterten BSDL-Modellen für programmierbare Logikvorrichtungen (dh FPGAs und CPLDs) verwendet, die zusätzliche ISC_<Operation>-Befehle zusätzlich zu den grundlegenden minimalen IEEE 1149.1-Befehlen enthalten. FPGA-Programmiertools von Xilinx , Altera, Lattice, Cypress, Actel usw. können solche Dateien normalerweise exportieren.
• Wie bereits erwähnt, enthalten viele Platinen JTAG-Steckverbinder oder einfach nur Pads, um Fertigungsvorgänge zu unterstützen, bei denen Boundary-Scan-Tests dazu beitragen, die Platinenqualität zu überprüfen (schlechte Lötstellen usw. zu identifizieren) und Flash-Speicher oder FPGAs zu initialisieren .
• JTAG kann auch Feldaktualisierungen und Fehlerbehebung unterstützen.

Kundendienst

Der Zugriff auf die JTAG-Schnittstelle des Ziels erfolgt unter Verwendung einiger JTAG-aktivierter Anwendungen und einiger JTAG-Adapterhardware. Es gibt eine breite Palette solcher Hardware, die für Zwecke wie Produktionstests, Debugging von Hochgeschwindigkeitssystemen, kostengünstige Entwicklung von Mikrocontrollern usw. optimiert ist. Ebenso kann die Software, die zum Ansteuern einer solchen Hardware verwendet wird, sehr unterschiedlich sein. Softwareentwickler verwenden hauptsächlich JTAG zum Debuggen und Aktualisieren von Firmware.

Anschlüsse

Es gibt keine offiziellen Standards für physikalische JTAG-Adapter-Anschlüsse. Entwicklungsboards enthalten normalerweise einen Header, um bevorzugte Entwicklungstools zu unterstützen; in einigen Fällen enthalten sie mehrere solcher Header, da sie mehrere solcher Tools unterstützen müssen. Ein Mikrocontroller, ein FPGA und ein ARM-Anwendungsprozessor teilen sich beispielsweise selten Tools, sodass ein Entwicklungsboard, das all diese Komponenten verwendet, möglicherweise drei oder mehr Header hat. Produktionsplatinen können die Header weglassen oder, wenn der Platz begrenzt ist, einen JTAG-Signalzugriff unter Verwendung von Testpunkten ermöglichen.

Einige gängige Pinbelegungen für 2,54 mm (0,100 Zoll) Stiftleisten sind:

• ARM 2×10 Pin (oder manchmal das ältere 2×7), wird von fast allen ARM-basierten Systemen verwendet
• MIPS EJTAG (2×7 Pin) für MIPS- basierte Systeme
• 2×5-Pin Altera ByteBlaster-kompatibles JTAG von vielen Anbietern erweitert
• 2×5-Pin- AVR erweitert Altera JTAG mit SRST (und in einigen Fällen TRST und einem Ereignisausgang)
• 2×7-Pin Texas Instruments verwendet mit DSPs und ARM-basierten Produkten wie OMAP
• 8-poliger (einreihiger) generischer PLD-JTAG, kompatibel mit vielen Lattice ispDOWNLOAD-Kabeln
• MIPI 10-/20-Steckverbinder (1,27 mm 050") für JTAG, cJTAG und SWD

Diese Anschlüsse beinhalten in der Regel mehr als nur die vier standardisierten Signale (TMS, TCK, TDI, TDO). Normalerweise werden Rücksetzsignale bereitgestellt, eines oder beide von TRST (TAP-Reset) und SRST (System-Reset). Der Anschluss stellt normalerweise die Logikversorgungsspannung der zu testenden Platine bereit, sodass die JTAG-Adapter die entsprechenden Logikpegel verwenden. Die Boardspannung kann auch als Debugger-Eingang „Board vorhanden“ dienen. Andere Ereigniseingangs- oder -ausgangssignale oder Allzweck-I/O- (GPIO)-Leitungen können bereitgestellt werden, um komplexere Debugging-Architekturen zu unterstützen.

High- End-Produkte verwenden häufig dichte Steckverbinder (häufig 38-polige MICTOR- Steckverbinder), um High-Speed- Tracing in Verbindung mit JTAG-Operationen zu unterstützen. Ein neuer Trend besteht darin, dass Entwicklungsboards eine USB-Schnittstelle zu JTAG integrieren, wo ein zweiter Kanal für einen seriellen Port verwendet wird. (Kleinere Boards können auch über USB mit Strom versorgt werden. Da moderne PCs dazu neigen, serielle Ports wegzulassen, können solche integrierten Debug-Links die Unordnung für Entwickler erheblich reduzieren.) Produktionsplatinen verlassen sich oft auf nagelneue Verbindungen zu Testpunkten zum Testen und Programmieren.

Adapterhardware

Die Adapterhardware variiert stark. Wenn es nicht in ein Entwicklungsboard integriert ist, ist ein kurzes Kabel erforderlich, das an einen JTAG-Anschluss auf dem Zielboard angeschlossen wird; eine Verbindung zum Debugging-Host, wie beispielsweise eine USB-, PCI- oder Ethernet-Verbindung; und genügend Elektronik, um die beiden Kommunikationsdomänen anzupassen (und manchmal für eine galvanische Trennung zu sorgen ). Eventuell ist ein separates Netzteil erforderlich. Es gibt beide "dumme" Adapter, bei denen der Host alle JTAG-Operationen entscheidet und durchführt; und "intelligente", bei denen ein Teil dieser Arbeit im Adapter ausgeführt wird, der oft von einem Mikrocontroller gesteuert wird. Die "intelligenten" Adapter eliminieren Verbindungslatenzen für Operationssequenzen, die das Abfragen von Statusänderungen zwischen den Schritten beinhalten können, und können dementsprechend einen schnelleren Durchsatz bieten.

Ab 2018 sind Adapter mit einer USB- Verbindung vom Host der gebräuchlichste Ansatz. High-End-Produkte unterstützen oft Ethernet , mit dem Vorteil, dass der Debug-Host ziemlich entfernt sein kann. Adapter, die Hochgeschwindigkeits-Trace-Ports unterstützen, enthalten im Allgemeinen mehrere Megabyte Trace-Puffer und stellen Hochgeschwindigkeitsverbindungen (USB oder Ethernet) bereit, um diese Daten an den Host zu übertragen.

Parallelport- Adapter sind einfach und kostengünstig, aber relativ langsam, da sie die Host-CPU verwenden, um jedes Bit zu ändern (" Bit-Banging "). Sie haben an Nützlichkeit verloren, da die meisten Computer in den letzten Jahren keinen parallelen Anschluss hatten. Auch die Treiberunterstützung ist ein Problem, da die Pinbelegung durch Adapter sehr unterschiedlich ist. Da der Parallelport auf einem Logikpegel von 5 V basiert, fehlte den meisten Adaptern die Spannungsumsetzungsunterstützung für 3,3 V oder 1,8 V Zielspannungen.

Es gibt auch serielle RS-232- Port- Adapter, deren Nützlichkeit in ähnlicher Weise abnimmt. Sie beinhalten im Allgemeinen entweder ein langsameres Bit-Banging als ein paralleler Port oder einen Mikrocontroller, der ein Befehlsprotokoll in JTAG-Operationen übersetzt. Solche seriellen Adapter sind auch nicht schnell, aber ihre Befehlsprotokolle könnten im Allgemeinen über Verbindungen mit höherer Geschwindigkeit wiederverwendet werden.

Bei allen JTAG-Adaptern ist die Softwareunterstützung ein grundlegendes Anliegen. Viele Anbieter veröffentlichen die von ihrer JTAG-Adapterhardware verwendeten Protokolle nicht und beschränken ihre Kunden auf die von diesen Anbietern unterstützten Toolketten. Dies ist ein besonderes Problem für "intelligente" Adapter, von denen einige umfangreiche Kenntnisse über die Interaktion mit bestimmten CPUs enthalten.

Software-Entwicklung

Die meisten Entwicklungsumgebungen für eingebettete Software enthalten JTAG-Unterstützung. Es gibt im Großen und Ganzen drei Quellen für solche Software:

• Chiphersteller können die Tools bereitstellen, die normalerweise einen von ihnen gelieferten JTAG-Adapter erfordern. Beispiele sind FPGA-Anbieter wie Xilinx und Altera , Atmel für seine AVR8- und AVR32-Produktlinien und Texas Instruments für die meisten seiner DSP- und Mikroprodukte. Solche Tools sind in der Regel sehr funktionsreich und möglicherweise die einzige echte Option für hochspezialisierte Chips wie FPGAs und DSPs. Low-End-Softwaretools können kostenlos zur Verfügung gestellt werden. Die JTAG-Adapter selbst sind nicht kostenlos, obwohl sie manchmal mit Entwicklungsboards gebündelt sind.
• Werkzeughersteller können sie bereitstellen, normalerweise in Verbindung mit mehreren Chipherstellern, um plattformübergreifende Entwicklungsunterstützung zu bieten. ARM- basierte Produkte haben einen besonders reichen Drittmarkt, und eine Reihe dieser Anbieter haben sich auf Nicht-ARM-Plattformen wie MIPS und PowerPC ausgeweitet . Werkzeughersteller bauen manchmal Produkte um freie Software wie GCC und GDB auf , wobei die GUI-Unterstützung häufig Eclipse verwendet . JTAG-Adapter werden manchmal zusammen mit Support-Paketen verkauft.
• Open-Source- Tools existieren. Wie oben erwähnt, bilden GCC und GDB den Kern einer guten Toolchain, und es gibt GUI-Umgebungen, die sie unterstützen.

All diese Software bietet in der Regel grundlegende Debugger-Unterstützung: Stoppen, Anhalten, Einzelschritte, Breakpoints, Durchsuchen von Datenstrukturen und so weiter. Kommerzielle Tools bieten in der Regel Tools wie sehr genaue Simulatoren und Spurenanalysen, die derzeit nicht als Open Source verfügbar sind.

Ähnliche Schnittstellenstandards

Serial Wire Debug (SWD) ist eine alternative elektrische 2-polige Schnittstelle, die das gleiche Protokoll verwendet. Es verwendet die vorhandene GND-Verbindung. SWD verwendet ein bidirektionales ARM-CPU-Standardkabelprotokoll, das in der ARM Debug Interface v5. Dadurch kann der Debugger ein weiterer AMBA- Bus-Master für den Zugriff auf den Systemspeicher und Peripherie- oder Debug-Register werden. Die Datenrate beträgt bis zu 4 MB/s bei 50 MHz . SWD hat auch eine eingebaute Fehlererkennung. Auf JTAG-Geräten mit SWD-Fähigkeit werden TMS und TCK als SWDIO- und SWCLK-Signale verwendet, wodurch Dual-Mode-Programmierer bereitgestellt werden.

Siehe auch

• Automatisierte optische Inspektion
• Automatisierte Röntgeninspektion
• In-Circuit-Test
• Abnahmeprüfung

Verweise

Externe Links

• IEEE-Standard für Testzugriffsport mit reduzierter Pin- und erweiterte Funktionalität und Boundary-Scan-Architektur Der offizielle IEEE 1149.7-Standard.
• JTAG 101 - IEEE 1149.x und Software Debug Intel Whitepaper zur JTAG-Nutzung beim Debuggen von Systemsoftware auf einer Vielzahl von Architekturen.
• IEEE Std 1149.1 (JTAG) Testability Primer Enthält eine starke technische Präsentation über JTAG mit Design-for-Test-Kapiteln.
• Boundary Scan / IEEE 1149 Tutorial mit Details zu Varianten des IEEE-Standards, BSDL, DFT und anderen Themen
• JTAG Tutorial Nützliche Tutorials und Informationen zur JTAG-Technologie.
• Was ist JTAG? Nützliche Informationen zu JTAG, Timeline, Architektur und mehr.
• JTAG-Anwendungen JTAG für Produktentwicklung, Lebenszyklus, Tests, benötigte Tools und andere Themen.