Hallo, ich habe zwar schon oft mit JTAG Debuggern gearbeitet, dennoch interessiert mich jetzt mal generell ihre Funktionsweise: Man hat ja immer ein Hardware-Dongle und passende Software dazu. Zum Beispiel -OpenOCD und FT2232 USB Chip -oder Lauterbach Trace32 und Lauterbach Hardware + passendes Dongle für Cortex-M oder Cortex-A. Meine Frage: Die Software (Trace32 oder OpenOCD) muss ja immer wissen, um welchen COntroller es sich handelt, da ja die JTAG-Module (oder heißen sie Ports) in verschiedenen Chips immer anderst angeordnet sind, richtig? Die Software steuert also, wie die JTAG-Abfragen/Setzungen im Chip ablaufen? Warum aber braucht man immer spezielle Hardware-Dongles für verschiedene Chips, es ist doch immer JTAG? Und das sogar zwischen ARMs unterschiedlich (Lauterbach für Cortex-M und Cortex-A). Wie kommt das denn? Vielen Danke für eure Antworten
:
Bearbeitet durch User
Die unterschiedlichen JTAG-Adapter sind erforderlich, weil deren Programmierschnittstellen (also die Art und Weise, wie sie von PC-Software anzusteuern sind) zum jeweils verwendeten Programm passen müssen. Theoretisch wäre es möglich, das zu vereinheitlichen, praktisch aber kocht (fast) jeder Softwarehersteller sein eigenes Süppchen, so daß unterschiedliche Adapter dabei herauskommen. Das allem zugrundeliegende JTAG-Protokoll ist zwar standardisiert, aber die darüber transportierten Inhalte sind prozessorabhängig und oft genug auch nicht dokumentiert, bzw. lange Zeit undokumentiert geblieben. So hat z.B. TI lange Zeit das JTAG-Protokoll der MSP430 nicht offengelegt, und Atmel hat soweit ich weiß das JTAG-Protokoll der 8-Bit-AVRs bislang auch nicht offengelegt. Naja, und so kommt es, daß jeder Debuggerhersteller halt nach seinen Softwarevorstellungen sich einen JTAG-Adapter gebastelt hat und den so ansteuert, wie er das für richtig hält -- natürlich ist auch diese Ansteuerung des Adapters (also das verwendete USB-Protokoll) nicht dokumentiert. Das war zu Zeiten des Frickelports auch nicht besser; vergleicht man den "Wiggler" von Macraigor (der z.B. für einige ARMe genutzt werden konnte) mit dem MSP-FET430-PIF, so ist zwar Ähnlichkeit, aber doch auch viel unterschiedliches zu erkennen, nicht nur beim JTAG-Stecker selbst (20polig bei ARM, 14-polig bei MSP430).
@ Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite >Theoretisch wäre es möglich, das zu vereinheitlichen, praktisch aber >kocht (fast) jeder Softwarehersteller sein eigenes Süppchen, so daß >unterschiedliche Adapter dabei herauskommen. Eben! Es wäre kein großes Problem, die unterste JTAG-Schicht auf einen standardisierten Treiber zu setzen und damit quasi JEDE Hardware mit JEDER Software verbinden! Vergleichbar mit dem Ethernetprotokoll! Dort kann auch jede Software andocken! OSI-Layer 1 und 2! https://de.wikipedia.org/wiki/OSI-Modell >Das allem zugrundeliegende JTAG-Protokoll ist zwar standardisiert, aber >die darüber transportierten Inhalte sind prozessorabhängig und oft genug >auch nicht dokumentiert, bzw. lange Zeit undokumentiert geblieben. Das ist nicht wirklich das Problem! Es geht um die unterste JTAG Schicht und die ist offen! Ist der gleiche Schwachsinn wie mit den Millionen Handyladesteckern. Das hat man ja mittlerweise halbwegs einheitlich auf Micro-USB festgelegt.
Falk B. schrieb: > Es wäre kein großes Problem Es wäre kein Problem, aber es interessiert niemanden. Also, keinen Controller- und keinen Debuggerhersteller. Insofern ist jede Diskussion von höchstens akademischen Nutzen.
Um die Frage mal aufzunehmen: Ich kann also mit jedem JTAG-Adapter auf jedes JTAG-Gerät zugreifen, solange ich eine Software habe, die den JTAG-Adapter ansprechen kann und das angeschlossene Gerät kennt? Oder anders gefragt: Wenn OpenOCD meinen JTAG-Adapter kennt und auch das angeschlossene Gerät, dann geht alles prima?
:
Bearbeitet durch User
Naja dann kannst du höchstens den nach ieee1149 standardisierten Boudary Scan Test machen, aber alles andere wie Programmieren oder Debuggen macht jeder Hersteller anders. Da ist nix kompatibel. Mit der ieee1532 wollte man da einen Schritt in die Richtung gehen aber meines Wissens machen das nur ein paar FPGAs.
Ähm... gut zu erfahren. Was kann man dann eigentlich mit einem no-name-JTAG-Adapter aus China so anfangen? Ich hatte bisher angenommen dass JTAG genau so standardisiert ist wie ein USB-RS232-Adapter: Adapter+Treiber installieren, läuft mit jeder Software und jedem (von der jeweiligen Software unterstützten) Ziel, egal ob AVR,ARM oder irgend eine gebricktes Gerät mit JTAG-Stecker. D.h. man braucht in der Praxis eine größere (wie groß?) Sammlung von Adaptern um "alle" Ziele per JTAG ansprechen zu können?
@Andreas K. (andreasmc) >Ähm... gut zu erfahren. Was kann man dann eigentlich mit einem >no-name-JTAG-Adapter aus China so anfangen? Die sind meist zu bestehenden No-no-name Produkten kompatibel ;-) >Ich hatte bisher angenommen dass JTAG genau so standardisiert ist wie >ein USB-RS232-Adapter: Adapter+Treiber installieren, läuft mit jeder >Software und jedem (von der jeweiligen Software unterstützten) Ziel, >egal ob AVR,ARM oder irgend eine gebricktes Gerät mit JTAG-Stecker. Leider nein. >D.h. man braucht in der Praxis eine größere (wie groß?) Sammlung von >Adaptern um "alle" Ziele per JTAG ansprechen zu können? Leider ja.
JTAG ist eigentlich nur für Boundary Scans gedacht. Irgendwann kamen die Hersteller von µCs auf die Idee diese Schnittstelle auch zum debuggen zu benutzen. Dafür haben die Hersteller dann proprietäre Befehle implementiert, die zum Großteil nicht dokumentiert oder standardisiert sind. Daher kocht jeder Hersteller sein eigenes Süppchen.
Rufus Τ. F. schrieb: > So hat z.B. TI lange Zeit das JTAG-Protokoll der MSP430 nicht > offengelegt, und Atmel hat soweit ich weiß das JTAG-Protokoll der > 8-Bit-AVRs bislang auch nicht offengelegt. Atmel dokumentiert (für die AVRs) nur die Programmierkommandos. Dafür unterstützen sie wenigsten sauberes JTAG Chaining (auch mit beliebigen Fremd-ICs), während (so habe ich gehört) ein MSP430 nicht in einer Kette mit anderen liegen darf. Andreas K. schrieb: > Ich hatte bisher angenommen dass JTAG genau so standardisiert ist wie > ein USB-RS232-Adapter: Ist es auch. Für die Funktion des Debuggers genügt dir das aber nicht, sondern da brauchst du auch noch die Schicht obendrüber. Bei RS-232 wäre das vergleichbar mit einem darüber bedienten Monitor-ROM-Code (war früher sehr üblich), über den man das eigentliche Programm steuern kann. Solange du dessen Dokumentation nicht hast, nützt es dir nicht viel, dass du an die Monitorschnittstelle einen gut standardisierten USB-RS232-Adapter dranklemmst. https://de.wikipedia.org/wiki/Maschinencode-Monitor Bei ARMs ist die Situation entspannter (und gibt's deshalb auch einfache 3rd-party dongles), da ARM dort das Debug-Protokoll selbst normiert hat und die Spezifikation allgemein zugänglich ist. Allerdings hat sich dort mittlerweile SWD durchgesetzt: braucht nur zwei statt vier Drähten, dafür kann man keine Chains bilden.
:
Bearbeitet durch Moderator
Du könntest dir Treiber für eine JTAG-Hardware schreiben der der Software vorgaukelt die Originalhardware vom Hersteller zu sein. Diesen treiber müßtest du für alle Hersteller schreiben. Dann würde deine Hardware (oder was auch immer) in der Systemsteuerung gleichzeitig als USB-Blaster und JTAGICE3 usw. erscheinen.
uwe schrieb: > Dann würde deine Hardware (oder was auch immer) in der Systemsteuerung > gleichzeitig als USB-Blaster und JTAGICE3 usw. erscheinen. Das wird nicht gehen, denn oft genug werden die jeweiligen Softwarepakete da zuallererst nach VID:PID gucken. Du könntest dann also nur einen Umschalter am Gerät vorsehen, damit es sich mal so, mal so am Bus meldet. Die Arbeit wird sich wohl bloß keiner antun wollen, sowas zu bauen.
Kann man virtuellen Geräten nicht eine VID:PID verpassen. Diese müssen halt ein kompatibles Interface vorweisen und die Komandos über einen Übersetzungsmechanismus an die Konkrete JTAG-Hardware weiterleiten. Wenn eine Software gerade einen Virtuellen Adapter benutzt sind die anderen halt Busy und können nicht geöffnet werden.
uwe schrieb: > Kann man virtuellen Geräten nicht eine VID:PID verpassen. Geht das jetzt nicht langsam in Richtung kompletter Overkill? Was ist denn gewonnen, wenn man so ein Softwaremonster verwendet? Wer unter uns arbeitet ständig mit mehreren unterschiedlichen Prozessor- oder FPGA-/CPLD-Architekturen, daß er zig unterschiedliche Programmier- resp. JTAG-Adapter benötigt? Ansonsten: Ein Ansatz, um so etwas hinzubekommen, wäre die Verwendung eines USB-over-IP-Treibers, der statt mit einem per Netzwerk entfernt angebundenem USB-Device-Server mit virtuell angebundenen USB-Devices arbeitet. Die erforderlichen Treiber ließen sich beispielsweise hiervon http://usbip.sourceforge.net/ ableiten.
uwe schrieb: > Kann man virtuellen Geräten nicht eine VID:PID verpassen. USB Specs mal überflogen? VID:PID gibts nur pro Device. Interfaces ("Virtuelle Geräte") laufen alle mit derselben VID:PID des Geräts.
Rufus Τ. F. schrieb: > Geht das jetzt nicht langsam in Richtung kompletter Overkill? > > Was ist denn gewonnen, wenn man so ein Softwaremonster verwendet Nix, zumal OpenOCD mit einem FTDI basierten JTAG Adapter genau das schon tut. Nur untersützt OpenOCD halt nicht alle möglichen µCs, sondern nur die mit offenen Specs oder die wo der Hersteller das selbst einprogrammiert - was vermutlich so gut wie niemand getan hat. Außerdem ist JTAG extern in Hardware oft schneller weil weniger Daten über den USB Bus müssen.
Jim M. schrieb: > uwe schrieb: >> Kann man virtuellen Geräten nicht eine VID:PID verpassen. > > USB Specs mal überflogen? VID:PID gibts nur pro Device. Interfaces > ("Virtuelle Geräte") laufen alle mit derselben VID:PID des Geräts. Jaaa, aber was wenn das Gerät einen Hub simulierte? Da könnte es beliebige Geräte am Downstream erscheinen und verschwinden lassen, oder?
Luther B. schrieb: >> USB Specs mal überflogen? VID:PID gibts nur pro Device. Interfaces >> ("Virtuelle Geräte") laufen alle mit derselben VID:PID des Geräts. > > Jaaa, aber was wenn das Gerät einen Hub simulierte? Da könnte es > beliebige Geräte am Downstream erscheinen und verschwinden lassen, oder? Solche Geräte sind zumindest mir in der Praxis nicht bekannt. Was es aber gibt sind µCs mit mehr als einer USB Schnittstelle, da bräuchte es nur einen billigen USB Hub Chip zusätzlich. Der Software Entwicklungsaufwand wäre aber astronomisch. Da würde man IMO in derselben Größenordnung wie OpenOCD landen, schau Dir da mal den Umfang des Quellcodes an. Und einige Hersteller dürften ihre Specs nichtmal unter NDA rausrücken.
> USB Specs mal überflogen? VID:PID gibts nur pro Device. Interfaces > ("Virtuelle Geräte") laufen alle mit derselben VID:PID des Geräts. Begriffskollision des Wortes "Interface", ich meine kein USB-Interface. Es wird für jeden Hardwareadapter der simuliert werden soll ein eigenes Virtuelles Gerät erstellt mit VID:PID. Diese Geräte müssen das gleiche Interface (Kommunikationsfunktionen) zur verfügung stellen wie der Orriginaladapter und die gleiche VID:PID. Die Geräte senden aber ihren datenstrom zum realen JTAG Gerät.
Wir machen das. Wir emulieren einen FT2232H (FTDI Bezeichnung "MPSSE") in Software. Wir verwenden unsere eigene VID/PID, aber zumindest urJTAG kann man das beibringen. Tests mit OpenOCD stehen noch aus. Andreas
Andreas D schrieb: > Wir machen das. Wir emulieren einen FT2232H (FTDI Bezeichnung "MPSSE") > in Software. Darumg ging's ja nicht, sondern darum, dass jemand ein Gerät entwerfern will, welches JTAGICE3, Segger J-Link und was auch immer alles in einem sein soll, sodass jedes Hersteller-Softwarepaket es sofort als „sein eigenes Baby“ annehmen würde. Dass man ein VID:PID-Paar faken kann, haben uns ja die chinesischen FTDI-Clones vor einiger Zeit ganz eindrucksvoll bewiesen, und auch, wie FTDI es geschafft hat, das trotzdem rauszufinden …
Das eine Gerät kann sich ja als USB-Hub verkaufen, an dem dann die gewünschten nachgeahmten Adapter allesamt angeschlossen sind.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.