www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik welches JTAG-Kästchen nehmen für Eigenentwicklung?


Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Dominic R. (dominic)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.)

Autor: Dominic R. (dominic)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.