JTAG-Decodierung Verstehen Sie JTAG?

Die Fehlersuche an einem Bus ist komplex: Zur Signalmessung kommt die Decodierung der Daten hinzu. Setzt das Bus-Protokol wie z.B. bei JTAG voraus, dass nicht nur die am Bus angeschlossenen Bauteile, sondern auch ihre Reihenfolge und sogar die zurückliegende Kommunikation bekannt sind, dann kann die Fehlersuche zu einem langwierigen Mammutprojekt werden. Schneller und leichter geht es mit Decodierprogrammen für Oszilloskope.

JTAG, auch als IEEE 1149.1 bekannt, ist einer der erfolgreichsten Elektronikstandards aller Zeiten. Vor über 20 Jahren erfunden, um Leiterplatten zu prüfen, wird JTAG heute bei fast allen Leiterplatten eingesetzt. Weiterhin ist JTAG ein wichtiges Element vieler ICs geworden. Prozessoren, FPGAs und andere hochentwickelte Chips verfügen oftmals über einen JTAG-TAP-Controller (TAP, Test Access Port), über den einzelne Baugruppen zwecks Konfiguration, Kommunikation und Debugging erreicht werden können.

 Kurz, JTAG-Scan-Ketten sind nicht nur für den Test in der Produktion eine wesentliche Technik, sondern auch in der Entwicklung. Was aber passiert, wenn eine JTAG-Scan-Kette nicht richtig funktioniert? Neue Werkzeuge ermöglichen es, eine JTAG-Scan-Kette zu debuggen, und zwar sowohl auf der physikalischen Schicht als auch auf der Protokollschicht.

 Man müsste das JTAG-Protokoll decodieren können

Entwickler gehen stets davon aus, dass eine JTAG-Scan-Kette korrekt funktioniert. Wenn aber eine Scan-Kette doch nicht richtig funktioniert, nimmt man üblicherweise zunächst ein Oszilloskop zur Hand und schaut sich die JTAG-Signale (physikalische Schicht) an. Wie sieht der Takt (TCK) aus? Sind die Leitungen zu stark belastet? Hat die Scan-Kette ein Timing-Problem? Dieser Ansatz hilft dabei, ein Problem auf der physikalischen Ebene dingfest zu machen, es gibt aber keine vergleichbare Methode, sich das JTAG-Protokoll anzusehen.

 Manche Entwicklerteams hätten gern einen schnellen Zugriff auf ein decodiertes JTAG-Protokoll – beispielsweise, um ASIC-Register via JTAG zu lesen und zu beschreiben. Nicht etwa, weil JTAG dafür besonders gut geeignet wäre, sondern weil JTAG in diesem Fall die einzig verfügbare Schnittstelle ist. Oder ein Unternehmen, das z.B. Ethernet- oder USB-zu-JTAG-Adapter herstellt, will prüfen, ob seine Adapter korrekt übersetzen. Ein anderes Beispiel: Entwickler möchten gern ein Subsystem über JTAG ansprechen und dafür die Informationen auf dem JTAG-Bus decodieren. Oder ein IC-Hersteller will eine fehlerhafte Interaktion seines Bausteins mit einem JTAG-Tool eines Drittherstellers untersuchen. Das sind nur einige wenige Beispiele, in denen das Decodieren des JTAG-Protokolls sehr hilfreich wäre – in Echtzeit natürlich und mit Werkzeugen, die den Bus nicht stören. In allen diesen Fällen geht es darum, Probleme zu lösen, deren Ursache sich vielleicht irgendwo in der Protokollschicht oder der physikalischen Schicht der JTAG-Scan-Kette findet, wobei es tausenderlei Ursachen geben kann.

Die meisten Entwickler haben höchst selten JTAG-Scan-Ketten zu decodieren. Wenn sich diese Aufgabe aber stellt, dann ist sie hochkomplex, fehleranfällig und zeitraubend. Ein Ingenieur mit einschlägiger Erfahrung auf diesem Gebiet weiß, wie schwierig die Decodierung der JTAG-Daten ist.

Angesichts ihrer Komplexität kann ihn eine solche Aufgabe wochenlang beschäftigen. Normalerweise beginnt er damit, Signale von allen vier JTAG-Leitungen auf einem Logikanalysator oder Oszilloskop zu erfassen und dann diese kryptische Information manuell zu entziffern. Die Decodierung von JTAG birgt verschiedene Herausforderungen. Ein Blick auf eine JTAGScan- Kette verdeutlicht die Komplexität des Vorgangs.

 Bei den meisten seriellen Bussen wie z.B. I2C, SPI und RS 232 lassen sich die Daten von vorne nach hinten oder von hinten nach vorne decodieren. Es ist auch möglich, einen Teil der Daten unabhängig vom Rest der Übertragung zu decodieren. Bei JTAG geht das nicht so einfach, JTAG ist komplexer.

JTAG wird aufgrund seines Aufbaus allgemein als serieller Bus verstanden. Er besteht aus vier Signalen – TCK (Test Clock), TMS (Test Mode Select), TDO (Test Data Output) und TDI (Test Data Input). Manchmal kommt ein fünftes Signal TRST (Test Reset) dazu. Der JTAG-TAP (Test Access Port) kennt 16 verschiedene Zustände, jeder davon hängt vom vorhergehenden Zustand und der Signalflanke von TMS ab. Um manuell JTAG-Signale zu decodieren, die mit einem her- kömmlichen Logikanalysator oder Oszilloskop aufgezeichnet wurden, muss zunächst der Anfangspunkt für die Analyse gefunden werden – ein Reset oder Leerlauf des TAP-Controllers –, um sich von dort aus von TAP-Zustand zu TAP-Zustand vorzuarbeiten. Die Signale auf JTAG-Scan-Ketten lassen sich nicht einfach aufzeichnen und dann von jedem beliebigen Zeitpunkt an decodieren. Die Decodierung ergibt nur dann einen Sinn, wenn der zurückliegende Verlauf des TMS-Signals mit erfasst und decodiert wird, um so den aktuellen Zustand des JTAG-TAP-Controllers zu kennen (Bild 1).

Die Komplexität des TAP-Controllers ist ein Grund dafür, dass das JTAG-Protokoll so schwierig zu lesen ist. Ein zweiter Grund, der die Decodierung von JTAG schwierig macht, ist, dass die JTAG-Scan-Kette eine beliebige Anzahl von Bauteilen aufweisen kann. Die Bauteile können auch in beliebiger Reihenfolge aufeinander folgen. Und jedes Bauteil hat seine eigenen Opcodes. Ohne zusätzliche Kenntnis über die genaue Art der Bauteile in der Kette, die Reihenfolge der Bauteile und der Opcodes jedes Bauteils ist eine korrekte Decodierung des JTAG-Protokolls unmöglich. Es kann durchaus sein, dass die Daten auf der Scan-Kette das dritte Bauteil von zwölfen anweisen, dass es einen Test durchführen und die Ergebnisse über die Scan-Kette zurückmelden soll. Die Scan-Kette enthält dann Befehls- und Datenregisterwerte, die spezifisch sind für dieses eine Bauteil. Jedes Bauteil hat seinen eigenen Befehlssatz mit Opcodes in einer für jedes Bauteil spezifischen Länge.

Um das JTAG-Protokoll manuell zu decodieren, sind die TAP-Controller-Zustände mitzuzählen. Außerdem sind bauteilspezifische Informationen über dieses spezielle Bauteil notwendig, und die Reihenfolge der Bauteile auf der Scan-Kette muss bekannt sein. Und selbst dann ist es eine Herkules-Aufgabe, die in Echtzeit natürlich nicht zu schaffen ist. Manche Entwicklerteams schreiben da lieber ein eigenes JTAG-Decodierprogramm, um die Daten für eine ganz bestimmte Scan-Kette zu decodieren. Das braucht aber Zeit – meistens hat man keine – und erfordert, dass sich das Team in ein Gebiet „einfuchst“, in das es sich eigentlich nicht einarbeiten möchte.