Nachdem ich nun wochenlang das Internet abgegrast habe und viel gefunden hab, bin ich in der Praxis dennoch nicht wirklich weiter gekommen. Habe mich schon an allem möglichen versucht, Software wie Hardware und auch verschiedenen JTAG-Targets. Nur ein reproduzierbares Erfolgserlebnis konnte ich noch nicht verbuchen. Das frustiert und ich denke eigentlich das ich nicht der Typ bin der so leicht aufgibt... Kennt jemand ein gutes Tutorial in dem mit einfachen, verfügbaren Mitteln JTAG ganz praktisch erklärt wird? An Interfaces habe ich einen Segger J-Link EDU, einen Olimex ARM-USB-OCD-H, einen USB Blaster (China-Clone) und natürlich div. Selbstbauteile (Mikrocontroller, Levelshifter, USB-Chips, etc.) zur Verfügung. An Software habe ich mit OpenOCD, J-Link, UrJTAG und selbst geschriebener Software experimentiert. An Targets habe ich einen Linksys WRT54GL, eine Fritzbox 7170, einen Bintec R232bw, div. Radios und Automotive-Module zur Verfügung. EVAL-Boards habe ich keine, ausser einem STM-Discovery und einem STM-Nucleo Board. Aber ich würde mir auch was zulegen, daran soll es nicht scheitern. Es gibt so viele gute Berichte im Internet wie man mittels JTAG einen Router debrickt, Bootloader überlistet, etc. Aber entweder sind die sehr allgemein gehalten oder enden nach einer vielversprechenden Einleitung. Auch meine Bemühungen hier im Forum Infos über JTAG zu bekommen sind mehr oder weniger erfolglos geblieben. Nicht weil niemand darauf geantwortet hätte, aber weil ich in der Praxis bislang immer nur Probleme hatte, aber keine Erfolge. Alles irgendwie strange...
:
> Aber ich würde mir auch was zulegen, daran soll es nicht scheitern. Das brauchst du nicht. Du hast ja bereits einen J-Link Edu und ich finde die Doku von Segger eigentlich ganz gut. Sowohl im Highlevel bereich wie auch Lowlevel (lesen von Registern, Kommunikation ueber TCP-IP mit dem Debugger). Also lad dir die PDFs durch und lies sie. > Es gibt so viele gute Berichte im Internet wie man mittels JTAG einen > Router debrickt, Bootloader überlistet, etc. Ach? Sowas gibt es? :) Dann suchst du also ein Youtubevideo das dich in 10min zu einem coolen Hacker macht? :-D Ich fuerchte da ist die Thematik etwas komplexer. Olaf
Danke Olaf, ich habe versucht das alles zu verstehen und natürlich auch in die Praxis umzuzusetzen, aber irgendwo bin ich dann wohl immer falsch "abgebogen"... Um z,b, mit j-link.exe (commander) irgendwas mit dem TAP controller machen zu können muss man erstmal ein Targetdevice wählen und und und. Also alles andere als einfach. Daher habe ich dann auch andere Software und Hardware getestet, in der Hoffnung das es besser wird, wurde es aber nicht :-/ Aus diesem Grund habe ich dann auch angefangen mir selbst Software zu schreiben und das mit einem Atmega bzw. STM32 zu tun. Ganz simples Zeug wie das auslesen des IDCODE, der Bestimmung der IR-Len, usw. Aber auch das hat immer irgendwie nur unstabile Ergebnisse gebracht und ich wusste dann nie woran es liegt, am Target, am Levelsbifter am Arduino, am Code, an mir...?! Und nein, ich suche gerade kein "How to become a hacker in 10 minutes" Video, sondern jemand der mit nachvollziehbaren Schritten beschreibt wie er von A nach B kommt. Ich denke einfach das wenn mir diese Basics fehlen, dann komme ich mit den Higherlevel Funktionen auch nicht klar. Ich habe ja mit den Segger und J-Flash bereits den Flash eines Gerätes ausgelesen, aber auch hier habe ich Probleme das auf einen anderen Adapter/Software zu transponieren und eigentlich müsste Jtag doch Jtag sein und es überall klappen...
Olli Z. schrieb: > eigentlich müsste Jtag doch Jtag > sein Rs232 muesste doch auch Rs232 sein. Aber viel viele vrerschiedene serialle Kabel gibt es?
Olli Z. schrieb: > Um z,b, mit j-link.exe (commander) irgendwas mit dem TAP controller > machen zu können muss man erstmal ein Targetdevice wählen und und und. > Also alles andere als einfach. Was willst du eigentlich genau erreichen? Einfach nur einen Controller wie z.B. einen STM32 flashen, debuggen, auslesen? Das ist mit der J-Link Software doch simpel, z.B.:
1 | JLink.exe -Device STM32F103RB -If JTAG -Speed 1000 # JLink mit richtigem Device starten |
2 | connect # Zum Device verbinden |
3 | loadbin ZuFlashendeDatei.bin, 0x08000000 # Datei flashen |
4 | h # Prozessor anhalten |
5 | r # resetten |
6 | regs # Register anzeigen |
7 | setBP 0x08001234 # Breakpoint setzen |
8 | g # Prozessor starten |
9 | h # Wieder anhalten |
10 | regs # Register anzeigen |
11 | savebin AusgelesenesImage.bin, 0x08000000 # Flash auslesen |
12 | quit # Sitzung Beenden |
Siehe ab S. 40: https://www.segger.com/downloads/jlink/UM08001 Deutlich bequemer wird's wenn man GDB nutzt:
1 | JLinkGDBServer -Device STM32F103RB -If JTAG -Speed 1000 |
Dann gdb starten:
1 | arm-none-eabi-gdb MeinProgramm.elf |
2 | target remote :2331 # Verbinden |
3 | load # Flashen |
4 | mon reset # Resetten |
5 | b main # Breakpoint setzen |
6 | c # Starten |
7 | ... |
Alternativ in einer IDE (z.B. eclipse) oder grafischem Debugger deiner Wahl (z.B. DDD) GDB starten, dann kann man grafisch durchsteppen usw. Wenn du z.B. das auf eclipse basierende Atollic Studio nutzt, kannst du mit ein paar Klicks das alles automatisch ablaufen lassen. JTAG ist ein bisschen wie Ethernet: Man kann alles möglich damit übertragen, aber nur weil man sich mit Ethernet auskennt weiß man noch lange nicht wie E-Mail, Web, Chats, ... funktionieren. Die J-Link Software abstrahiert zum Glück viele Mikrocontroller, sodass diese über eine einheitliche Nutzerschnittstelle bedient werden können.
Niklas G. schrieb: > JTAG ist ein bisschen wie Ethernet: Man kann alles möglich damit > übertragen, aber nur weil man sich mit Ethernet auskennt weiß man noch > lange nicht wie E-Mail, Web, Chats, ... funktionieren. Das ist ein sehr guter Vergleich
:
Bearbeitet durch User
Uwe B. schrieb: > Olli Z. schrieb: >> eigentlich müsste Jtag doch Jtag > Rs232 muesste doch auch Rs232 sein. Aber viel viele vrerschiedene > serialle Kabel gibt es? Damit hast Du zwar recht, hilft mir aber jetzt auch nicht wirklich weiter. Vielleicht hast Du ja noch etwas substantielles zum Thema beizutragen?
Hallo, Was willst du eigentlich verstehen / machen? Das liest sich für mich wie wenn du versuchst dir deinen eigenen JTAG Debugger (J-Link) auf basis eines Atemga / STM32 zu bauen? Olli Z. schrieb: > Aus diesem Grund habe ich dann auch angefangen mir selbst Software zu > schreiben und das mit einem Atmega bzw. STM32 zu tun. Ganz simples Zeug > wie das auslesen des IDCODE, der Bestimmung der IR-Len, usw. Aber auch > das hat immer irgendwie nur unstabile Ergebnisse gebracht und ich wusste > dann nie woran es liegt, am Target, am Levelsbifter am Arduino, am Code, > an mir...?! Für was willst du JTAG verwenden? - Software Debuggen - Boundery scann Für welchen Controller Famile wilst du mittels JTAG Debuggen? - ARM7 - CortexM3 - AVR32 - ... > Ich habe ja mit den Segger und J-Flash bereits den Flash eines Gerätes > ausgelesen, aber auch hier habe ich Probleme das auf einen anderen > Adapter/Software zu transponieren und eigentlich müsste Jtag doch Jtag > sein und es überall klappen... Ich gehe mal davon aus das du hier den Segger und J-Flash meinst. Jtag stellt nur die unterste Schicht der kommunikation dar. Zum Flash auslesen braucht es aber noch jede menge mehr. Ein Programm für den auszulesenden Kontroller, Ein Protokoll der die ausgelesenen daten übertragt, ... das ganze ist dann noch core spezifisch, ... ggf schau dir mal die ARM Documentation zum JTAG an. die fand ich eigentlich ganz brauchbar. gruss
Ben S. schrieb: > Niklas G. schrieb: >> JTAG ist ein bisschen wie Ethernet: Man kann alles möglich damit >> übertragen, aber nur weil man sich mit Ethernet auskennt weiß man noch >> lange nicht wie E-Mail, Web, Chats, ... funktionieren. > > Das ist ein sehr guter Vergleich Leider ist es aber doch nur all zu oft umgekehrt: Jemand der sich mit E-Mail, Web, Chats "auskennt" weiss nicht automatisch wie Ethernet funktioniert. Und DAS wäre der richtige Vergleich für meine Frage. Denn ich möchte erstmal diese Basics beherrschen und erst dann zu den höherwertigen Funktionen vordringen. Wer meinen ersten Post liest kann das eigentlich unmißverständlich daraus entnehmen...
Erstmal danke Niklas für Deine Beteiligung am Thema. Niklas G. schrieb: > Was willst du eigentlich genau erreichen? Einfach nur einen Controller > wie z.B. einen STM32 flashen, debuggen, auslesen? Das ist mit der J-Link > Software doch simpel, z.B.: Weder noch. Irgendwann mal, ja. Erstmal geht es mir darum ganz elementare Dinge sicher umsetzen zu können. Um beim Beispiel zu bleiben: > [code]JLink.exe -Device STM32F103RB -If JTAG -Speed 1000 # JLink mit > richtigem Device starten > connect # Zum Device verbinden Zu diesem Zeitpunkt geschieht da schon eine ganze Menge "Magie" über JTAG. Ich habe mal versucht mittels Logicanalyzer daraus schlau zu werden, was mir aber leider nicht gelungen ist. Ich finds super wenn Du das alles beherrschst und hoffe das ich diesen Zustand auch mal erreichen kann. Dann helfen mir die zitierten Beispiele sicher weiter :-) > Alternativ in einer IDE (z.B. eclipse) oder grafischem Debugger deiner > Wahl (z.B. DDD) GDB starten, dann kann man grafisch durchsteppen usw. Ja, genau sowas wäre doch für JTAG-Neulinge genau das richtige, aber eben auf JTAG-Ebene und nicht schon höher. Ich fürchte mit "Debugger" meinst Du schon einen GDB, ich wäre aber an einem JTAG-Debugger interessiert. Sprich ich sehe den Zustand der Signale vom Interface, das was ich in den TAP hineinschicke (TDI) und was ich von ihm erhalte (TDO). Das ganze im Single-Step und einer Timeline.
Olli Z. schrieb: > Wer meinen ersten Post liest kann > das eigentlich unmißverständlich daraus entnehmen... Ich leider nicht. Du möchtest also wirklich alle Details kennen, und nicht einfach nur einen Controller flashen/debuggen, wie es die meisten tun? Dafür gibt es vermutlich keine detaillierten Tutorials, weil die meisten Leute einfach eine fertige Implementation, wie eben J-Link, nutzen. Die meisten Programmierer wollen auch nicht genau wissen wie ein C-Compiler ihr Programm zerlegt, sondern nur wie man ein C-Programm schreibt. Du solltest bei ARM genaue Dokumentation zu JTAG finden. Es gibt aber Unterschiede zwischen den ARM-Controllern; jeder hat z.B. seine eigene Methode, um den Flash zu beschreiben (selbst die verschiedenen STM32Fx-Familien unterscheiden sich da). Die alle zu implementieren dürfte Arbeit sein.
Olli Z. schrieb: > Erstmal geht es mir darum ganz > elementare Dinge sicher umsetzen zu können. Was willst du denn umsetzen? Den JLink nachbauen? Dessen Preis wird irgendwie im Arbeitsaufwand dafür begründet liegen. Olli Z. schrieb: > Zu diesem Zeitpunkt geschieht da schon eine ganze Menge "Magie" über > JTAG. Ja. Olli Z. schrieb: > Ich finds super wenn Du das alles beherrschst und hoffe das ich diesen > Zustand auch mal erreichen kann Nö, ich hab mich mit den Details auch nicht auseinandergesetzt und bin froh, dass die Leute bei Segger sich darüber schon den Kopf zerbrochen haben. Besser als die kann ich das auch nicht, und ich kriege damit meine Projekte umgesetzt. Olli Z. schrieb: > Sprich ich sehe den Zustand der Signale vom Interface, das > was ich in den TAP hineinschicke (TDI) und was ich von ihm erhalte > (TDO). Das ganze im Single-Step und einer Timeline. Aber wozu? Das braucht man doch höchstens, wenn man sich seinen eigenen Mikrocontroller und eigenen TAP baut. Weil das ziemlich wenige Leute tun, wird sich kaum einer die Mühe gemacht haben, so etwas zu programmieren.
:
Bearbeitet durch User
> Ich leider nicht. Du möchtest also wirklich alle Details kennen, und > nicht einfach nur einen Controller flashen/debuggen, wie es die meisten > tun? Dafür gibt es vermutlich keine detaillierten Tutorials, weil die > meisten Leute einfach eine fertige Implementation, wie eben J-Link, > nutzen. Die gibt es sicherlich. Allerdings vom Controllerhersteller persoenlich weil die bei jedem Baustein anders sind. Deshalb muss man beim J-Link auch die Prozessorbezeichnung angeben. Ich koennte mir auch vorstellen das du da ein NDA unterschreiben musst. Olaf
Olaf schrieb: > Die gibt es sicherlich. Aber nicht in Form eines Step-By-Step Tutorials, sondern in Form einer Dokumentation. Man muss sich die Details schon selbst zusammen suchen. So ist das doch immer, wenn man die ausgetretenen Pfade verlässt... Olaf schrieb: > Ich koennte mir auch vorstellen > das du da ein NDA unterschreiben musst. Naja, bei den STM32 ist das Flashen im Reference Manual dokumentiert.
Naja, das Tutorial, das Du suchst heißt wohl: IEEE 1149.1 Das lässt sich per google als pdf finden... Alles weitere ist dann Controller-spezifisch und in den jeweiligen Manuals zu finden.
Niklas G. schrieb: > Olli Z. schrieb: >> Wer meinen ersten Post liest kann >> das eigentlich unmißverständlich daraus entnehmen... > > Ich leider nicht. Ok, dann tut es mir leid und versuche meinen Wunsch anders zu formulieren! > Du möchtest also wirklich alle Details kennen, und > nicht einfach nur einen Controller flashen/debuggen, wie es die meisten > tun? Ja, das geht in die richtige Richtung. Ob ich wirklich "alle Details" wissen will... naja, aber zumindest möchte ich verstehen was da unter der Haube läuft. > Dafür gibt es vermutlich keine detaillierten Tutorials, weil die > meisten Leute einfach eine fertige Implementation, wie eben J-Link, > nutzen. Ganz genau das ist meine Erfahrung nach stundenlangem rumsuchen im Internet über mehere Tage/Wochen! Die meisten setzen entweder "höher" an oder beschreiben das was überall an Grundlagen zu lesen ist. Aber scheinbar niemand (naja, zumindest konnte ICH nichts finden) macht ein richtig gutes, praktisches Basic-Tutorial. > Die meisten Programmierer wollen auch nicht genau wissen wie ein > C-Compiler ihr Programm zerlegt, sondern nur wie man ein C-Programm > schreibt. Da hast Du wohl recht, mich eingeschlossen. Manchmal ist es aber extrem hilfreich wenn man das weis, z.B. beim Debuggen oder Reverse-Engineering von Binärcode. > Du solltest bei ARM genaue Dokumentation zu JTAG finden. Es gibt aber > Unterschiede zwischen den ARM-Controllern; jeder hat z.B. seine eigene > Methode, um den Flash zu beschreiben (selbst die verschiedenen > STM32Fx-Familien unterscheiden sich da). Die alle zu implementieren > dürfte Arbeit sein. Sicher. Nicht ohne Grund verlangen Firmen wie Segger einen ordentlichen Betrag für ihre Produkte. Soweit will ich auch garnicht gehen.
Wobei das, was man bei google findet ist die Version von 2001. Die wurde 2013 abgelöst. Aber nachdem ich auch schon von 2013 mit JTAG Debuggern gearbeitet habe, dürfte der alte Standard duchaus noch Gültigkeit haben...
Olli Z. schrieb: > Aber > scheinbar niemand (naja, zumindest konnte ICH nichts finden) macht ein > richtig gutes, praktisches Basic-Tutorial. Das ist immer so, wenn es derart in die Tiefe geht. "Praktisch" von "praxisnah" wäre das sowieso nicht, weil dafür würde man fertige Systeme nutzen. Für wie viele Leute hätte so etwas einen praktischen Nutzen? Und "Basic" widerspricht der Komplexität des Themas. Compilerbau lässt sich auch nicht in einem "Basic Tutorial" abhandeln. Beispiel: Mein USB-Tutorial mit STM32 versucht auf viele Details einzugehen und möglichst wenig vordefinierte Software zu nutzen. Das Ergebnis: Es wird sich beschwert dass der Text zu kompliziert ist und man benutzt lieber fertige Systeme wie die VCP-Implementation von W.S. ... Ähnlich würde es einem JTAG-Tutorial ergehen.
Olli Z. schrieb: > Ja, das geht in die richtige Richtung. Ob ich wirklich "alle Details" > wissen will... naja, aber zumindest möchte ich verstehen was da unter > der Haube läuft. Diese etwas großspurige Haltung wird durch deine Suche nach einem Tutorial etwas entlarvt. Wer wissen will wie etwas "unter der Haube läuft", der nimmt sich die Primärquelle vor, in diesem Fall die Spec. Im Gegensatz zu vielen anderen Dingen im Bereich der Mikrocontroller, wird dir aber gerade DAS bei JTAG keinerlei Vorteile bringen. Es sei denn du willst deine eigene JTAG Hardware von null auf bauen und programmieren.
:
Bearbeitet durch User
Olli Z. schrieb: > Zu diesem Zeitpunkt geschieht da schon eine ganze Menge "Magie" über > JTAG. Ich habe mal versucht mittels Logicanalyzer daraus schlau zu > werden, was mir aber leider nicht gelungen ist. Was bein Debuggen ueber JTAG oder SWD passiert, kannst Du gut den den Quellen der Black Magic Debug Probe sehen https://github.com/blacksphere/blackmagic.
JTAG ist nur die Daten-Autobahn, über die Informationen transportiert werden. Die Informationen selbst und ihre Bedeutung für bestimmte Ziele sind von Interesse. Wenn ich nach Venlo fahre, um Einzukaufen, interessiert mich in erster Linie das Angebot der dortigen Händler, nicht die Autobahn. Ich werde sicher nirgends einen zusammenhängenden Ratgeber finden, der alle Ziele beschriebt, die ich theoretisch über die Autobahn erreichen könnte. Ganz ähnlich ist das auch mit JTAG. Nenne einen konkreten Chip, dann kann man Dir dazu vielleicht die passende Anleitung geben. Bei den von Dir genannten Geräten schätze ich, dass diese Infos nicht öffentlich zugänglich sind.
Fuer die STM32 gibt es Boundary Scan Description Language Files. Dort sind die CortexM3 und die STM32 Scan Taps beschrieben. Was man dann mit der CortexM3 Tap machen kann, beschreibt ARM z.B. in IHI0031
Also wenn es mich/uns hier in der Diskussion weiter bringt können wir gern am Beispiel STM32 arbeiten. Wie ich ka schrieb ist mir das Target als solches erstmal völlig egal und wenn es welche gibt die sich aufgrund ihrer Dokumentation und Verbreitung besonders eignen - warum nicht?! Sofern es halbwegs bezahlbar bleibt lege ich mir entsprechende Hardware eben zu. Im ersten Schritt hab ich halt geschaut was ich da hab. Welche STM32 Prozessoren kämen denn in Frage?
Olli Z. schrieb: > Also wenn es mich/uns hier in der Diskussion weiter bringt können wir > gern am Beispiel STM32 arbeiten. Wie ich ka schrieb ist mir das Target > als solches erstmal völlig egal und wenn es welche gibt die sich > aufgrund ihrer Dokumentation und Verbreitung besonders eignen - warum > nicht?! Aber du hast schon verstanden dass es eine Art unteren Layer gibt, nämlich JTAG, welches durch eine Spec beschrieben wird, und darauf aufbauend, jeder Hersteller sein eigenes Protokoll drüber fährt um seine Controller damit kommunizieren zu lassen. Die Frage ist nun nämlich, für welche dieser beiden Schichten interessierst du dich eigentlich?
Also wenn es mich/uns hier in der Diskussion weiter bringt können wir gern am Beispiel STM32 arbeiten. Wie ich ka schrieb ist mir das Target als solches erstmal völlig egal und wenn es welche gibt die sich aufgrund ihrer Dokumentation und Verbreitung besonders eignen - warum nicht?! Sofern es halbwegs bezahlbar bleibt lege ich mir entsprechende Hardware eben zu. Im ersten Schritt hab ich halt geschaut was ich da hab. Welche STM32 Prozessoren kämen denn in Frage? Und kennt jemand eine Jtag-Debug Software, so wie ich es oben mal als Traumvorstellung beschrieben hab? Und nochmal: ich will nix clonen, billiger nachbauen, noch brauche ich das fürs Studium oder als Hausaufgabe, es geht mir in erster Linie ums Verständnis und der praktischen Umsetzung dessen.
Die IEEE-1149.1 wurde ja schon genannt. Wenn du mal die Statemaschine verstanden hast, kannst du das mit TMS aufgebohrte SPI-Protokoll verstehen. Dann siehst du, dass prinzipiell damit ein Instruction Register / Data Register angesteuert wird, und dem Run-Test-Idle-State allenfalls eine spezielle Bedeutung zukommt, die abhängig vom TAP (also chip-spezifisch ist). Wenn du mit dem Verständnis Mühe hast, kannst du mit Hilfe des recht hübschen Java-Programms "goJTAG" auch ein BSCAN-File (BSDL, findet man oft irgendwo beim Hersteller) deines Lieblingschips einlesen und JTAG-Sequenzen im Trockendock (ohne Adapter) durchspielen, das hilft beim intuitiveren Ansatz des Verstehens. Achtung: der BSDL-Parser hatte damals zumindest Mängel und liest ev. nicht alle Dateien.
Danke! Das goJTAG werden ich mir mal genauer ansehen, es scheint das zu sein was ich suche!
Nabend, die IEEE Norm beschreibt Bei JTAG wie man mit den 3 Leitungen mit irgend jemanden reden kann. Mehr nicht. ggf noch boundery scan im ganz ganz groben. Was die Register zu bedeuten haben, wie gross diese sind, ... haben andere zu beschreiben. ARM selber beschreibt dann auf basis der Norm wie man über JTAG z.B. Mit einem ARM7 / ARM9 Core reden kann Atmel hingegen wie mit einem ATMEGA, XILINX wie mit ihren FPGAs, ... bzw wie viele reister es gibt. und was diese bedeuten. Die Meisten MCUs bilden 2 funktionen über JTAG ab. Den Bounderyscann und einmal das Core debugging. Beim Bondery scan geht die SCAN line mehr oder weniger einmal an allen pins vorbei. Damit lassen sich die Zustände aller Pins einlesen bzw setzen. Beim Core Debugging ist es eigentlich das gleiche nur geht die SCAN Line einmal um den MCU Core (z.B. ARM7DTMI) Liegt somit zwischen ARM core und der internen Periferie. (Funktionseinheiten RAM FLASH) Du kannst damit den internen zustand des cores auslesen. oder auch den ganzen core simuliern. SWD ist der nachfolger von JTAG. JTAG ist halt prinzip bedingth sehr sehr langsam / bzw sehr sehr inefizient. Wobei ich SWD nur bei ARM cortex cores gesehen habe. (ob das auch jemand anders einsetzt keine ahnung) ARM hat sowohl zu JTAG als auch zu SWD recht umfangreiche Dokumente. Eines davon ist ja schon genant worden.
123 schrieb: > die IEEE Norm beschreibt Bei JTAG wie man mit den 3 Leitungen mit irgend > jemanden reden kann. Mehr nicht. ggf noch boundery scan im ganz ganz > groben. > Was die Register zu bedeuten haben, wie gross diese sind, ... haben > andere zu beschreiben. Ich verstehe was Du mir sagst und kann das in der Theorie alles nachvollziehen. Leider bin ich kein Akademiker und es daher eher gewohnt mein Wissen durch Praxiserfahrung zu erweitern und nicht bloß aus der Theorie. Ich will Dich und andere damit weder bremsen noch abwerten, alles was ihr schreibt ist wichtig und sinnvoll! Nur würde ich das gern selbst sehen, machen, ausprobieren und genau da drückt mich der Schuh weil ich das bislang nicht hinbekommen habe. Glaubt bitte nicht das ich hier alles auf dem Silbdertablett präsentiert haben möchte, ich habe mir wirklich mehrere Dutzend Abhandlungen über das Thema reingezogen, neben IEEE-Dokumenten auch Datenblätter von Herstellern, Präsentationen von Unis und Embedded-Veranstaltungen, privaten und kommerziellen Homepages, Videos und und und. Nur, wie schon gesagt, war da nie etwas bei was auch ICH Dödel hätte tun können und irgendwie brauch ich das um zu kapieren. Ich weiss Eure Bemühungen wirklich zu schätzen und hoffe das ich diesen Thread auch mal mit Ergebnissen füttern darf, für all die Anfänger und einfachen Hobbybastlern wie mich :-) Der Hinweis auf "goJTAG" (http://www.gojtag.com/) scheint genau die Lücke zu füllen die ich bislang in meinem Wissen sehe, TOP! Vielen Dank dafür! Der dort beispielhaft verwendete PicoTAP Adapter von Göpel scheint laut dem beiliegenden Schaltplan (www.gojtag.com/sites/default/files/PICOTAP_SCHEMATIC.pdf) sehr einfach nachzubauen zu sein und besteht im Grunde nur aus einem FT2232H Chip, wie er z.B. im Olimex ARM-USB-OCD-H drin ist. Auf der Seite wird damit geworben das man diesen Adapter kostenlos(!?) von Göpel zu nicht-kommerziellen Einsatzzwecken erhalten könne. Das kann ich ja kaum glauben und fände ich ja fast schon unanständig ;-) Womöglich gilt das aber auch schon nicht mehr da der Artikel darüber von 2011 ist. Ich brauche jetzt mal ein paar Tage um das was ich dort finde alle aufzusaugen und werde gern berichten! Nochmal ein großes Lob und Danke an Euch!
:
Bearbeitet durch User
Du konzentrierst dich immer noch zu sehr auf den JTAG Adapter. Den kannst du für wenige Euro fertig kaufen. Besorge Dir lieber einen Logic Analyzer (falls du noch keinen hast), damit kannst du Dir die Kommunikation anschauen und nachvollziehen. Wenn du wirklich mit JTAG experimentieren willst, musst du zuerst einen Chip finden, bei dem die JTAG Features offen und für Dich verständlich dokumentiert sind. Und dann brauchst du für diesen Chip eine halbwegs reale Anwendung, damit die ganze Aktion nicht völlig an der Praxis vorbei geht. Denn: > Leider bin ich kein Akademiker und es daher eher gewohnt > mein Wissen durch Praxiserfahrung zu erweitern Besorge oder baue Dir einen JTAG Adapter, nachdem klar ist, welchen Chip du damit debuggen möchtest. Bei der ganzen Aktion solltest du nicht vergessen, dass JTAG nicht nur zum Debuggen von Mikrocontrollern da ist. Man kann damit die Funktion kompletter Geräte prüfen. Beim PC kann man über das JTAG Interface das gesamte Mainboard überprüfen (ging zumindest früher mal), wenn man denn die Doku dazu hat. By the way: wir hatten die selbe Diskussion für Dich schon vor ein paar Monaten: Beitrag "Wie funktioniert JTAG?" Lies Dir das nochmal durch, du wirst sehen, dass du im Prinzip die gleichen Antworten schon einmal bekommen hast.
Die Basics ? Es gibt SPI, einen Kurzdistanzlink, der auf Schieberegistern basiert. Der Master und der Slave haben jeder ein Schieberegister. Die sind per MISO (master in slave out), MOSI (master out slave in), SCLK (clock) gekoppelt. Der Master schiebt nun die Werten durch das Schieberegister zum slave, waehrend gleichzeitig, irgendwas vom Slave zum Master geschoben werden kann. Der Master gibt den clock (SCLK) vor. Nun haengt man alle Register, und Speicher eines Devices als Schieberegister in Serie, und erhaelt JTAG. Vereinfacht. JTAG ist ein erweitertes SPI.
:
Bearbeitet durch User
Olli Z. schrieb: > Auch meine Bemühungen hier im Forum Infos über JTAG zu bekommen sind > mehr oder weniger erfolglos geblieben. Das wundert mich nicht. Der Grund dafür ist, daß JTAG eigentlich ein serielles Interface zum Testen von Baugruppen auf Löt- und Kontakt-Problemen ist. Die Leute hier im Forum wissen das aber zumeist garnicht und denken, es sei ein Programmier- und Debug-Interface für ihre µC. Aber eben diese Programmier- und Debug-Verwendung ist erstens so im Ursprung garnicht vorgesehen und zweitens herstellerabhängig. Deshalb wirst du genau darüber nirgendwo ein allgemein gültiges Tutorial finden. Ws du finden kannst, sind Dokumentationen zur ursprünglichen JTAG-Verwendung, also für die Fälle, wo tatsächlich ein ganzes Board auf korrekte Verlötung getestet werden soll. W.S.
W.S. schrieb: > Der Grund dafür ist, daß JTAG eigentlich ein serielles Interface zum > Testen von Baugruppen auf Löt- und Kontakt-Problemen ist. Die Leute hier > im Forum wissen das aber zumeist garnicht und denken, es sei ein > Programmier- und Debug-Interface für ihre µC. Aha. Na klar. Das weiß hier niemand, ausser dich. Du kannst dir merken: So blöd wie du sind wir schon lange. > Aber eben diese Programmier- und Debug-Verwendung ist erstens so im > Ursprung garnicht vorgesehen und zweitens herstellerabhängig. Deshalb > wirst du genau darüber nirgendwo ein allgemein gültiges Tutorial finden. Und DAS hat ihm bisher fast jeder versucht zu erklären. Weil den meisten Leuten hier, genau DIESE Problematik mit JTAG völlig klar ist. Aber wenn ich vom TE so was lesen muss: > Ich verstehe was Du mir sagst und kann das in der Theorie alles > nachvollziehen. Leider bin ich kein Akademiker und es daher eher gewohnt > mein Wissen durch Praxiserfahrung zu erweitern und nicht bloß aus der > Theorie. dann weiß ich nicht ob der Verweis auf die JTAG Spec oder auch nur das Datenblatt eines STM32 wirklich sinnvoll ist.
:
Bearbeitet durch User
Ohne jetzt den ganzen Thread durchgelesen zu haben... Wenn ich Dich richtig verstehe, willst Du verstehen, was "unter der Haube" passiert. Dann würde ich doch vorschlagen, mal in den OpenOCD Code reinzuschauen. Darin wirst Du die ganze "Magie" finden. Bei mir war es übrigens auch so, dass es eine Weile dauerte, bis ich begriff, dass da viele eigene Süppchen gekocht werden. Ich dachte immer, dass da doch was Standardisiertes vorhanden sein muss! Und suchte nach diesem Gemeinsamen Nenner, den es halt nicht gibt (oder der halt viel kleiner ist, als ich zumindest dachte).
Malzeit, Kennt noch jemand den Wigler / Raven als JTAG TAP? Die Dinger die den LPT des PCs zum debuggen verwendet wurden. Einer davon war glaube ich ein rein passiver, recht günstig aber auch grotten langsam. ggf kann man daran und einem Open source Projekt das bit banging für den JTAG ergründen. Der FTDI wird vermutlich schon sehr viel intern machen zumindest wird JTAG als modus im datenblat des FTDI ewähnt.
Beitrag #5578484 wurde von einem Moderator gelöscht.
Beitrag #5578490 wurde von einem Moderator gelöscht.
Beitrag #5578494 wurde von einem Moderator gelöscht.
Olli Z. schrieb im Beitrag #5578490: > Daher suche ich jemand der mir > nachvollziehbare Schritte schreiben kann wie unter Atmega z.B. A nach B > kommt. Das hat mit JTAG etwa so viel zu tun, wie Kochen mit Elektrikern. > Eigentlich müsste Jtag doch Jtag sein und es überall klappen. Zum 100ten mal: Nein. JTAG ist eine simple auf Schieberegister basiertes serielles Übertragung. Wenn du damit ATmega Mikrocontroller auslesen willst, musst du die zugehörige Software benutzen. Zum Beispiel AVR8-Burn-o-mat (basiert auf avrdude) und einen dazu kompatiblen Programmieradapter. Im übrigen ist JTAG auf ATmega Mikrocontrollern schon vor langer langer Zeit durch die ISP Schnittstelle ersetzt worden. > Mit den Segger und J-Flash habe ich bereits versucht, > den Flash eines Gerätes ausgelesen, dabei > wurde aber das Gerät zerstört. Zeige den kompletten Schaltplan des Gerätes bis zum JTAG Adapter, Foto vom Aufbau, benenne die verwendete Software mit ihren Einstellungen. Dann kann man Dir vielleicht aufzeigen, was du falsch gemacht hast.
Beitrag #5578754 wurde von einem Moderator gelöscht.
Olli Z. schrieb im Beitrag #5578754: > Und warum soll es damit nicht gehen? Weil Dir die Anleitung für das jeweilige Gerät fehlt. Mit der richtigen Anleitung wird es funktionieren. Kaufe Dir lieber einen Atmel ICE Adapter, dessen Schnittstelle zum PC hin ist klar dokumentiert. Nur hast du dann dein Ziel nicht wirklich erreicht. Denn wenn du einen bestimmten ATmega auslesen kannst, kannst du eben nur diesen ATmega auslesen. Bei STM32 funktioniert das wieder ganz anders, und wenn du ein PC Mainboard testen willst, geht es wieder anders.
Bitte fallt nicht auf diesen dummen Menschen rein der nun versucht überall unter meinem Namen seinen Minderwertigkeitskomplex auszuleben. Ich schreibe ausschließlich nur eingelogged, nie als Gast! Ihr merkt es aber auch schon am Schreibstil. So würde ich nicht formulieren. Einfach ignorieren, ich melden jeden seiner Beiträge und habe auch schon einen Antrag auf Feststellung seiner IP gestellt. Irgendwann verliert er die Lust. ICH lasse mich durch solche dummen Menschen die nichts besseres mit ihrer Freizeit anzufangen wissen jedenfalls nicht irritieren und das solltet ihr auch nicht :-) Dieser Betrag wird sicher auch bald gelöscht. Armer Mod, hat richtig was zu tun mit diesem Zaungast.
Stefanus F. schrieb: > Das hat mit JTAG etwa so viel zu tun, wie Kochen mit Elektrikern. Wieso? Elektriker können nicht kochen?
"Und da waren sie wieder, meine drei Probleme"... Ich bekomme den Olimex Adapter nicht mit goJTAG ans laufen, er wird einfach nicht erkannt :-( Habe schon alles mögliche ausprobiert, Originaltreiber von FTDI, umprogrammieren der INF Dateien laut Datenblatt, umprogrammieren der VID/PID im EEPROM des FT2232H Chips des Olimex auf FTDI Defaultwerte, als auch die die der PicoTAP Adapter von Göpel nutzt. Der PicoTAP nutzt ja den selben Chip. Warum ignoriert die Software den vom Olimex? Hab auch schon in den Java Quellcode geschaut wo die Interfaces enumeriert werden. Einen direkten Vergleich von VID und PID habe ich dort nicht gefunden. Es werden einfach alle FDTI Interfaces genommen die hinten kein " B" haben, also eben nur Port A. Leider finde ich keinen Debugschalter zum starten, sodass ich Logmeldungen sehen könnte, aber meine Java Kenntnisse sind auch recht bescheiden. Habt ihr noch eine Idee? Olli Z. (nur echt mit dem (z80freak) dahinter :-)
:
Bearbeitet durch User
> Ich bekomme den Olimex Adapter nicht mit goJTAG ans laufen, > er wird einfach nicht erkannt :-( Welchen Olimex Adapter konkret, und wie lautet die Fehlermeldung? Wie wird der Adapter in der Systemsteuerung angezeigt? Bist du ganz sicher dass dein Adapter dem Schaltplan des PicoTAP entspricht? http://www.gojtag.com/sites/default/files/PICOTAP_SCHEMATIC.pdf
Angehängte Dateien:
-
gojtag_nodevicefound.jpg
34 KB
Stefanus F. schrieb: >> Ich bekomme den Olimex Adapter nicht mit goJTAG ans laufen, >> er wird einfach nicht erkannt :-( > > Welchen Olimex Adapter konkret, und wie lautet die Fehlermeldung? Olimex ARM-USB-OCD-H und der hat einen FTDI2232H, genau wie der PicoTAP. > Wie wird der Adapter in der Systemsteuerung angezeigt? Einmal als Gerät und einmal als virtueller COM-Port, so wie es der Treiber vorsieht. Aktuell habe ich als VID/PID die Kombi: 0403 und 6010, also FTDI-Default. > Bist du ganz sicher dass dein Adapter dem Schaltplan des PicoTAP > entspricht? > http://www.gojtag.com/sites/default/files/PICOTAP_SCHEMATIC.pdf Nein, da ich vom Olimex keinen Schaltplan habe, aber der USB-Chip ist zumindest derselbe. Er könnte also, aber will nicht. Irgendwie sieht er den FTDI nicht als den Chip den er sehen möchte. Im DeviceConnectDialog.java findet sich dieser Source:
1 | private void constructUsbPanel() {
|
2 | // Initialize |
3 | usbPanel = new JPanel(); |
4 | usbPanel.setName("PicoTAP USB (FTDI based)");
|
5 | comboUsbDevice= new JComboBox(); |
6 | String[] devices = null; |
7 | try {
|
8 | // try to enumerate connected chips |
9 | devices = UsbFtdiPort.enumerate(); |
10 | } catch (Throwable t) {
|
11 | // Some error |
12 | devices = null; |
13 | } |
14 | |
15 | if ((devices != null) && (devices.length > 0)) {
|
16 | comboUsbDevice.setModel(new DefaultComboBoxModel(devices)); |
17 | comboUsbDevice.setEnabled(true); |
18 | } else {
|
19 | comboUsbDevice.setModel(new DefaultComboBoxModel( |
20 | new String[] {"No FTDI devices connected"}));
|
21 | comboUsbDevice.setEnabled(false); |
22 | } |
Er findet also keine FTDI-Ports, obwohl das Gerät einwandfrei im Gerätemanager angezeigt wird. Die Treiberversion ist 2.12.28.0 Die enumerate-Routine ist ebenfalls überschaubar:
1 | public static String[] enumerate() |
2 | {
|
3 | String[] devices = null; |
4 | |
5 | int devCount = FtdiLibrary.INSTANCE.getFtdiDeviceCount(); |
6 | if(devCount == -1) |
7 | return devices; |
8 | |
9 | byte[] deviceNames = new byte[devCount * 64]; //allocate buffer |
10 | devices = new String[devCount]; //and strings for device names |
11 | |
12 | int ret = |
13 | FtdiLibrary.INSTANCE.enumerateDevices(deviceNames, devCount); //store device names to byte buffer |
14 | if(ret == -1) |
15 | {
|
16 | System.err.println("UsbFtdiPort: Unable to enumerate devices");
|
17 | // throw new PortException("Cannot read IO port value");
|
18 | return devices; |
19 | } |
20 | |
21 | int devCountPortA = 0; |
22 | for(int i = 0; i < devCount; i++) |
23 | {
|
24 | int strSize; |
25 | for(strSize = 0; strSize < 64 && deviceNames[i*64 + strSize] != 0; strSize++); //get real string size |
26 | devices[i] = new String(deviceNames, i*64, strSize, Charset.forName("US-ASCII"));
|
27 | |
28 | // Only count the first port of FTDI chip |
29 | if (devices[i].endsWith(" B"))
|
30 | devices[i] = null; |
31 | else |
32 | devCountPortA++; |
33 | } |
34 | |
35 | // Filter "port B" devices |
36 | String[] devicesPortA = new String[devCountPortA]; |
37 | devCountPortA = 0; |
38 | for (int i = 0; i < devCount; i++) {
|
39 | if (devices[i] != null) |
40 | devicesPortA[devCountPortA++] = devices[i]; |
41 | } |
42 | |
43 | return devicesPortA; |
44 | } |
Ich weiss jedoch nicht genau woher die FTDI funktionen stammen. Scheinbar wird diese Klasse aus einer Bibliothek namens "jtagctrl" geladen:
1 | public class UsbFtdiPort implements Port {
|
2 | |
3 | public interface FtdiLibrary extends Library {
|
4 | FtdiLibrary INSTANCE = (FtdiLibrary)Native.loadLibrary("jtagctrl",FtdiLibrary.class);
|
Aber wie gesagt, ich bin nicht der Java-Crack... :-(
Angehängte Dateien:
ES KLAPPT! So schnell kanns gehen :-) Als ich den Beitrag oben schrieb ist mir die "jtagctrl.dll" Datei im Programmverzeichnis von goJTAG aufgefallen. Die habe ich mal kurz untersucht und die Einstiegspunkte für die prozeduren gefunden die ich oben im Javacode vermisst habe. Dann habe ich die Datei mal umbenannt und geschaut ob sich das Programm anders verhält (ich hätte eine Java-Exception oder sonstige Fehlermeldung erwartet), aber nichts. Dann habe ich den Programmpfad im Startbatch für die gojtag.jar hinzugefügt und siehe da, es klappt! Nun lädt er die DLL und kann auch den Adapter erkennen. Vermutlich sogar mit der originalen Olimex VID/PID, das probier ist jetzt mal als nächstes aus. Hier mein Start-Batch (von hause aus war beim Programm keins dabei):
1 | @echo off |
2 | set PATH=%~dp0\jre\bin;%~dp0;%PATH% |
3 | set CLASSPATH=.;%~dp0 |
4 | start javaw -jar gojtag.jar |
Schön dass du die Lösung hier präsentiert hast. Das vergessen die Leute oft.
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.