Jetzt hab ich zwar schon viel gelesen und angeschaut zum Thema aber irgendwie komm ich nicht "rein". Den elektrischen Anschluß des Interfaces glaube ich verstanden zu haben. Auch das die Geräte in einer Art Daisy-Chain verbunden werden. Aber ab dann hab ich nur noch Fragen und weiss nicht mehr wie es weiter geht. Wie ist das mit den IDs? Wie "scanne" ich die die Geräte die in diesem Bus verbunden sind? Woher weiss ich welche JTAG Befehle ein Gerät versteht? Gibt es Befehle die jedes Gerät verstehen muss? (Basis-Kommandos) Woher kenne ich die Parameter für die Taktfrequenzen? Und und und... Vielleicht kann mir jemand ein gutes Einsteiger-Tutorial empfehlen, was man auch verstehen kann. Oder einfach mal in kurzen Worten erklären WIE man an die Sache systematisch ran geht. Als Equipment habe ich einen Segger J-Link EDU zur Verfügung. Zum testen z.B. ein Blaupunkt FX mit JTAG, OMAP, Flash.
Olli Z. schrieb: > Aber ab dann hab ich nur noch Fragen und weiss nicht mehr wie es weiter > geht. Wie ist das mit den IDs? > Wie "scanne" ich die die Geräte die in diesem Bus verbunden sind? Hast du das mit dem grossen "Schieberegister" und IR/DR-Mode verinnerlicht? Also BYPASS-modus soweit verstanden? > Woher weiss ich welche JTAG Befehle ein Gerät versteht? Gibt es Befehle > die jedes Gerät verstehen muss? (Basis-Kommandos) BYPASS verstehen fast alle, nur manchmal auch mit fehlerhafter Implementierung. Die weiteren IR-Registerwerte sind komplett herstellerspezifisch, wie auch oft, was bei Run-Test-Idle passieren soll. > Woher kenne ich die Parameter für die Taktfrequenzen? Auch herstellerspezifisch. Bei Prozessoren musst du teils für die Emulation auch noch 'ready'-Bits abfragen, bevor du weiter Daten rein/rausclockst. Relativ gut standardisiert ist der "Boundary-Scan", da findest du zu vielen Chips die *.bsdl-Dateien. Weniger gut bis gut gehütetetes Geheimnis sind die Interna zur In-Circuit-Emulation. Für weiteres Reverse-Engineering würde ich mal mit folgenden Tools anfangen: - Boundary Scan ausprobieren: goJTAG, openJTAG (eher grottig) - ICE: OpenOCD Ahja, und beim OMAP insbesondere mit den I/O Spannungen aufpassen.
@ Olli Z. (z80freak) >geht. Wie ist das mit den IDs? Jeder IC hat eine mit variabler Länge. Die steht im Datenblatt und .bsdl File. >Wie "scanne" ich die die Geräte die in diesem Bus verbunden sind? Das kann jede JTAG-Software. >Woher weiss ich welche JTAG Befehle ein Gerät versteht? Siehe oben. >Gibt es Befehle >die jedes Gerät verstehen muss? (Basis-Kommandos) Ja. >Woher kenne ich die Parameter für die Taktfrequenzen? Siehe oben. >Als Equipment habe ich einen Segger J-Link EDU zur Verfügung. Zum testen >z.B. ein Blaupunkt FX mit JTAG, OMAP, Flash. Das "schöne" an JTAG ist, daß so ziemlich ALLE Hardwareadapter und Software EIGENE Zwischenprotokolle haben und nur mit sich selber funktionieren. Man muss also immer die richtige Software mit der exakt dazu passenden Hardware haben. Allgemeine Treiber gibt es nicht. Ich hab vor Ewigkeiten mal damit rumgespielt. http://www.ricreations.com/JTAG-Software-Downloads.htm Siehe auch JTAG.
Hallo Strubi, erstmal vielen Dank für die Hilfe. Ich quote mal direkt drunter :-) Strubi schrieb: > Hast du das mit dem grossen "Schieberegister" und IR/DR-Mode > verinnerlicht? Das ist doch der "Boundary Scan" nicht wahr? Also wo praktisch innerhalb eines JTAG-Moduls (oder wie auch immer die einzelnen Bausteine genannt werden) die I/O-Ports wie in einem großen Schieberegister zusammengefasst werden. Wenn ich also z.B. 16 I/O-Ports hätte könne und müsste ich ein 16-Bit (2Byte) dort reinschieben um Daten zu setzen und auslesen um den Zustand zu ermitteln. Das wäre das Datenregister (DR genannt?). Um andere Dinge zu tun, bzw. überhaupt dem Chip (zu testenden Modul) zu sagen was es mit den Daten tun soll, oder ob es welche liefern soll, wird vorab im Befehlsregister (IR gennant?) bekannt gegeben. Jedes Bauteil versteht eine eigene Anzahl von Funktionen. > Also BYPASS-modus soweit verstanden? Das ist doch, wenn ich DURCH andere in der Daisy-Chain hängenden Bauteile Daten nur durchschleusen will, ohne das die vom Chip bearbeitet werden. Dabei werden doch die eingehenden Daten (TDI) direkt wieder zum Ausgang (TDO) weitergereich. Hab nur noch nicht verstanden wie man dann geziehlt ein Bauteil anspricht. Sprich wie schalte ich ein Bauteil auf Bypass und woher weiss ich wie ich das richtige erwische? >> Woher weiss ich welche JTAG Befehle ein Gerät versteht? Gibt es Befehle >> die jedes Gerät verstehen muss? (Basis-Kommandos) > > BYPASS verstehen fast alle, nur manchmal auch mit fehlerhafter Ist also "BYPASS" ein Befehl? > herstellerspezifisch, wie auch oft, was bei Run-Test-Idle passieren Was ist darunter zu verstehen? >> Woher kenne ich die Parameter für die Taktfrequenzen? > > Auch herstellerspezifisch. Bei Prozessoren musst du teils für die > Emulation auch noch 'ready'-Bits abfragen, bevor du weiter Daten > rein/rausclockst. Dann muss sowas ja im Datenblatt stehen, oder? Sofern man eines hat. Kann man denn, wenn man es nicht weiss, einfach mit der niedrigsten Taktrate anfangen? Wie verhält sich das ganze zur Laufzeit des Prozessors. Führt diesen sein Programm unabhängig von meinen JTAG Abfragen/Setzbefehlen aus? Oder geht der jedesmal in eine Art HALT-Zustand bis ich mit dem JTAG-Datenaustausch fertig bin? Und was meinst Du nun mit "Emulation" in diesem Zusammenhang? > Relativ gut standardisiert ist der "Boundary-Scan", da findest du zu > vielen Chips die *.bsdl-Dateien. Weniger gut bis gut gehütetetes Davon hab ich schonmal gehört. Was genau steht denn da drin und wie/womit nutzt man solche Dateien? Ist also dieser "Scan" nur ein scan nach bekannten Größen? Ich dachte der Scan identifiziert auch unbekannte Module/Teilnehmer. Wenn nicht, dann ist das doch nur eine Art Existenzcheck. Wie ist das mit der Reihenfolge der Teilnehmer in der Kette (Test-Chain?) ist die entscheident? > Geheimnis sind die Interna zur In-Circuit-Emulation. ??? Bitte ein paar Details dazu :-) > Für weiteres Reverse-Engineering würde ich mal mit folgenden Tools > anfangen: > - Boundary Scan ausprobieren: goJTAG, openJTAG (eher grottig) Kann ich diese Tools mit meinem Segger Interface nutzen? Ich hab keine Ahnung was da zwischen Software und Adapter für ein Protokoll gesprochen wird. Könnte mir aber vorstellen das Segger hier einen Standard gesetzt hat und das andere Clones das nur nachahmen. > - ICE: OpenOCD Was ist denn dieses "ICE", davon hab ich schon paarmal gelesen. Auch von einem "ICE Breaker" oder "ICE Crusher". > Ahja, und beim OMAP insbesondere mit den I/O Spannungen aufpassen. Anfangs hatte ich den "Vcc" vom Segger JTAG-Port nicht mit dem Board verbunden weil ich nicht wusste ob das ein Problem macht. Aber ohne macht es ein Problem, denn der Adapter erkennt darüber wohl die DIO-Spannung um seine eigenen Pegel daran anzupassen. Nach dem Verbinden hats dann funktioniert das ich wenigstens kommunizieren konnte. Wenn auch bislang nichts sinnvolles dabei rauskam.
@Olli Z. (z80freak) >> Also BYPASS-modus soweit verstanden? >Das ist doch, wenn ich DURCH andere in der Daisy-Chain hängenden >Bauteile Daten nur durchschleusen will, ohne das die vom Chip bearbeitet ><werden. Dabei werden doch die eingehenden Daten (TDI) direkt wieder zum >Ausgang (TDO) weitergereich. Ja, mit nur 1 Takt Verzögerung. >Hab nur noch nicht verstanden wie man dann geziehlt ein Bauteil >anspricht. Sprich wie schalte ich ein Bauteil auf Bypass und woher weiss >ich wie ich das richtige erwische? Mit Hilfe der JTAG Statemachine. Jeder JTAG-Eingang hat eine einfache Statemachine, die mittels des TDI Eingangs gesteuert wird. Also muss man die richtige Bitsequenz reintakten, um den jeweiligen Zustand zu erreichen. Dann folgen die Daten bzw. Kommandos. >> BYPASS verstehen fast alle, nur manchmal auch mit fehlerhafter >Ist also "BYPASS" ein Befehl? Ja. >> herstellerspezifisch, wie auch oft, was bei Run-Test-Idle passieren >Was ist darunter zu verstehen? Das viele Befehle und ihre Wirkung sehr IC-spezifisch sind. >> Auch herstellerspezifisch. Bei Prozessoren musst du teils für die >> Emulation auch noch 'ready'-Bits abfragen, bevor du weiter Daten >> rein/rausclockst. >Dann muss sowas ja im Datenblatt stehen, oder? Nein, die Details der Debugger/Emulatoren über JTAG sind meisten sehr schlecht bis gar nicht öffentlich dokumentiert. Das kennt nur der Hersteller und ggf. eine Firme, welche dafür Software macht. Betriebsgeheimnis ;-) >Kann man denn, wenn man es nicht weiss, einfach mit der niedrigsten >Taktrate anfangen? Sicher, das ist aber das kleinste Problem. 1MHz schafft jeder IC, man kann auch mit 10kHz anfangen. Denn das Protokoll ist wie SPI synchron. >Wie verhält sich das ganze zur Laufzeit des >Prozessors. Das ist bei jedem IC verschieden. > Führt diesen sein Programm unabhängig von meinen JTAG >Abfragen/Setzbefehlen aus? Meistens schon. >Oder geht der jedesmal in eine Art >HALT-Zustand bis ich mit dem JTAG-Datenaustausch fertig bin? Nein. Aber es gibt viele Prozessoren, wo man in Echtzeit den Debugger per JTAG nutzen kann. >> Relativ gut standardisiert ist der "Boundary-Scan", da findest du zu >> vielen Chips die *.bsdl-Dateien. Weniger gut bis gut gehütetetes >Davon hab ich schonmal gehört. Was genau steht denn da drin und Alle elementaren Daten, wie Name des ICs, welche Befehle er kennt, seine ID, Länge des Instruction- und Datenregisters etc. >wie/womit nutzt man solche Dateien? Mit den passenden JTAG-Programmen. Damit wissen die, was der IC kann und wie man ihn mit Daten versorgen muss. >Ist also dieser "Scan" nur ein scan nach bekannten Größen? Ich dachte >der Scan identifiziert auch unbekannte Module/Teilnehmer. Ja, über die ID. Man kann mit diversen Test einige Parameter von unbekannten ICs auch ohne BSDL-File rausfinden, aber halt nicht alle. > Wenn nicht, >dann ist das doch nur eine Art Existenzcheck. Wie ist das mit der >Reihenfolge der Teilnehmer in der Kette (Test-Chain?) ist die >entscheident? Eigentlich nicht, praktisch ja. Auf Grund diverser grenzwertiger Kompatibilitäten haben einige JTAG-Debugger Probleme, wenn eine CPU nicht die Nr. 1 in einer JTAG-Kette ist. >> Geheimnis sind die Interna zur In-Circuit-Emulation. >??? Bitte ein paar Details dazu :-) Sie sind geheim, siehe oben! >> Für weiteres Reverse-Engineering würde ich mal mit folgenden Tools >> anfangen: >> - Boundary Scan ausprobieren: goJTAG, openJTAG (eher grottig) >Kann ich diese Tools mit meinem Segger Interface nutzen? Keine Ahnung, vermutlich nicht. >wird. Könnte mir aber vorstellen das Segger hier einen Standard gesetzt >hat und das andere Clones das nur nachahmen. Kann sein, ist aber eher unwahrscheinlich. >> - ICE: OpenOCD >Was ist denn dieses "ICE", davon hab ich schon paarmal gelesen. Auch von >einem "ICE Breaker" oder "ICE Crusher". Das sind aber alles Debugger bzw. Emulatoren, welche zum Programmieren und Debuggen spezieller CPUs gebaut sind. Diese können NICHT die normalen JTAG-Funktionen ansprechen, wie Setzen und Lesen von IOs!
Falk B. schrieb: >>geht. Wie ist das mit den IDs? > Jeder IC hat eine mit variabler Länge. Die steht im Datenblatt und .bsdl > File. Ist diese ID "willkürlich" vom Hersteller vergeben, oder gibt es eine zentrale Registrierungsstelle? Sprich kann es auch doppelte Werte geben? Ist diese ID im Chip fest eingebrannt? Sprich reagiert er nur auf seine ID? >>Wie "scanne" ich die die Geräte die in diesem Bus verbunden sind? > Das kann jede JTAG-Software. Soweit ich verstanden habe aber doch nur wenn ich weiss was ich dort finde? Oder wie sieht so ein SCAN-Vorgang aus? Gibt es ein Kommando wie "Sende mir Deine ID, Chip-1"? >>Gibt es Befehle >>die jedes Gerät verstehen muss? (Basis-Kommandos) > Ja. Beispielsweise? Da gibts dann doch sicher eine Übersicht? Danke für die Links, werde ich mal reinziehen :-)
@ Olli Z. (z80freak) >Ist diese ID "willkürlich" vom Hersteller vergeben, Nein. >oder gibt es eine zentrale Registrierungsstelle? Ja > Sprich kann es auch doppelte Werte geben? AFAIK nein. >Ist diese ID im Chip fest eingebrannt? Ja. >Sprich reagiert er nur auf seine ID? Nein, so funktioniert das nicht. Die ID kann man auslesen. Das wars. Damit kann man die logische Verbindung zum BSDL-File herstellen. Man kann aber auch totalen Unsinn an Daten und Befehlen in einen IC schreiben. Dann kommt aber halt Unsinn raus. >>>Wie "scanne" ich die die Geräte die in diesem Bus verbunden sind? >> Das kann jede JTAG-Software. >Soweit ich verstanden habe aber doch nur wenn ich weiss was ich dort >finde? Nein, man kann auch eine unbekannte JTAG-Kette scannen und ein paar grundlegende Infos dadurch erhalten. Anzahl der ICs, Länge der Daten- und Kommandoregister etc. >Oder wie sieht so ein SCAN-Vorgang aus? Gibt es ein Kommando wie >"Sende mir Deine ID, Chip-1"? So in etwa. Aber die Adressierung erfolgt nicht wie bei I2C über eine Adresse sondern durch die Lage/Reihenfolge im riesigen Schieberegister. >>>Gibt es Befehle >>>die jedes Gerät verstehen muss? (Basis-Kommandos) >> Ja. >Beispielsweise? Da gibts dann doch sicher eine Übersicht? Die stehen in fast jedem Datenblatt eines ICs, der JTAG kann.
Falk B. schrieb: > Das sind aber alles Debugger bzw. Emulatoren, welche zum Programmieren > und Debuggen spezieller CPUs gebaut sind. Diese können NICHT die > normalen JTAG-Funktionen ansprechen, wie Setzen und Lesen von IOs! Genau, aber ... Man nehme ein 1,5€-Blue-Pill-Board oder gar ein STM32F030 Board derselben Preisklasse und hänge das an den JLink oder einen 2€-STLink. Dann kann man über openOCD bequem an den GPIO-Pins wackeln bzw. sie abfragen. Geht zwar recht gemächlich, aber wenn man erst mal verstanden hat, wie es geht, schreibt man sich ein kurzes (Assembler-) Programm, schiebt das über openOCD ins RAM des Prozessors ... und los geht's. Die "Ausgabe" lässt sich hinterher umgekehrt aus dem RAM des Prozessors auslesen. Mit dem Programm im Controller lässt sich sogar recht einfach per FIFO kommunizieren. (Im Moment zwar nur unidirektional Host->Target implementiert, aber die umgekehrte Richtung geht sinngemäß genauso, auch bidirektional mit 2 FIFOs wär' keine große Sache.) So etwas geht auch mit einem FTDI-Adapter per Bitbanging, aber prinziell natürlich nur vergleichsweise langsam.
Falk B. schrieb: >>Hab nur noch nicht verstanden wie man dann geziehlt ein Bauteil >>anspricht. Sprich wie schalte ich ein Bauteil auf Bypass und woher weiss > > Mit Hilfe der JTAG Statemachine. Jeder JTAG-Eingang hat eine einfache > Statemachine, die mittels des TDI Eingangs gesteuert wird. Also muss man > die richtige Bitsequenz reintakten, um den jeweiligen Zustand zu > erreichen. Dann folgen die Daten bzw. Kommandos. Aha, verstehe! Die genannte Bitsequenz ist also nochmal was anderes als ein Kommando. Wie und wo ist das denn definiert welche Sequenz für was gut ist? Kannst Du mal ein Beispiel für eine solche Sequenz nennen? Ruhig abstrakt. >>Dann muss sowas ja im Datenblatt stehen, oder? > Nein, die Details der Debugger/Emulatoren über JTAG sind meisten sehr > schlecht bis gar nicht öffentlich dokumentiert. Das kennt nur der Mist, hab schon befürchtet das da irgendwo ein Haken ist ;-) >>Kann man denn, wenn man es nicht weiss, einfach mit der niedrigsten >>Taktrate anfangen? > Sicher, das ist aber das kleinste Problem. 1MHz schafft jeder IC, man > kann auch mit 10kHz anfangen. Denn das Protokoll ist wie SPI synchron. Meine ersten Tests habe ich mit 4000 kHz gemacht, hust - hust, das ist ja dann quasi nur zum warmlaufen. Und dann geht man einfach hoch bis es nicht mehr klappt?! Ja, vermutlich steht das im bsdl-File ;-) >>Oder geht der jedesmal in eine Art >>HALT-Zustand bis ich mit dem JTAG-Datenaustausch fertig bin? > > Nein. Aber es gibt viele Prozessoren, wo man in Echtzeit den Debugger > per JTAG nutzen kann. Ok, Debugger heißt ja doch, das man die Software auf dem Chip debugfähig gemacht hat, sodass eine Kommunikation mit einem Debugger-Tool möglich ist?! >>> Relativ gut standardisiert ist der "Boundary-Scan", ... >>Davon hab ich schonmal gehört. Was genau steht denn da drin und > Alle elementaren Daten, wie Name des ICs, welche Befehle er kennt, seine > ID, Länge des Instruction- und Datenregisters etc. Cool! Genau was ich gesucht hab. Was mir dann nur fehlt ist, wie man den Chip in einen Modus versetzt, das er auf dem JTAG-Interface (ich glaube "TAP" genannt) diesen Boundary-Scan zulässt und durchführt. Sowie eine Software mit der ich das machen kann. > Mit den passenden JTAG-Programmen. Damit wissen die, was der IC kann und > wie man ihn mit Daten versorgen muss. Dazu werde ich mich wohl mal mit OpenOCD, goJTAG auseinandersetzen müssen. Eigentlich sollte es von Segger ja auch was dazu geben... das Kommandozeilentool "jlink.exe" (J-Link Commander) finde ich aber etwas sperrig. Grad für den Einstieg hätte ich mir etwas mit einer GUI gewünscht. Und vor allem detaillierten Debug-Ausgaben. >>Ist also dieser "Scan" nur ein scan nach bekannten Größen? Ich dachte >>der Scan identifiziert auch unbekannte Module/Teilnehmer. > > Ja, über die ID. Man kann mit diversen Test einige Parameter von > unbekannten ICs auch ohne BSDL-File rausfinden, aber halt nicht alle. Aber man könnte wie oben beschrieben erstmal schauen was es alles für Geräte(/Chips/Module wie auch immer) in einer JTAG-Linie gibt und dann geziehlt jedes Gerät über seine ID nach bestimmten Eigenschaften abklopfen. > Kompatibilitäten haben einige JTAG-Debugger Probleme, wenn eine CPU > nicht die Nr. 1 in einer JTAG-Kette ist. Oha. Ich hoffe da zählt mein Segger J-Link nicht dazu... Wer die Nr. 1 ist hängt ja von der Verschaltung TDI/TDO ab. Und die gibt ja der Entwickler der Hardware vor. Sprich, bei einem fremden Gerät kann ich das nicht beeinflussen. Gibt es Geräte in Geräten? Also das ein uC zunächst nur eine CPU oder I/O-Register in die Chain einhängt (virtuell gesehen) und wenn er einen bestimmten Befehl bekommt das dann auch plötzlich weitere Komponenten wie ein externes Flash oder weitere I/O-Module "da" sind? >>> - Boundary Scan ausprobieren: goJTAG, openJTAG (eher grottig) >>Kann ich diese Tools mit meinem Segger Interface nutzen? > Keine Ahnung, vermutlich nicht. Vermutlich wird es oberhalb von Segger noch Tools geben die in einer anderen Preisliga spielen (obwohl ich den schon sehr teuer finde). Aber diese Open-Dinger arbeiten wohl eher mit Clone-Hardware zusammen. >>Was ist denn dieses "ICE", davon hab ich schon paarmal gelesen. Auch von >>einem "ICE Breaker" oder "ICE Crusher". > Das sind aber alles Debugger bzw. Emulatoren, welche zum Programmieren > und Debuggen spezieller CPUs gebaut sind. Diese können NICHT die > normalen JTAG-Funktionen ansprechen, wie Setzen und Lesen von IOs! Ok, das lass ich jetzt mal sacken. Ich verstehe die Worte, kann es aber noch nicht richtig einordnen.
A. B. schrieb: > einen 2€-STLink. Dann kann man über openOCD bequem an den GPIO-Pins > wackeln bzw. sie abfragen. Haben diese ST-Link Adapter (sowas hab ich auch, im Format eines USB-Sticks) denn wirklich JTAG? Auf meinem steht, soweit ich das erkenne nämlich nur SWM und das ist doch nicht dasselbe?! Kann openOCD nur mit dieser Art Adapter, oder auch mit dem Segger J-Link? > es geht, schreibt man sich ein kurzes (Assembler-) Programm, schiebt das > über openOCD ins RAM des Prozessors ... und los geht's. Die "Ausgabe" > lässt sich hinterher umgekehrt aus dem RAM des Prozessors auslesen. Wow, so weit bin ich noch LANGE nicht ;-) Bevor ich ran gehe und mich in fremden CPUs breit mache und die Macht übernehme, will ich erstmal verstehen wie das Interface drumherum funktioniert. > Mit dem Programm im Controller lässt sich sogar recht einfach per FIFO > kommunizieren. (Im Moment zwar nur unidirektional Host->Target > implementiert, aber die umgekehrte Richtung geht sinngemäß genauso, auch > bidirektional mit 2 FIFOs wär' keine große Sache.) Sprich dein Fremdcode welchen Du im Prozessor ausführen lässt erzeugt Daten in einem Stack im RAM, welchen Du dann per JTAG ausliest und den SP verringerst. Schlau, schlau ;-) > So etwas geht auch mit einem FTDI-Adapter per Bitbanging, aber prinziell > natürlich nur vergleichsweise langsam. Könnte ich mir auch vorstellen, denn JTAG ist seriell, arbeitet mit getrennten TX und RX Leitungen und ein paar Steuersignalen. Einzig der Takt ist beim FTDI dann je nach eingestellter Baudrate fest
Wow, wie das läuft, ich bin echt begeistert! So viele nützliche Antworten und nicht ein Quaker dabei, toll! Und denen die bislang geantwortet haben VIELEN VIELEN DANK!!! Endlich Antworten auf meine Fragen mit denen ich auch was anfangen kann, nach stundenlangem lesen irgendwelcher Foren, Datenblätter und Blogs. Ich will das jetzt auch nicht Tod-Theoretisieren sondern mir kribbelt es in den Finger das auch mal in die Praxis umzusetzen. Anfangen möchte ich mit dem Scan der Teilnehmer-IDs an einem mir unbekannten System. Da möchte ich erstmal nur sehen das mir die IDs geliefert werden und evtl. mal mit der Taktrate rumexperimentieren. Kann mir einer eine Software empfehlen die mit meinem Segger J-Link zusammenarbeitet? Oder wie ich einen solchen Scan mit dem jlink.exe CLI durchführen kann? Wenn das klappt, würde ich als nächstes schauen wo ich die bsdl-Files für die gefundenen IDs her bekomme. Wenn es dafür eine zentrale Registriertungsstelle gibt, wie oben gesagt, dann kann man dort doch sicher einen ID-Lookup durchführen.
http://bsdl.info/ da findet man herstellerübergreifend bsdl-Files. Beim Hersteller selbst sind die meistens irgendwo versteckt oder nicht mehr erhältlich. http://www.ece.mtu.edu/faculty/rmkieckh/cla/3173/References/JTAG-tut-big-2007.pdf Das beschreibt die Hardware, vor allem um Figure 13 herum, die state-machine des TAP-controllers Um mit einem einzigen Bit zu klappern muss man jeweils z.B. 500 Bits reinschieben.
@A. B. (Gast) >Genau, aber ... Man nehme ein 1,5€-Blue-Pill-Board oder gar ein >STM32F030 Board derselben Preisklasse und hänge das an den JLink oder >einen 2€-STLink. Dann kann man über openOCD bequem an den GPIO-Pins >wackeln bzw. sie abfragen. >Geht zwar recht gemächlich, aber wenn man erst mal verstanden hat, wie >es geht, schreibt man sich ein kurzes (Assembler-) Programm, schiebt das >über openOCD ins RAM des Prozessors ... und los geht's. Die "Ausgabe" >lässt sich hinterher umgekehrt aus dem RAM des Prozessors auslesen. Jaja, die Frickler-Fraktion läßt grüßen. Es gibt aber auch Leute, auch Bastler, die wollen das alles nicht und eine fertig funktionierende Lösung haben und dafür auch betreit sind, deutlich mehr als 3,fuffzich auszugeben.
Ein weiteres Tool in die Richtung ist die 'black magic probe', eine intelligente debug probe. Die Quellen dazu gibts auf github, da findest du auch einen jtag scan: https://github.com/blacksphere/blackmagic/blob/master/src/target/jtag_scan.c
Olli Z. schrieb: > Kann openOCD nur mit dieser Art Adapter, oder auch mit dem Segger > J-Link? Geht auch, auch verschiedene andere, dabei auch ftdi. So ein STLink Clone ist aber mit Abstand wohl preislich und optisch am schönsten. Aber Geschmackssache. >> es geht, schreibt man sich ein kurzes (Assembler-) Programm, schiebt das >> über openOCD ins RAM des Prozessors ... und los geht's. Die "Ausgabe" >> lässt sich hinterher umgekehrt aus dem RAM des Prozessors auslesen. > Wow, so weit bin ich noch LANGE nicht ;-) Bevor ich ran gehe und mich in > fremden CPUs breit mache und die Macht übernehme, will ich erstmal > verstehen wie das Interface drumherum funktioniert. Naja, viel ist da nicht zu tun. Es läuft ja nur darauf hinaus, sich ein simples Datenformat (so etwa 'T' -> T auf '1' setzen, 't' -> T auf '0' setzen ...) auszudenken, und das abzuarbeiten. Könnte man auch in C, aber da muss man aufpassen, nicht versehentlich etwas aus der libc, oder startup-code vorauszusetzen. >> Mit dem Programm im Controller lässt sich sogar recht einfach per FIFO >> kommunizieren. (Im Moment zwar nur unidirektional Host->Target >> implementiert, aber die umgekehrte Richtung geht sinngemäß genauso, auch >> bidirektional mit 2 FIFOs wär' keine große Sache.) > Sprich dein Fremdcode welchen Du im Prozessor ausführen lässt erzeugt > Daten in einem Stack im RAM, welchen Du dann per JTAG ausliest und den > SP verringerst. Schlau, schlau ;-) Stack wäre eher unpraktisch, da LIFO. Aber das ginge prinzipiell natürlich auch. Die Kommunikation des Debuggers zum Controller könnte schon über JTAG laufen, aber einfacher über SWD (weniger Leitungen, STLink kann nur SWD). Aber eigentlich für diesen Zweck egal. >> So etwas geht auch mit einem FTDI-Adapter per Bitbanging, aber prinziell >> natürlich nur vergleichsweise langsam. > Könnte ich mir auch vorstellen, denn JTAG ist seriell, arbeitet mit > getrennten TX und RX Leitungen und ein paar Steuersignalen. Einzig der > Takt ist beim FTDI dann je nach eingestellter Baudrate fest Hm, ich meinte eher, dass u. U. für jedes Bit ein USB-Paket auf den Weg geht. Aber zum Ausprobieren ist das natürlich völlig egal.
Leider ist die Hardware oft so individuell, dass man doch das meiste selbst machen muss. Ich habe hier z.B. ein CPLD, an dem ein Dutzend seriell angesteuerter ICs hängen, je ein Chip Select dazu. Um die via Boundary Scan zu testen müsste ich doch das meiste zu Fuß ansteuern. Das taugt doch eher zum ersten Platinentest, ob irgendwo Lötfehler sitzen usw.
Falk B. schrieb: > Jaja, die Frickler-Fraktion läßt grüßen. Es gibt aber auch Leute, auch > Bastler, die wollen das alles nicht und eine fertig funktionierende > Lösung haben und dafür auch betreit sind, deutlich mehr als 3,fuffzich > auszugeben. Aber sicher doch. Viel Geld ausgeben, verwenden, aber hinterher doch keine blasse Ahnung haben, was da intern abläuft. Wem's gefällt ...
hier ist noch ein Beispiel wie mit openOCD per Python jede Menge Register ausliest: https://github.com/kanflo/opendps/blob/master/ocd-client.py
@Olli Z. (z80freak) >> Mit Hilfe der JTAG Statemachine. Jeder JTAG-Eingang hat eine einfache >> Statemachine, die mittels des TDI Eingangs gesteuert wird. Also muss man >> die richtige Bitsequenz reintakten, um den jeweiligen Zustand zu >> erreichen. Dann folgen die Daten bzw. Kommandos. >Aha, verstehe! Die genannte Bitsequenz ist also nochmal was anderes als >ein Kommando. So in der Art. >Wie und wo ist das denn definiert welche Sequenz für was gut ist? Kannst >Du mal ein Beispiel für eine solche Sequenz nennen? Ruhig abstrakt. Sagte ich bereits, in fast jedem Datenblatt eines ICs, der JTAG hat. Z.B. der ATmega328, siehe Anhang. Im ersten Bild sieht man das Blockschaltbild von allem, was am JTAG dranhängt. Die Blöcke sind mehr oder minder lange Schieberegister. Das 2. Bild zeigt die eigentlich sehr einfache JTAG-Statemachine. Die wird über TMS gesteuert (nicht TDI, mein Fehler). Je nach State landen dann die Daten in den verschiedenen Registerns. >Und dann geht man einfach hoch bis es nicht mehr klappt?! Ja, vermutlich >steht das im bsdl-File ;-) Naja, ich hab jetzt keinen wirklichen Überblick, welche Taktraten da so üblich sind. Ich hab mal so was im Bereich 10-50MHz gelesen, je nach IC. >> Nein. Aber es gibt viele Prozessoren, wo man in Echtzeit den Debugger >> per JTAG nutzen kann. >Ok, Debugger heißt ja doch, das man die Software auf dem Chip debugfähig >gemacht hat, sodass eine Kommunikation mit einem Debugger-Tool möglich >ist?! Sicher. >Cool! Genau was ich gesucht hab. Was mir dann nur fehlt ist, wie man den >Chip in einen Modus versetzt, das er auf dem JTAG-Interface (ich glaube >"TAP" genannt) diesen Boundary-Scan zulässt und durchführt. Bei den meisten ICs ist der JTAG-Port IMMER verfügbar, nur bei einigen uCs ist er per Fuses/Software abschaltbar. >Sowie eine Software mit der ich das machen kann. Was willst du denn machen? Zum Debuggen oder Programmieren braucht man die jeweilige Spezialsoftware, zum Setzen und Lesen von IOs gibt es mehrere Universalsoftwares, die aber meist recht eng an das jeweilige Hardwareinterface gebunden sind. >Dazu werde ich mich wohl mal mit OpenOCD, goJTAG auseinandersetzen >müssen. Eigentlich sollte es von Segger ja auch was dazu geben... Gibt es auch, aber ich hab davon keine Ahnung. >Gibt es Geräte in Geräten? Also das ein uC zunächst nur eine CPU oder >I/O-Register in die Chain einhängt (virtuell gesehen) und wenn er einen >bestimmten Befehl bekommt das dann auch plötzlich weitere Komponenten >wie ein externes Flash oder weitere I/O-Module "da" sind? Ja, dort hängen dann die diversen Spezialmodule im IC dran. Der Debugger ist so eins, die ISP-Schnittstelle zum Programmieren auch. >Vermutlich wird es oberhalb von Segger noch Tools geben die in einer >anderen Preisliga spielen (obwohl ich den schon sehr teuer finde). Sicher, da sind 10k-20k der EINSTIEGSPREIS! Die braucht aber ein normaler Mensch nicht, das ist was für Firmen, die das jeden Tag in Massen brauchen. > Aber >diese Open-Dinger arbeiten wohl eher mit Clone-Hardware zusammen. Naja, mit dem entsprechenden Frickel-Faktor.
@Olli Z. (z80freak) >Wenn das klappt, würde ich als nächstes schauen wo ich die bsdl-Files >für die gefundenen IDs her bekomme. Beim IC-Hersteller. > Wenn es dafür eine zentrale >Registriertungsstelle gibt, wie oben gesagt, dann kann man dort doch >sicher einen ID-Lookup durchführen. Glaub ich weniger.
Angehängte Dateien:
-
multicore.png
2,4 KB
Olli Z. schrieb: > Hab nur noch nicht verstanden wie man dann geziehlt ein Bauteil > anspricht. Sprich wie schalte ich ein Bauteil auf Bypass und woher weiss > ich wie ich das richtige erwische? Siehe angehängte Skizze, da ist noch keiner drauf eingegangen. Die Detektion funktioniert so, dass du durch dieses zusammengehängte IR (aller verketteten Bausteine, konstanter Grösse) irgend eine Zufallssequenz in den TDI clockst und die entsprechende Verzögerung am TDO vergleichst (Nerds würden von Autokorrelation sprechen). Damit hast du die Länge des IR <nIR>. Dann schaltest du alle Units auf Bypass, indem du <nIR> 1-Bits reinclockst. Bei korrekter Implementierung des JTAG-TAP ist jedes DR ein Bit lang, wie in der Grafik, Ausnahme Core B, der in dem Beispiel gezielt angesteuert wird. Die Länge des DR hängt dabei immer vom eingespeisten Wert im jeweiligen IR-Scheibchen des entsprechenden Core ab. Wenn dir die einzelnen Längen der IR schon aus dem BSDL-File kennst, gibt's ev. noch undokumentierte Befehle zu erraten. Wenn nicht, musst deine Detection per Einzelschrittigem Durchclocken von '1' bits die einzelnen IR-Sizes auch erraten. Boundary Scan ("EXTEST"-Befehl im IR) ist dabei eben nur einer von vielen, bei dem dann das DR zur Ansteuerung der Pins dient. Was goJTAG und OpenOCD angeht, würde ich zu einem einfachen FT2232-Adapter raten (achtung, die haben typischerweise 3.3V I/O), mit dem J-Link kann das ein heilloses Gemurkse werden, da es unterschiedliche Firmwares gibt, die einen tun, die andern nicht. goJTAG kann man auch in einer Art Simulationsmodus ohne Hardware austesten, das half schon einigen fürs Verständnis. Ansonsten sind richtig gute JTAG tools sauteuer bzw. bleiben komplett im Haus oder sind als relativ obskures Tool in einem typ. >50k€-Testsystem verbacken.
Falk B. schrieb: > Z.B. der ATmega328, siehe Anhang. Öhem, hust – gerade der hat nun keins. Ist die Ausnahme unter den ATmegas. Falk B. schrieb: >> Was ist denn dieses "ICE", davon hab ich schon paarmal gelesen. Auch von >>>einem "ICE Breaker" oder "ICE Crusher". > > Das sind aber alles Debugger bzw. Emulatoren, welche zum Programmieren > und Debuggen spezieller CPUs gebaut sind. Diese können NICHT die > normalen JTAG-Funktionen ansprechen, wie Setzen und Lesen von IOs! Bist du dir da eigentlich völlig sicher? Meiner Meinung nach benutzen die als Transport normales JTAG, und damit sollte man auch die Scanchain zugreifen können. JTAG ist dabei das Transportprotokoll, das Debugprotokoll sitzt darüber. (Bei OpenOCD kann man teilweise zwischen JTAG und SWD in der Software wählen, wenn der Adapter beides unterstützt.)
@Jörg Wunsch (dl8dtl) (Moderator) >> Z.B. der ATmega328, siehe Anhang. >Öhem, hust – gerade der hat nun keins. Ist die Ausnahme unter den >ATmegas. Ja, vertippt, 324 >> Das sind aber alles Debugger bzw. Emulatoren, welche zum Programmieren >> und Debuggen spezieller CPUs gebaut sind. Diese können NICHT die >> normalen JTAG-Funktionen ansprechen, wie Setzen und Lesen von IOs! >Bist du dir da eigentlich völlig sicher? Jain. >Meiner Meinung nach benutzen die als Transport normales JTAG, und >damit sollte man auch die Scanchain zugreifen können. Ja. > JTAG ist dabei >das Transportprotokoll, das Debugprotokoll sitzt darüber. Ja, aber es gibt im Normalfall bei der "Software oben drüber", also OSI Layer 6 oder 7 keine Software, die einzelne IOs anspricht, weil man das bei einem Debugger schlicht nicht braucht.
Falk B. schrieb: > Ja, aber es gibt im Normalfall bei der "Software oben drüber", also OSI > Layer 6 oder 7 keine Software, die einzelne IOs anspricht, weil man das > bei einem Debugger schlicht nicht braucht. Bei der nicht, aber niemand zwingt einen, die Hersteller-Tools zu benutzen. Ein Atmel-ICE oder J-Link lässt sich zumindest unter OpenOCD benutzen (genauso wie der genannte FT2232-Billig-Adapter), insofern wäre es denkbar, dass die oben genannten JTAG-Tools das ebenfalls können. Ich habe bislang JTAG allerdings auch nur zum Debuggen genutzt, irgendwann sogar mal zwei Controller in einer Chain. Ist aber beim Debuggen eher die Ausnahme.
Falk B. schrieb: > weil man das > bei einem Debugger schlicht nicht braucht. Das ist doch ein Standardfeature das ich per Debugger auch CPU Register lesen und schreiben kann und damit auch IOs oder andere Peripherie beeinflussen kann.
Johannes S. schrieb: > Das ist doch ein Standardfeature das ich per Debugger auch CPU Register > lesen und schreiben kann und damit auch IOs oder andere Peripherie > beeinflussen kann. Nein, das ist ein getrenntes Paar Latschen. Beim normalen Scan hast du die IOs von der CPU abgetrennt und bedienst sie komplett über die JTAG-Register. Das ist vom Prinzip her standardisiert, da es der ursprüngliche Zweck von JTAG ist. Was du willst, benutzt die (herstellerspezifische) Debugschnittstelle.
http://bsdl.info/view.htm?sid=956e3a0b5622bd9b88ca59b002289d77 das BDSL-File zum Atmega324P, als Beispiel. Drei Packages in einem File, ich dachte, man braucht für jedes Gehäuse ein eigenes. Das kann man wohl beim Aufruf über die "constant PDIP, TQFP, oder MLF" aussuchen. "attribute BOUNDARY_LENGTH of ATmega324P : entity is 57 ;" Das ist eher kurz.
:
Bearbeitet durch User
Wenn es nur darum geht an ein paar Pins händisch zu Wackeln ist https://www.jtaglive.com/de/content/jtag-live-buzz auch ganz nett. Funktioniert auch mit No-Name Ftdi basierenden Adaptern.
Leider ist es mir nicht gelungen das erlernte in die Praxis umzusetzen :-( Anscheinend will keines der genannten Programme (OpenOCD, goJTAG, LiveBuzz...) mit meinem Segger zusammenarbeiten. Auch scheint es nicht "üblich" zu sein unbekannte Systeme zu scannen. Daher komme ich bei Segger auch nicht weiter. Muss/sollte ich mir dann doch mal so einen USB Blaster o.ä. zulegen nur um weiter zu kommen?! Hmpf...
:
Bearbeitet durch User
@Olli Z. (z80freak) >Auch scheint es nicht "üblich" zu sein unbekannte Systeme zu scannen. Das stimmt so nicht. Wir haben in der Firma eine ältere Software von Atmel, ich glaub Atmelisp6.x, die kann Atmel-CPLDs in beliebigen JTAG-Ketten programmieren und die anderen ICs zumindest in Bypass schalten. Von Lattice gab es da auch mal was. >Daher komme ich bei Segger auch nicht weiter. Das ist halt ein Debugger, kein "normaler" JTAG Adapter. >Muss/sollte ich mir dann doch mal so einen USB Blaster o.ä. zulegen nur >um weiter zu kommen?! Hmpf... Sieht so aus.
Falk B. schrieb: > JTAG-Ketten programmieren und die anderen ICs zumindest in Bypass schalten. Ja, wenn ich das mit dem Scan richtig verstanden habe sollte das ja auch kein großes Hexenwerk sein, zumindest ist es hier im verlinkten Sourcecode in der Funktion "jtag_scan()" ganz gut ersichtlich: https://github.com/blacksphere/blackmagic/blob/master/src/target/jtag_scan.c >>Daher komme ich bei Segger auch nicht weiter. > Das ist halt ein Debugger, kein "normaler" JTAG Adapter. Hmm, aber neben dem Debugger gibt es dafür zahlreiche Tools wie den Flasher und Visualisierungen von IO-Pins. Teils aber wieder kostenpflichtig. Ich habe den Tipp bekommen für einen solchen Scan das Tool "JTAGLoad" aus der J-Link Software zu nutzen. Das werde ich heute Abend mal ausprobieren. Der jlink-commander und jlink-flasher wollen immer wissen was man anspricht. Da muss man vorher einen Chiptyp auswählen sonst fängt der garnicht erst an. >>Muss/sollte ich mir dann doch mal so einen USB Blaster o.ä. zulegen nur >>um weiter zu kommen?! Hmpf... > Sieht so aus. Die Dinger sind ja nicht so teuer, werde mir das unabhängig davon mal zulegen. So kann ich bei Bedarf das richtige Tool wählen.
Angehängte Dateien:
-
jtag_tap.gif
7,9 KB
Leider kann ich noch nicht was wirklich brauchbares vorweisen, aber ich glaub ich komme der "Lösung" immer näher, dank Eurer Hilfe :-) Wenn ich es recht verstanden hab, dann bilden eine oder mehrere Chips auf einem Board über die verbundenen TDI/TDO-Leitungen eine Kette, wobei die Signale TMS, TCK und TRST parallel an allen Chips anliegt. Mit der TMS-Leitung stellt man den Betriebsmodus über eine Statemachine ein (siehe Anhang). Dabei wird bei jedem TCK-Zyklus über den Zustand der TMS-Leitung der nächste Status bestimmt. Die Betriebmodus wären "Bypass, Capture, Preload und Extest" und werden über die letzten beiden Bits im Befehlsregister (IR) bestimmt. Um dieses Register zu beladen muss man den TAP-Controller auf dem Chip über die an TMS verbundene Statemachine erstmal in einen Zustand bringen, in dem man das Kommando über die TDI-Leitung des Chips "einschieben" kann. Dies erreicht man, wenn ich richtig liege, wie folgt (TCK-Zyklus 1->0->1 setze ich zwischen jedem TMS-Bit implizit voraus): TMS: 0 => Wechsel zum Run-Test/Idle modus (hier passiert noch nichts) 1 => Das DR-Register ist gewählt (wollen wir nicht) 1 => Das IR-Register ist gewühlt (hier wollen wir hin!) 0 => Sind nun im Caputre-IR (nö, weiter...) 0 => Sind nun im Shift-IR (JA, das wollen wir tun!) Nun bleibt TMS 0 und solange bleibt die Statemachine im Zustand "Shift-IR", sprich sie erwartet nun auf TDI die Bits die ins IR-Register kommen sollen. Bei jedem TCK schiebt die Statemachine somit ein TDI-Bit ein bis man TMS wieder auf 1 setzt. Und das tue ich dann: TDI: 1 => Niederwertigstes Bit (steht im Register nach Ende der Operation dann ganz rechts) 1 => nächstes Bit Jetzt setze ich TMS wieder wie folgt: 1 => Der Shift-IR Zustand wurde beendet und in den Exit1-IR gewechselt. Zu dieser Zeit liegen die auf TDI eingeschobenen Bits noch im IR-Register, sind aber noch nicht als Befehl erkannt/freigegeben. 1 => Nun im Zustand Update-IR werden die Bits vom IR-Register vom TAP-Controller als Befehl interpretiert (dazu unten mehr). 0 => Wieder zurück zum Run-Test/Idle Zustand. Wenn ich es richtig verstanden habe legen die beiden Bits im IR-Register folgenden Betriebmodus fest: 11 = Bypass (alle Bits von TDI werden auf TDO wieder ausgegeben, jedoch mit einem TCK Takt Verzögerung, weil sie erst im Puffer landen). 00 = Extest (Daten von TDI an die Boundary-Register für die externen Pins vorgaukeln) 01 = Caputre (Daten von den Boundary-Registern an TDO übertragen) 10 = Preload (Daten von TDI in die Boundary-Register übertragen) ------ Und wenn ich es richtig verstanden habe, dann greift man auf ein z.B. am Prozessor angeschlossenen Flash zu indem man die Pins, an dem die Adress und Enable-Leitungen das Flash-Speichers am Prozessor angeschlossen ist über JTAG mit entsprechenden Signalen bestückt (EXTEST Modus) und dann über JTAG die Pins ausliest an denen die Datenleitungen liegen (EXTEST). Somit hat die interne Logik des Prozessors garnichts damit am Hut, das ist reine TAP-Arbeit. Wow, ganz schön pfiffig ;-)
Olli Z. schrieb: > Und wenn ich es richtig verstanden habe, dann greift man auf ein z.B. am > Prozessor angeschlossenen Flash zu indem man die Pins, an dem die Adress > und Enable-Leitungen das Flash-Speichers am Prozessor angeschlossen ist > über JTAG mit entsprechenden Signalen bestückt (EXTEST Modus) und dann > über JTAG die Pins ausliest an denen die Datenleitungen liegen (EXTEST). Korrekt. Habe jetzt aber nicht alles gelesen... Ansonsten nochmal der Hinweis auf goJTAG, du kannst damit auch ohne Adapter rumspielen und einzeln die States der JTAG-Statemachine 'ansteppen'. Da die Doku dazu recht spärlich war, habe ich für unsere JTAG-Lösung mal was dokumentiert, findest im ICEbear-Manual unter Abschnitt 4.5: http://section5.ch/dsp/icebear/ICEbear-manual.pdf Mit ein bisschen Frickelei kannst du jeden FT2232H-Adapter zur Mitarbeit bewegen, wenn du schliesslich an der HW Pins toggeln willst. Das ist aber gerade mal nur Boundary Scan. ICE ist wieder ne ganz andere Sache. Guck dir sonst mal CoreSight an. Hab grade noch einen ausgegraben: http://section5.ch/doc/jtag/jtag-impl-ew2012.pdf (in der Annahme, dass English kein Thema ist..)
Falk B. schrieb: > @Olli Z. (z80freak) >>Kann man denn, wenn man es nicht weiss, einfach mit der niedrigsten >>Taktrate anfangen? > > Sicher, das ist aber das kleinste Problem. 1MHz schafft jeder IC, man > kann auch mit 10kHz anfangen. Denn das Protokoll ist wie SPI synchron. Auch an dieser Stelle kann es ordentliche Probleme geben, denn bei sehr vielen Microcontrollern gibt es Einschränkungen bezüglich des JTAG-Taktes. Dieser darf z.B. maximal die Hälfte oder ein Drittel des CPU-Taktes betragen. Wenn der Prozessor im Normalbetrieb, d.h. mit einigen MHz läuft, ist das kein Problem. Viele Microcontroller haben aber Stromsparmodi mit reduziertem Takt, der z.B. aus einem Uhrenquarz mit 32,768kHz generiert und dann womöglich noch geteilt wird. Somit benötigt ggf. man einen JTAG-Programmierschniepel, der auch Takte im unteren kHz-Bereich erzeugen kann. Wird z.B. kurz nach dem Reset der Stromsparmodus aktiviert oder muss das Aktivieren des hohen Prozessortaktes durch explizite Kommandos erfolgen, kann man sich ansonsten aus dem Prozessor aussperren. Sehr viele Prozessoren erlauben es nicht, unmittelbar nach einem Reset im Einzelschrittbetrieb loszulegen, sondern der JTAG-Debugger muss entweder die separate Resetleitung abfragen und dann schnellstmöglich die JTAG-Kommandos zum Aktivieren des Einzelschrittbetriebs senden, oder sogar per JTAG abfragen, ob ein Prozessorreset erfolgt ist. Bis dahin hat der Prozessor aber schon einige zig bis hundert Instruktionen ausgeführt. Mittlerweile kann man bei vielen Microcontrollern JTAG auch teilweise oder vollständig deaktivieren, d.h. entweder per Konfigurationsbits ("Fuses") oder indem per Design sichergestellt wird, dass während der ersten n Instruktionen der JTAG-Anschluss deaktiviert ist. Wenn sich die Firmware dann nicht debuggen lassen will, kann sie selbst JTAG dauerhaft deaktivieren. Nachtrag: Und dann gibt es auch noch JTAG mit Verschlüsselung, was allerdings nur wenige Prozessoren und Debugger unterstützen, wobei es sich eher um eine Art Kennwort handelt und nicht um eine Verschlüsselung der Nutzdatenübertragung.
:
Bearbeitet durch User
Martin S. schrieb: > Ansonsten nochmal der Hinweis auf goJTAG, du kannst damit auch ohne > ... > Mit ein bisschen Frickelei kannst du jeden FT2232H-Adapter zur Mitarbeit Weiss grad nicht mit welchen Adaptern der goJTAG noch alles kann, aber FDTI (also eigentlich "nur" ein USB zu RS232 Wandler) ist dabei. Theoretisch sogar mein Segger, jedoch über den Umweg von Zdiag (einer Art Universaltreiber für USB-Geräte). Aber ich will grad am Anfang nicht rumfrickeln müssen, sondern mein Wissen von Grund auf aufbauen. Ich merke jetzt schon das es mir zum Verständnis hilft zu wissen wie die einzelnen Bits laufen müssen. Dann verstehe ich auch die höheren Protokolle besser. > bewegen, wenn du schliesslich an der HW Pins toggeln willst. Das ist > aber gerade mal nur Boundary Scan. ICE ist wieder ne ganz andere Sache. Ganz genau DAS ist auch mein Meilenstein. Es ist mir durchaus klar das man z.B. Flash-Programmierung nicht mehr "zu Fuß" machen kann, das will ich auch nicht. Aber um da hin zu kommen ist es (zumindest für mich) extrem hilfreich zu kapieren wie das im Detail abläuft. Dir erstmal vielen Dank für die Infos. Zu lesen habe ich ohne Ende. Wär aber auch schön wenn wir hier konkret an meinen Ausführungen diskutieren könnten, denn nur damit erhalte ich ein Feedback ob ich alles verstanden habe :-)
Andreas S. schrieb: > Und dann gibt es auch noch JTAG mit Verschlüsselung, was allerdings nur > wenige Prozessoren und Debugger unterstützen, wobei es sich eher um eine > Art Kennwort handelt und nicht um eine Verschlüsselung der > Nutzdatenübertragung. Was Du da ansprichst erinnert mich an das was ich über das von mir zu debuggende System mit einem OMAP5948 gelesen habe. Es benötigt wohl eine bestimmte "Initialisierungssequenz" an den TAP des Chip damit der weiterhin mit einem redet. So weit bin ich aber noch lange nicht, da ich erstmal die Basics verstehen und umsetzen können muss. Nur mal so am Rande habe ich mit "J-Link Commander" (dem CLI-Tool von meinem Segger Interface) und dem CLI-Befehl "i" (Info) schonmal folgendes über mein System erfahren:
1 | C:\Program Files (x86)\SEGGER\JLink_V622g>jlink |
2 | SEGGER J-Link Commander V6.22g (Compiled Jan 17 2018 16:40:20) |
3 | DLL version V6.22g, compiled Jan 17 2018 16:39:42 |
4 | |
5 | Connecting to J-Link via USB...O.K. |
6 | Firmware: J-Link ARM V8 compiled Nov 28 2014 13:44:46 |
7 | Hardware version: V8.00 |
8 | S/N: 268004270 |
9 | License(s): FlashBP, GDB |
10 | OEM: SEGGER-EDU |
11 | VTref = 3.377V |
12 | |
13 | |
14 | Type "connect" to establish a target connection, '?' for help |
15 | J-Link>i |
16 | Device "ARM9" selected. |
17 | TotalIRLen = 50, IRPrint = 0x001444031F3D81 |
18 | JTAG chain detection found 3 devices: |
19 | #0 Id: 0x031F3D81, IRLen: 34, Unknown device |
20 | #1 Id: 0x0692602F, IRLen: 04, ARM9TDMI Core |
21 | #2 Id: 0x00000001, IRLen: 12, Unknown device |
22 | CP15.0.0: 0x41069263: ARM, Architecure 5TEJ |
23 | CP15.0.1: 0x1D112152: ICache: 16kB (4*128*32), DCache: 8kB (4*64*32) |
24 | Cache type: Separate, Write-back, Format C (WT supported) |
25 | Adaptive clocking not supported for selected CPU core. Only supported for -S cores. |
26 | Auto JTAG speed: 8000 kHz |
27 | JTAG Id: 0x0692602F Version: 0x0 Part no: 0x6926 Man. Id: 0017 |
28 | J-Link>q |
Die relevante Information für mich im Moment wäre nur die IDs aus dem/den Chips in der Scanchain zu erfahren und wieviele Geräte in der Chain verbunden sind. Dazu meine obigen Ausführungen...
steve schrieb: > https://www.youtube.com/watch?v=TlWlLeC5BUs > wenn du der englischen Sprache mächtig bist :-) Ja bin ich. Danke steve, das habe ich mir schon angesehen. Aber verstanden habe ich beim ersten mal noch nicht viel. Je mehr ich mich damit beschäftige desto mehr verstehe ich auch die Inhalte des Videos. Übrigends ein cooler Typ, ich mag seinen Blog.
Angehängte Dateien:
-
jtag_init.jpg
82 KB
So, einen Schritt weiter! :-) Habe mal meinen Logicanalyzer mit dem JTAG-Port vom J-Link Adapter verbunden und ein bischen rumgespielt. Im jlink.exe (J-Link Commander) gibt es scheinbar doch Lowlevel-Befehle: ---- JTAG-Hardware --- c00 Create clock with TDI = TMS = 0 c Clock tck0 Clear TCK tck1 Set TCK 0 Clear TDI 1 Set TDI t0 Clear TMS t1 Set TMS trst0 Clear TRST trst1 Set TRST r0 Clear RESET r1 Set RESET Damit kann man die Taktleitung (TCK) sowie die Modeselect-Leitung (TMS) ansteuern. Im Screenshot habe ich die einige Antworten vorher beschriebene Sequenz gesendet um die Statemachine im TAP so weit zu bekommen, das das IR-Register an TDI/TDO hängt. Die Sequenz lautete 0 1 1 0 0 (und dann bleibt TMS so lange 0 wie Bits ins IR geladen werden). Auf dem Screenshot gut zu erkennen, da der LA das JTAG-Protokoll versteht und über den Pegel anzeigt. Als nächstes würde ich dann gern wissen welche Instruktion ich ins IR laden muss, damit dieses das ID-Register an den Bus hängt und ich es auslesen kann.
Habe mir gestern zum testen einen alten Linksys Router WRT54 aus der Bastelkiste gezogen, weil ich diesbezüglich mal was über Debricken via Jtag gelesen hatte. Die Jtag Header Pins waren schnell ermittelt. Und siehe da, ich konnte auf Anhieb mit meinen Arduino Jtag Debugger marke Eigenbau den IDCODE auslesen!! :-) Das heißt das ich grundsätzlich richtig liege mit meiner Sicht auf die Funktionsweise von Jtag. Meine Bastellösung macht nichts anderes als via TMS und TCK die Statemachine zunächst in den Modus Test-Reset und dann in Scan-DR zu versetzen um anschließend an TDI 32 Bits zu lesen. Laut Spezifikation legt ein Jtag Chip nach dem TAP-Reset seinen IDCODE ins DR Register. Zumindest für den Broadcom Chip der auf dem Router verbaut ist stimmt das auch. Habe das ganze dann noch mit dem USB-Blaster und Quartus Jtag-Debugger, sowie dem Segger JLink Commander verifiziert. Passt! Endlich mal ein Erfolg. Das mein eigentlicher Testkandidat (Displayboard) die Zusammenarbeit verweigert liegt also ab was anderem. Evtl. ist der Cyclone ja erst nach einer bestimmten Bedingung zum Jtag bereit. Ich teste das heut Abend nochmal. Als nächstes werde ich mich dann mit SVF beschäftigen um in die nächst höhere „Jtag-Bewußtseinsebene“ zu gelangen ;-) Damit kann ich dann ja sogar schon lowlevel Befehle erstellen. Zunächst teste ich noch meine IRLen Detection. Laut Quartus hat der BCM5352 vom Linksys 8 Bit im IR. Ich werde berichten!
Auch die IDCODE Register auf dem Mainboard mit dem OMAP5948 konnte ich nun mit meiner Bastellösung sicher auslesen. Der Trick hierbei war, die TRST-Leitung auf HIGH zu ziehen. Die ist scheinbar intern nicht mit einem Pullup versehen, oder vielleicht sogar eher absichtlich mit einem Pulldown damit die JTAG-Logik nicht mitläuft. Das hat gefehlt und daher befand sich der TAP-Controller im OMAP immer im RESET Zustand. Jetzt erhalte ich folgende Bits aus dem 32 Bit Register: 0000 0011000111110011 11011000000 1 (=0x031F3D81). Soweit mir bekannt setzt sich das IDCODE Register wie folgt zusammen: 4 Bits Version (meist '0000') 16 Bits Part Number 11 Bits Manufacturer Identity (JEDEC genormt) 1 Bit LSB (immer '1') Die Hersteller-Bits wären also: 110 1100 0000 (= 0x6C0). Jedec spezifiziert hier aber eigentlich nur 8 Bits (siehe https://www.mikrocontroller.net/attachment/39268/jep106k.pdf) Wie ist das zu lesen? Auf dem Display-Board mit dem EP2C8 scheint das zu passen. Hier bekomme ich den IDCODE: 0000 0010000010110010 00001101110 1 (=0x020B20DD) Die Hersteller-Bits sind demnach 00001101110 (=6E) und laut Liste "Altera". Passt wunderbar! :-) 00001101110
:
Bearbeitet durch User
Nun konnte ich auch ohne größere Probleme die Methode zur Erkennung der Anzahl JTAG-Controller (=Chips) in der Chain umsetzen und das sogar mit meiner Billig-Bitbang-Arduino-Lösung ;-) Das Prinzip basiert auf folgender Definition von JTAG: * Jeder JTAG-Controller muss den BYPASS Mode kennen * Dieser wird aktiv, wenn im Befehlsregister (IR) das erste und letzte Bit 1 ist (1....1) * Anschließend wird zwischen TDI und TDO eines jeden Chips ein nur 1-Bit breites Schieberegister für Daten (DR) geschaltet. Wobei der Inhalt vom Chip weder beschrieben noch ausgewertet wird. Sind also alle Teilnehmer in der Chain im Bypass-Modus, dann geben sie die Daten von TDI mit einer Verzögerung von einem Takt am TDO wieder aus. Man schreibt also erstmal jede Menge 0en in die Chain (=Datenregister) sodass mutmaslich alle Chips diesen Zustand in ihrem Datenregister haben. Anschließend schreibt man 1en und zählt die Takte bis am TDI des Testers auch eine 1 erscheint. Die Anzahl der Takte ist dann gleich der Anzahl der JTAG-Devices. Mit diesem Test kann man auch noch prüfen ob alle Chips in den Bypass Mode gegangen sind. Denn nachdem man die DRs mit 0en geflutet hat, darf beim ersten zurücklesen keine 1 kommen. Falls doch, stimmt was nicht. Jedenfalls habe ich das wie folgt kodiert:
1 | TAP_GotoReset(); |
2 | TAP_GotoShiftIR(); |
3 | TAP_SendBits(1, 999); // will force all chips in chain to BYPASS mode |
4 | digitalWrite(TDO, 1); |
5 | digitalWrite(TCK, LOW); // TDO is valid on falling edge |
6 | digitalWrite(TMS, 1); |
7 | digitalWrite(TCK, HIGH); // TMS is taken on rising edge |
8 | // now we are in state "Exit1-IR"
|
9 | TAP_GotoShiftDR(); |
10 | // now all JTAG-Controllers should be in BYPASS mode
|
11 | TAP_SendBits(0, 1000); // "clear" dataregister of all chips |
12 | // now send ones until we receive one back
|
13 | int d; |
14 | for(d=0; d<1000; d++) |
15 | {
|
16 | digitalWrite(TDO, HIGH); |
17 | digitalWrite(TCK, LOW); // chips take data from their TDI at falling edge of TCK |
18 | digitalWrite(TCK, HIGH); // chips shift out on TDO |
19 | if (digitalRead(TDI)) { |
20 | break; |
21 | }
|
22 | }
|
23 | Serial.print("Number of devices determined: "); |
24 | Serial.println(d, DEC); |
25 | TAP_GotoReset(); |
Das ist sicher nicht elegant, funktioniert aber einwandfrei! Ich konnte auf dem Displayboard 1 Chip und auf dem Mainbaord 3 Chips erkennen. Nun weiss ich auch das ich auf dem Mainboard 3x 32-Bit IDCODE lesen kann/muss um die IDs aller Chips zu ermitteln. So langsam komme ich der Sache immer näher :-)
Mich würde jetzt interessieren wie man via JTAG einen Flash-Speicher programmiert, der mit all seinen Pins an einem FPGA hängt, welches einen JTAG-Controller besitzt. Ich stelle mir das grundsätzlich so vor: Zuerst muss ich die Pins identifizieren die vom FPGA zum Flash gehen und deren "Bitposition" im DR ermittelen. Hierbei sollten mir die Herstellerangaben helfen diese zu finden. Dann müsste man ein JTAG-Kommando senden, welches die interne Logik des Chips von den BS-Registern der Pins abkoppelt, sodass ich mit den Pins tun kann was immer ich will. Wenn mir auch das gelingt, wäre wohl der nächste Schritt die eigentliche Programmierung. Vereinfacht würd ich das so sehen: - Adress- und Daten-Bits, sowie das CE-Bit ins DR schieben. Der Flash sollte dann "empfangsbereit" sein - Anschließend nochmal dieselben Bits reinschieben, jedoch mit WE - Zuletzt nochmal das gleiche Muster, jedoch ohne WE Und das per Prinzip für jede Adresse. Auslesen entsprechend, aber mit OE anstelle WE. Wenn der Flash, so wie meiner hier, einen 16 Bit Datenbus hat, sich aber auf 8 Bit umstellen lässt, muss ich halt nur doppelt so viele Adressen lesen und ggf. die Bytes wieder "zusammenstopfen". Selbstverständlich hat so ein Flash-Chip ein zu beachtendes Protokoll wie CFI, einfach so drauflosschreiben/lesen ist wohl nicht. Das kenn ich noch nicht, aber vermutlich wird wenigstens eine Initialisierungssequenz notwendig sein, wenn nicht sogar ein Kommando pro Lese- oder Schreibvorgang. Bevor ich mir nun solch eine Software selbst entwickele meine Fragen: 1.) Sehe ich das so alles richtig? 2.) Gibt es nicht bereits fertige Flash-Tools die genau sowas mit Hilfe von JTAG machen?
Olli Z. schrieb: > Bevor ich mir nun solch eine Software selbst entwickele meine Fragen: > 1.) Sehe ich das so alles richtig? Ich habe das jetzt nicht im Detail nachverfolgt, aber es könnte so gehen. > 2.) Gibt es nicht bereits fertige Flash-Tools die genau sowas mit Hilfe > von JTAG machen? Ja, z.B. Xilinx Vivado (und iMPACT für ISE) unterstützten das Programmieren von Flash-Bausteinen "hinter" dem FPGA. Ich gehe davon aus, dass korrespondierenden Werkzeuge von Intel/Altera usw. dies ebenfalls beherrschen. Bei Microcontrollern gibt es neben der direkten Ansteuerung der Flash-Steuersignale noch die Möglichkeit, zunächst eine kleine Programmierroutine ins RAM zu laden und nacheinander jeden Datenblock zunächst ebenfalls ins RAM zu laden, dann die Routine laufen zu lassen, usw. Lauterbach nennt diese Betriebsart "Target based programming" und beschreibt auch recht genau, wie man selbst solch eine Programmierroutine schreibt. Dadurch können auch ungewöhnliche Speicherorganisationen oder Businterfaces bedient werden. Außerdem ist es wesentlich schneller, als wenn jedes Flash-Kommandos erst einmal bitweise durchgeklötert werden muss.
Danke. Um die Performance ging es mir in erster Instanz erstmal nicht, sonder eher um die Machbarkeit. Ein Unterschied für mich ist noch, das man für die JTAG Methode kein Programm für den Zielchip erstellen muss. Bei einem FPGA wüsste ich garnicht wie und womit.
Andreas S. schrieb: > Ja, z.B. Xilinx Vivado (und iMPACT für ISE) unterstützten das > Programmieren von Flash-Bausteinen "hinter" dem FPGA. Bei xc3sprog geht das auch. Da kann man in die Quellen reinschauen.
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.