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.
:
Bearbeitet durch User
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 |
8 | with other devices. |
(http://processors.wiki.ti.com/index.php/JTAG_%28MSP430%29) Auch wenn Dein Vergleich von JTAG/Ethernet eine schöne Vorstellung ist, so bleibt sie ein unrealistischer Traum.
@ 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.
:
Bearbeitet durch Moderator
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-1 https://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.
:
Bearbeitet durch User
@Christoph Kessler - 01.02.2016 Der Link http://www.bsdl.info/index.htm ist tot! - Schade ... Grüsse aus Berlin PSblnkd
Da bleibt immer noch archive.org: https://web.archive.org/web/20150510153942/http://bsdl.info/index.htm
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.
https://github.com/travisgoodspeed/goodfet/tree/master/client da liegen die Python-Files für diverse Mikrocontroller z.B. "GoodFETclient to interface zigduino/atmel128 radio" https://github.com/travisgoodspeed/goodfet/blob/master/client/GoodFETatmel128.py
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.