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
