Hallo zusammen,
gerade im Hobbybereich werden oft verschiednen, für die Anwendung
passende Controller verwendet. Zum probieren und basteln kaufe ich
Controller unterschiedlichster Hersteller, um Erfahrung zu sammeln und
spezielle Funktionen zu realisieren.
Nun ist es ja so, dass viele Hersteller ihre JTAG-Library nicht offen
legen. Dies führt dazu, dass man für nahezu jeden Controller bzw. jeden
Hersteller einen JTAG-Adapter benötigt.
Gibt es dennoch einen JTAG-Programmier/Debug-Adapter, welcher nahezu
alle Hersteller und Chips abdecken kann? Als µC verwende ich z.B. einige
Atmel-Controller, den MSP430 von TI, den C5000, CPLDs von Xilinx, FPGA
von Lattice. Das ganze darf auch etwas kosten, wenn dadurch dann das
Gewirr an unterschiedlichsten Adaptern entfällt.
MfG
Stefan
Stefan schrieb:> Gibt es dennoch einen JTAG-Programmier/Debug-Adapter, welcher nahezu> alle Hersteller und Chips abdecken kann?
Segger J-Link, für zuhause reicht der J-LINK EDU, kostet um die 50EUR.
Du kannst aber auch bei ebay gucken.
rgds
Stefan schrieb:> Gibt es dennoch einen JTAG-Programmier/Debug-Adapter, welcher nahezu> alle Hersteller und Chips abdecken kann?
Nein, jedenfalls nicht fürs Debuggen. Das ist nicht normiert.
Georg
Der Beeprog2 hat einen 20-poligen Flachkabelanschluss für viele
Hersteller mit Hilfe-File zur Belegung.
http://www.elnec.com/en/products/universal-programmers/beeprog2/
Die Software läuft als Demo auch ohne Gerät.
Allerdings 1.249,59 € bei Conrad Nr. 155153
Rufus Τ. F. schrieb:> Damit kann man MSP430 bearbeiten?
Nein.
Jörg W. schrieb:> Oder AVRs?
Nein.
Stefan schrieb:> den C5000, CPLDs von Xilinx, FPGA> von Lattice.
Und die auch nicht.
6a66 schrieb:> Segger J-Link, für zuhause reicht der J-LINK EDU, kostet um die 50EUR.> Du kannst aber auch bei ebay gucken.
Supported CPUs
J-Link works with any of the following CPU cores:
ARM7/9/11
Cortex-A5/A8/A9
Cortex-M0/M0+/M1/M3/M4/M7
Cortex-R4/R5
Microchip PIC32
Renesas RX110, RX111, RX113
Renesas RX210, RX21A, RX220
Renesas RX610
Renesas RX621, RX62G, RX62N, RX62T
Renesas RX630, RX631, RX63N, RX63T
Sven L. schrieb:> Schau Dir mal das USBProg 5.0 an...>> http://www.usbprog.org
Supported processors: ARM (JTAG, SWD), AVR (ISP,PDI), XMega (PDI)
Christoph K. schrieb:> Der Beeprog2 hat einen 20-poligen Flachkabelanschluss für viele> Hersteller mit Hilfe-File zur Belegung.> http://www.elnec.com/en/products/universal-programmers/beeprog2/> Die Software läuft als Demo auch ohne Gerät.
48-pins powerful pindrivers, no adapter required for any DIL devices
ISP connector for in-circuit programming
Naja, immerhin habt ihr euch bemüht. Nur helfen tut es keinem.
Stefan schrieb:> Gibt es dennoch einen JTAG-Programmier/Debug-Adapter,
Nein.
Moin,
Der Segger-Kram ist definitiv nix universelles, aber danke trotzdem für
die Werbung.
Die meisten setzen auf den FT2232(D/H) für die einfachen
Programmier/Debug-applikationen. Die Hardware ist dieselbe, und die
Software muss man sich halt zusammenstückeln.
Gerade für msp430 und AVR habe ich allerdings, als es aktuell war, nix
fertiges gefunden und musste den HAL oder HIL selber hacken.
Dafür sind die Xilinx, Lattice und ARM-Sachen gut abgedeckt, zumindest,
wenn man unter Linux arbeitet.
Grüsse,
- Strubi
Rufus Τ. F. schrieb:> 6a66 schrieb:>> Segger J-Link>> Damit kann man MSP430 bearbeiten?
Asche auf mein Haupt!
Kann er nicht genauso wenig wie die AVRs.
War ich wohl zu voreilig, und Werbung wollte ich keine machen :(
Sorry!
rgds
Was dem Wunsch des TE wohl noch am nächsten käme wäre Lauterbach.
AVR8 kann der aber wohl auch nicht (scheint erst bei AVR32 los zu gehen)
und der Preis ist für den Hobbybereich natürlich auch jenseits von Gut
und Böse.
Man bräuchte eine Art Super-Treiber, der nach oben hin alle
verschiedenen Treibermodelle der verschiedensten Software adaptiert und
nach unten hin eine einheitliche Hardwar anspricht. Denn auf der
Hardware-Ebene sind ALLE JTAG-Adapter gleich, die State Machine vom JTAG
ist standardisiert. Dann könnte man mit eine Programmieradapter fast
alle Software nutzen.
Aber der Aufwand für so einen Treiber ist groß. Fast genauso groß wie
die Softwarehersteller zur Nutzung eines gemeinsamen Low Level Treibers
zu überzeugen.
Falk B. schrieb:> Denn auf der> Hardware-Ebene sind ALLE JTAG-Adapter gleich, die State Machine vom JTAG> ist standardisiert.
Das hat bloss fürs Debuggen überhaupt nichts zu sagen, da kocht jeder
Hersteller sein eigenes Protokoll. Aber soweit waren wir schon längst.
Georg
@ Georg (Gast)
>> Denn auf der>> Hardware-Ebene sind ALLE JTAG-Adapter gleich, die State Machine vom JTAG>> ist standardisiert.>Das hat bloss fürs Debuggen überhaupt nichts zu sagen, da kocht jeder>Hersteller sein eigenes Protokoll. Aber soweit waren wir schon längst.
Nö, denn auch der Debugger muss durch die normale JTAG- State Machine
rein. Und eben DAS ist überall gleich!
Falk B. schrieb:> Nö, denn auch der Debugger muss durch die normale JTAG- State Machine> rein. Und eben DAS ist überall gleich!
Ja und? Dann kannst du Hardware prüfen oder I/O-Ports lesen oder was in
einen Speicher schreiben, aber noch lange nicht was Debuggen. Zumindest
wenn man unter Debuggen mehr versteht als Speicherplätze zu lesen und zu
schreiben.
Georg
@Georg (Gast)
>> Nö, denn auch der Debugger muss durch die normale JTAG- State Machine>> rein. Und eben DAS ist überall gleich!>Ja und?
Nichts na und! Darum geht es! Die untersten Schichten universell
ansprechen, das sie schon per Hardware immer gleich sind!
>einen Speicher schreiben, aber noch lange nicht was Debuggen. Zumindest>wenn man unter Debuggen mehr versteht als Speicherplätze zu lesen und zu>schreiben.
Darum geht es gar nicht!
Vergleich. JTAG ist so ählich wie Ethernet, es stellt die physikalische
Schicht und Bitübertragungsschicht zur Verfügung, siehe
OSI-Schichtenmodell. Alle Ethernetkarten arbeiten zusammen. Und alle
Ethernetkarten stellen nach oben, zu höheren Schichten, eine IDENTISCHE
Schnittstelle zur Verfügung! Damit kann dann TCP/IP, UDP, FTP etc. alles
drüber laufen und die HÖHEREN Funktion umsetzen. Die darunterleigende
Hardware ist gleich! Capice?
Wenn Ethernet wie JTAG wäre, bräuchte man für TCP/IP eine andere
Netzwerkkarte als für FTP!!!
Falk B. schrieb:> Nichts na und! Darum geht es! Die untersten Schichten universell> ansprechen, das sie schon per Hardware immer gleich sind!
Sind sie zumindest beim MSP430 eben nicht. Sieh Dir dazu die
Auslassungen von TI an:
1
However this JTAG interface is not 100% IEEE 1149.1 (JTAG) compatible.
2
For example none of the MSP430 devices has Boundary Scan Cells. We only
3
support the required command BYPASS, but don’t support the other required
4
commands for example EXTEST and SAMPLE/PRELOAD.
5
6
Therefore there is no BSDL file for any MSP430 devices.
7
In addition you can not put a MSP430 into a JTAG chain together
@ Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
>> Nichts na und! Darum geht es! Die untersten Schichten universell>> ansprechen, das sie schon per Hardware immer gleich sind!>Sind sie zumindest beim MSP430 eben nicht. Sieh Dir dazu die>Auslassungen von TI an:>However this JTAG interface is not 100% IEEE 1149.1 (JTAG) compatible.
MÖÖÖÖP!!! Gehe ins Gefängnis. Gehe direkt dorthin. Ziehe keine 4000
Dollar ein!
>For example none of the MSP430 devices has Boundary Scan Cells. We only>support the required command BYPASS, but don’t support the other required>commands for example EXTEST and SAMPLE/PRELOAD.
Auch damit kann eine universelle Hardware laufen, denn Bypass reicht, um
diese Ebene zu verarbeiten. Dann ist aber auch der JTAG-Port für
Testzwecke nutzlos und die Bezeichnung JTAG irreführend!
>Therefore there is no BSDL file for any MSP430 devices.>In addition you can not put a MSP430 into a JTAG chain together>with other devices.
Jaja, die lieben Süppchen, die da alle kochen.
>Auch wenn Dein Vergleich von JTAG/Ethernet eine schöne Vorstellung ist,>so bleibt sie ein unrealistischer Traum.
I have dream!
;-)
Mag sein, aber es ist kein technisches Problem, es ist ein
organisatorisches. Das babylonische Sprachgewirr gab es auch in vielen
anderen Bereichen und wurde irgendwann mal, als die Not groß war oder
was auch immer, mehr oder minder sinnvoll standardisiert. Denk nur mal
an die Zeiten, als ein Byte noch nicht immer 8 Bit hatte, oder als es
noch 25, 30 sonstwas Hertz Stromversorgung gab etc., etc. Oder ganz
einfaches Konsumer-Beispiel. Die endlos vielen verschiedenen Stecker und
Spannungen für Handladegeräte. Da ist man mittlerweile beim
Quasistandard Micro-USB. Geht doch!
Klar, die Notwendigkeit und der Leidensdruck sind bei JTAG anscheinend
noch nicht groß genug.
Das gleich Drama gibt es beim Thema IC-Packages. Alle Hersteller liefern
tolle Datenblätter, wo bisweilen nur der IC selber beschrieben ist,
nicht aber das empfohlende Design für das Package. Dann sitzen 10.000
Leute und erstellen das alles in ihrem CAD-System neu. Und das im Jahr
2016, viele Jahre nach dem Jamba-Klingelton-Download-Wahnsinn ;-)
Dort hätte man längst eine Standardformat etablieren können, mit dem
sich per Click ein Package in ein CAD-System importieren läßt. Naja, so
werden Arbeitsplätze gesichert . . .
Falk B. schrieb:> I have dream!
Statt zu träumen solltest du dich besser informieren. Beim JTAG liegst
du zu 100% daneben - es sind ja auch keineswegs alle USB-Geräte
kompatibel und mit einem einzigen Treiber anzusprechen, nur weil sie
alle die USB-Schnittstelle benutzen. Und schon bei V24 war das so, mein
Hitex-Emulator für Z80 läuft über V24, aber deswegen kann er noch lange
nicht einen 6800 emulieren, obwohl es dafür auch einen Emulator mit V24
gibt.
Falk B. schrieb:> Das gleich Drama gibt es beim Thema IC-Packages.
Genauso daneben - das gibt es längst, heisst IPC-7351. Allerdings nicht
für Amateur-Software wie Eagle, und überhaupt kann jeder Layouter das
benutzen oder eben nicht. Ich erstelle einen Footprint für TQFP-100 mit
den bordeigenen Mitteln etwa genauso schnell, und dass einen
IPC-Footprint auch jemand anders nutzen könnte ist für mich irrelevant.
Aber wenn man nur will (und informiert ist), dann geht das.
Georg
@Georg (Gast)
>> I have dream!>Statt zu träumen solltest du dich besser informieren.
Und du besser zuhören und nachdenken!
> Beim JTAG liegst>du zu 100% daneben - es sind ja auch keineswegs alle USB-Geräte>kompatibel und mit einem einzigen Treiber anzusprechen, nur weil sie>alle die USB-Schnittstelle benutzen.
Wollen wir wetten, dass ALLE USB Geräte sich auf unterster Ebene an die
USB-Spec halten MÜSSEN und das auch tun? Ströme, Spannungen,
Leitungscodierung, Frames etc? Man kann JEDES USB-Gerät an JEDEN USB-Hub
anschließen, und er wird auch erkannt. Ob es dann dafür einen High Level
Treiber gibt, ist eine ganz andere Frage!
>Und schon bei V24 war das so, mein>Hitex-Emulator für Z80 läuft über V24, aber deswegen kann er noch lange>nicht einen 6800 emulieren, obwohl es dafür auch einen Emulator mit V24>gibt.
Du willst es nicht verstehen. Das sind Funktionen einer HÖHEREN Ebene,
die NATÜRLICH immer verschieden sind! Aber die elekrischen Pegel sowie
das UART-Datenformat ala 8N1 sind IDENTISCH!!!
>> Das gleich Drama gibt es beim Thema IC-Packages.>Genauso daneben - das gibt es längst, heisst IPC-7351.
Nur nutzt die kaum einer!
> Allerdings nicht>für Amateur-Software wie Eagle, und überhaupt kann jeder Layouter das>benutzen oder eben nicht. Ich erstelle einen Footprint für TQFP-100 mit>den bordeigenen Mitteln etwa genauso schnell,
Wollen wir wetten, daß du für ein TQFP 100 deutlich mehr als 3 Clicks
und 5s brauchst?
> und dass einen>IPC-Footprint auch jemand anders nutzen könnte ist für mich irrelevant.
Jaja, der liebe Egoismus. Feilst du deine Schrauben auch selber?
Standardisierung ist echt doof!
Falk B. schrieb:> MÖÖÖÖP!!! Gehe ins Gefängnis. Gehe direkt dorthin. Ziehe keine 4000> Dollar ein!
Teufel!! Jetzt geht's aber los hier...
Hast Du ein Clone-Experiment aus Cyblord und C-Hater unter Beihilfe des
Laberkopfes gemacht?
Falk B. schrieb:> Du willst es nicht verstehen. Das sind Funktionen einer HÖHEREN Ebene
Das war doch genau die Frage, ob es einen Programmer/Debugger gibt für
alle Controller. Das ist nicht nur ein feuchter Traum von dir, das ist
wohl einfach nur eine blödsinnige Vorstellung.
Falk B. schrieb:>>Genauso daneben - das gibt es längst, heisst IPC-7351.>> Nur nutzt die kaum einer!
Ja und? Daraus könnte man schliessen, dass dein Traum eben garnicht so
traumhaft ist, weil er in der Praxis nicht das bringt was du erwartest -
was ohnenhin nur auf deiner völligen Ahnungslosigkeit darüber beruht.
Der Rest der Welt besteht nicht nur aus Falk-Jüngern und Brunneristen,
die meisten haben wohl ganz andere Träume, und deine Meinung, was nicht
deiner persönlichen Ansicht zu JTAG entspricht, dürfte garnicht JTAG
heissen, ist nichts als schlichter Grössenwahn.
Georg
@Georg (Gast)
>Der Rest der Welt besteht nicht nur aus Falk-Jüngern und Brunneristen,
Schade ;-)
>die meisten haben wohl ganz andere Träume, und deine Meinung, was nicht>deiner persönlichen Ansicht zu JTAG entspricht, dürfte garnicht JTAG>heissen, ist nichts als schlichter Grössenwahn.
Nö, sondern mit Sachkenntnis. Den JTAG heißt nun mal Joint Test Action
Group und der JTAG Port wurde ursprünglich mal nur zum TESTEN von IO
Pins gemacht, die Programmierung und das Debuggen kamen erst später
hinzu. Wenn also heute ein JTAG Port OHNE Testfunkionalität als JTAG
bezeichnet wird, ist das schon ulkig. So, als ob man mit einem
SmartPHONE nicht mehr telephonieren könnte (naja, man arbeitet dran ;-)
Die Eingangsfrge des OP ist längst beantwortet und meine Beiräge gingen
in eine ganz andere Richtung. Aber mit so viel Schaum vorm Mund wie du
kann man das natürlich nur schwer erfassen.
Falk B. schrieb:> Wenn also heute ein JTAG Port OHNE Testfunkionalität als JTAG bezeichnet> wird, ist das schon ulkig.
Nicht erst heute, war beim MSP430 schon immer so.
Andererseits bewegt sich die Welt ohnehin gerade weg von JTAG*). Die
Xmegas haben ihr PDI, ARM sein SWD, teils zwar immer noch JTAG, aber
teils eben auch schon nichtmal mehr das.
Ja, die Welt könnte schöner sein, ist sie eben nicht.
Eine JTAG-Chain fürs Debuggen ist auch nur bedingt hübsch: JTAG kann
nur einen Master haben, wenn du aber zwei Prozessoren in der Chain
gleichzeitig debuggen willst, müsste der Master dann noch beide
Prozessoren (gar noch von unterschiedlichen Herstellern?) gleichzeitig
debuggen können.
*) Bezüglich des Debuggings. Bezüglich des Platinentests hat es sicher
nach wie vor seine Berechtigung.
Georg schrieb:> Falk B. schrieb:>> Du willst es nicht verstehen. Das sind Funktionen einer HÖHEREN Ebene>> Das war doch genau die Frage, ob es einen Programmer/Debugger gibt für> alle Controller. Das ist nicht nur ein feuchter Traum von dir, das ist> wohl einfach nur eine blödsinnige Vorstellung.
Du hast es immer noch nicht begriffen. Lies den Eröffnungspost. Ach was,
lies einfach nur den Betreff dieses Threads. Wo geht es da darum, daß
alles mit der gleichen Software erledigt werden soll?
Es geht um einen universellen JTAG-Adapter. Also um die Hardware und die
unterste Treiberschicht. Daß höhere Ebenen für unterschiedliche Aufgaben
dann unterschiedlich sein müssen, spricht doch in keinster Weise
dagegen, die unteren Ebenen zu standardisieren. Genauso wie das eben bei
USB auch ist. Eine standardisierte Hardware, ein standardisierter
Low-Level Treiber und oben drüber dann spezifische Treiber/Schichten.
Hallo,
was das Programmieren oder Debuggen von IEEE1149.x unterstützenden ICs
angeht, macht jeder Hersteller was er will, hält sich aber (meißt) an
den Standard IEEE1149.1. Darin ist u.a. die "untere" Schicht, also der
Transport von Befehlen und Daten über den 4 oder 5 adrigen Testbus
definiert. Die Standardregister sind im Standard IEEE1149 beschrieben.
Herstellerspezifische Register zum Debuggen oder Programmieren können
unter Einhaltung des Protokolls (TAP-State-Machine) adressiert,
beschrieben und gelesen werden. In BSDL-Modellen sind diese Register oft
erwähnt, aber nicht näher beschrieben, weil das die Internas zur
Programmierung zum Debuggen offenlegen würde.... Diese Informationen
kann ich zwar nicht liefern, aber eine Maschine, die den Zugriff auf
jedes Register eines jeden IEEE1149.x unterstützenden ICs erlaubt:
http://www.blunk-electronic.de/de/produkte.html
Damit ist der Weg zum Reverse-Engineering eröffnet. Die Software zum
Importieren von Netzlisten, BSDL-Modellen und zum Generieren von
Testvektoren ist OpenSource (In Ada 2005). Eine Erweiterung zum
Adressieren der herstellerspezifischen Register halte ich für absolut
machbar. Die Quellen sind hier:
https://github.com/Blunk-electronic/M-1https://github.com/Blunk-electronic/lbr_ada
Zum Tracen des Testbusses eignet sich evtl. dieses Gerät:
http://www.blunk-electronic.de/products/hw/logic_scanner/Logic_Scanner_UM.pdf
(Quellen werden evtl. freigegeben)
Ein Beispiel-Szenario der Vergangenheit habe ich in
http://www.blunk-electronic.de/ise/howto_erase_XC9500.pdf und
http://www.blunk-electronic.de/ise/erase_sectored_fast.svf dokumentiert.
Im genannten SVF ist erkennbar, wie mit den "nicht-dokumentierten"
Registern gespielt wird.
Ich hatte nur auf "Programmieren" und nicht das "Debuggen" geachtet.
Programmer für den JTAG-Port finden sich noch am ehesten, die zweite
Anwendung, Boundary scan, wurde nur bisher kurz gestreift, und zum
Debuggen scheint es wirklich nichts universelles zu geben.
Wenn man in einer verwunschenen Ecke der Herstellerwebsite endlich ein
passendes BSDL-File gefunden hat - die sind immer gut versteckt - geht
die Bastelei erst los.
(Es gbt auch noch eine herstellerübergreifende Seite
http://www.bsdl.info/index.htm
da ist eher was zu finden.)
Ein übliches IC, z.B. TQFP 100 enthält ein Boundary-Scan-Schieberegister
mit deutlich über 300 Bit, da für jeden Pin mindestens ein Input-/
Output und Direction-Bit definiert sind. Um nur mit einem Pin zu
klappern muss man per bit-banging jeweils diese >300 bit reinschieben.
So einen unsinnigen JTAG-Port wie beim MSP430 kenne ich auch von Renesas
SH2, der läßt sich praktisch nur auf Durchzug stellen.
Bin gerade auf den hier gestoßen: https://www.adafruit.com/products/1279
Der scheint alles mögliche zu können und hat Unterstützung für AVR
Debugging und OpenOCD.
Sehr interessant, aber ich habe noch kein Beispiel gefunden wie man
damit wirklich einen AVR debuggt, deshalb kaufe ich erstmal noch nicht.
Aber wenn das Ding wirklich alles kann was es verspricht, sind die 50€
fair.
