Erstmals eine Frage aus meiner Arbeitswelt: Wir haben einen proprietären Prozessorkern, den wir gerade um JTAG-Ketten erweitern, um debuggen zu können. Toolchain ist gcc und gdb. Wir werden wohl einen Daemon programmieren, der als gdb-Stub fungiert und sich die geeigneten JTAG-Sequenzen zusammenbaut. Nun suchen wir ein geeignetes JTAG-Debugger-Kästchen, das uns die JTAG-Sequenzen pumpt, mit möglichst "anständiger" Geschwindigkeit. Anschluß an USB halte ich für sinnvoll. Gibt es da geeignet generische Hardware, mit der man alles machen kann, für das Schnittstellen unter Linux existieren? Macraigor kenne ich schon, vielleicht eignet sich auch was anderes? Es sollte halt low-level genug sein, um irgendwie den JTAG-Traffic durchzureichen. Prozessorspezifische Eigenintelligenz ist nicht gefordert, wir wollen das nur benutzen, nicht Firmware oder FPGAs darin anpassen müssen.
Hallo Jörg, FTDI FT2232 basierte JTAG Interfaces gibt es mittlerweile von einer Reihe von Herstellern. ARM Debugging mit diesen Interfaces wird vom OpenOCD und Rowley's Crossworks unterstützt. Die Dokumentation von FTDI ist ausreichend, um über die MPSSE das JTAG Protokoll zu implementieren. Wiggler sind einfache parallelport Interfaces die ebenfalls von verschiedenen kommerziellen und freien Programmen zum Debuggen und Flashen verwendet werden. Da ein Wiggler nur zum BitBanging eingesetzt wird lässt sich das Protokoll ebenfalls leicht implementieren. Andere JTAG Interfaces sind in der Regel proprietär. Ob es für deine speziellen Anforderungen möglich ist, an die Dokumentation zu kommen, hängt wohl vom einzelnen Hersteller (Keil, Segger, Rowley) ab. Gruß, Dominic
Interessante Ansätze, vielen Dank. Segger und Amontec könnten in Frage kommen, Keil und Rowley machen doch eher in Compiler? Bei FTDI FT2232 dachte ich erstmal an Seriell-Umsetzer, potentiell langsam. Aber der Chip scheint ja auch für mehr vorbereitet zu sein, limitiert erst durch den 12 MBit-USB-Modus.
Das interessante am FT2232 ist dessen MPSSE (multiprotocol serial engine), mit der auch SPI, I²C und eben die für JTAG erforderlichen Bitwackeleien in Hardware unterstützt werden.
Ja, habe ich gesehen, das meinte ich. Trotzdem würde ich das als Low-End Lösung ansehen, auf 6 MHz beschränkt. Ein Maccraigor usb2Demon macht 20 MHz, in der Klasse würde ich mich lieber bewegen, also falls ihr noch solche Kästchen kennt bin ich für Tipps dankbar. ;-) Ob das in der Praxis so ankommt weiß ich nicht, es kommen ja u.A. noch erhebliche USB-Latenzen dazu. Wir wollen gerne das Remote File I/O Protokoll vom gdb unterstützen, mit möglichst hohem Durchsatz.( Wir haben oft mit größeren Datenmengen zu tun.)
> Interessante Ansätze, vielen Dank. Segger und Amontec könnten in Frage > kommen, Keil und Rowley machen doch eher in Compiler? Beide bieten auch Debugger mit passendem JTAG Interface an. Keil verwendet dafür den U-Link(2), Rowley den CrossConnect. > Bei FTDI FT2232 dachte ich erstmal an Seriell-Umsetzer, potentiell > langsam. Aber der Chip scheint ja auch für mehr vorbereitet zu sein, > limitiert erst durch den 12 MBit-USB-Modus. Die erste Grenze stellt wohl der maximale Takt von 6MHz dar. In der Praxis erreiche ich bei ARM7/9 etwa 2MHz "effektiv", inklusive Wartezeiten zwischen einzelnen, kleineren Scans, aber ohne Latenz-Effekte. Damit sind beim ARM Transferraten von bis zu 120KB/s in's Target RAM möglich. Ob ein höhrer Takt tatsächlich einen Vorteil bringt hängt wohl v.a. von der Debug Architektur ab. Sobald USB Latenzen eine Rolle spielen ist es mit der Performance onehin vorbei. Um das zu vermeiden benötigt entweder das JTAG Interface Eigenintelligenz oder das Debug Protokoll des Targets muss quasi "shoot-and-forget" bieten, sprich der Debugger schickt einfach Daten so schnell er kann, und das Target kommt garantiert mit bzw. erkennt Overflows. > Wir wollen gerne das Remote File I/O Protokoll vom gdb unterstützen, mit > möglichst hohem Durchsatz.( Wir haben oft mit größeren Datenmengen zu > tun.) Bisher habe ich solche Funktionalität entweder via "Shared Memory" oder einem speziellen Debug Kanal gesehen. Bei der shared memory Variante einigen sich Host und Debugger auf einen Speicherbereich der dann quasi für Remote Procedure Calls verwendet wird. Beim Debug Kanal existiert ein Hardware-spezifischer Kommunikationskanal (z.B. ARM7/9 DCC), der es dem Debugger erlaubt mit der laufenden Hardware zu kommunizieren. Die genaue Ausgestaltung und v.a. der erreichbare Durchsatz hängt stark vom Debug Support im Target ab. Gruß, Dominic
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.