Hallo Ich hätte hier mal eine Frage zum JTAG Protokoll, das bei den AVR Mikrocontrollern verwendet wird. Die Spezifikation wann welche Signale kommen müssen, sind in den Atmel Datenblättern ja zumindest qualitativ beschrieben. Aber welchen Wert ich jetzt z.B. in das IR Register clocken mussen, damit ich spezielle interne Register lesen kann, ist nicht beschrieben. Ich nehm mal an, dass Atmel die Spezifikation nicht wirklich rausgeben will, da ich bei Google und Co nichts gefunden habe. Deshalb wollt ich mal fragen, ob jemand vielleicht die Spezifikation hat bzw. ob sich jemand schonmal etwas genauer damit beschäftigt hat. Der Grund, warum ich diese Informationen brauche, ist, weil ich ein Projekt an der Uni mache, bei dem wir einen JTAG ICE MK II kompatiblen Debugger machen sollen (jedoch mit einem Cypress Controller). Die Möglichkeit die Controller Software des AVR Studios zu verwenden besteht also nicht. Vielleicht hat jemand ja ein paar Informationen. mfg Andreas
Kurz noch was dazu... ahm.. gibt es vielleicht einen parallelen JTAG Adapter, bei dem die Signale (TMS, TCK,...) direkt durch eine Debug Software erzeugt wird?? Wenn die Software auch noch Open-Source wäre, dann wäre das auch perfekt! Vielleicht weiß jemand was. mfg Andreas
Soweit mir bekannt, gibt es keinen AVR JTAG Debugger ohne Atmel-spezifische JTAG Firmware im Adapter. Eine grobe Übersicht über Debugger-Hardware findest du bei http://www.mikrocontroller.net/articles/JTAG#AVR_JTAG
Ohje... das hab ich fast befürchtet... dann muss ich also doch mit Messen und Reverse Engineering anfangen.
Warum? Mir erschliesst sich der Hintergrund der Aufgabenstellung nicht. Dein Adapter wird dadurch extrem uninteressant. Sobald Atmel einen neuen Prozessor rausbringt, müssen die Adapter eh neu angepasst werden. Bei Atmel passiert das durch den Upload der offiziellen Firmware. Bei deinem Adapter mit eigenem µC und eigener Firmware (bzw. Software im PC statt Firmware) ist ein neues Reversing und ggf. eine Anpassung beim "Hersteller" erforderlich. Das zieht keine Kunden an ;-) Bist du sicher, dass dein Prof. einen Cypress Controller für alle Aufgaben des Adapters einsetzen will? Oder soll ggf. der Cypress Controller nur für die USB (oder Ethernet?) Kommunikation mit dem PC eingesetzt werden und ein Atmel Controller für die JTAG Kommunikation mit dem Host? So ein Mixsystem auf Basis eines Atmega32 und eines USBN9604 (Universal Serial Bus Full Speed Node Controller with Enhanced DMA Support von National Semiconductor) hat ja Benedikt Sauter aufgebaut http://www.embedded-projects.net/index.php?page_id=135
Andreas Auer wrote: > Der Grund, warum ich diese Informationen brauche, ist, weil ich ein > Projekt an der Uni mache, bei dem wir einen JTAG ICE MK II kompatiblen > Debugger machen sollen (jedoch mit einem Cypress Controller). ... > ... dann muss ich also doch mit > Messen und Reverse Engineering anfangen. Ist Deine Uni vielleicht in China ? Ansonsten würde ich davon abraten, kriminelle Sachen an ner Uni zu machen. Peter
Erstmal danke für die Antworten. Das mit dem Update des Adapters über das AVR Studio hab ich schon mitbekommen. Keine Angst... Und ob der Adapter interessant wird oder nicht, sei mal eher dahingestellt. Ich hab jetzt nicht vor aus dem Projekt ein finaziell gewinnbringendes Produkt hervorzubringen. In erster Linie geht es hier auch mal um die Realisierbarkeit. D.h. ich bin hier auch mal auf der Suche nach Informationen über JTAG und wie Atmel dies implementiert hat. Da ich Google mäßig wenig gefunden habe, dachte ich mir, ich frag hier mal nach (meist bekommt man ja auch konstruktive Hinweise). Btw. der Cypress Controller wurde gewählt, weil es ein Experimentierboard mit diesem Controller gibt. Hardwaremäßig wäre es natürlich schön nur diesen Cypress Controller einsetzen zu können um einen JTAG Debugger zu bauen. Aufwand und Sinnhaftigkeit dieses Projekts müssen sich nach etwas Recherche nochmal herausstellen. Ich will auch nicht was nachbauen (ist ja meinst nicht sonderlich lehrreich), sonder untersuchen, ergründen, ob es möglich ist sowas zu realisieren und inwiefern das Ding dann auch funktioniert. @Peter: Also momentan bin ich mir nicht wirklich einer kriminellen Handlung bewusst. Ich hab ja nicht vor ein JTAG Konkurenzprodukt zu Atmel zu bauen, das ich dann im großen Stil verkaufen will. Außerdem weiß ich nicht, ob ein Unterschied besteht, ob man nun einen JTAG Debugger baut und die Firmware von Atmel benutzt oder ob man eine selbst gestrickte Firmware auf einem ganz anderen Controller benutzt. Aus dieser Sicht würd ich sogar meinen, dass mein Unterfangen absolut keine kriminelle Handlung darstellt. Ich hätte jetzt auch nicht irgendwo gelesen, dass man das JTAG Interface nicht benutzen darf. Aber falls ich was übersehen habe, kannst du mich ja gerne aufklären. Schönen Tag, Andreas
http://de.wikipedia.org/wiki/Reverse_Engineering 1/ "Die Erschließung der Regeln eines Kommunikationsprotokolls aus der Beobachtung der Kommunikation, z. B. mit einem Sniffer." Ist eine Form des Reverse Engineering. 2/ "Die Analyse von Protokollen ist davon rechtlich nicht betroffen, weil dabei die Software selbst gar nicht Gegenstand der Untersuchung ist." Wenn man sich auf das Protokoll beschränkt und ggf. nachweisen kann, dass alle Informationen aus dem Protokoll selbst gewonnen wurden und keinesfalls die Software disassembliert oder sonstwie untersucht wurde. Stichwort auch Clean-Room Reverse-Engineering 3/ "Benutzt man das Ergebnis des Reverse Engineerings zum gewerblichen Nachbau, so wird man sich mit der großen Menge der gewerblichen Schutzrechte (z. B. Plagiat) in ähnlicher Weise konfrontiert sehen, so wie es auch bei Ergebnissen der ganz normalen eigenständigen Forschung und Entwicklung der Fall sein kann (z. B. Patent)." Sinnvolle Patente sind universell abgefasst. Im Beispiel würde in einem fiktiven Patent/Gebrauchsmuster zu einem JTAG-Adapter irgendein µC/FPGA/IC als Funktionsbaustein im Adapter drinstehen und keine Beschränkung auf explizite Atmel-µC. Damit wäre der Cypress Controller ebenfalls im Schutzbereich des Patents. Fazit: Das Vorhaben muss nicht kriminell sein. Allerdings kann eine gute Rechtsberatung nicht schaden...
Da gab's mal ein Projekt namens FreeICE. Allerdings scheint das ganze nicht mehr weitegeführt zu werden. siehe auch : http://gnu.rtin.bz/ftp.gnu.org/savannah/files/freeice/AVR-OCD-Documentation.html
Andreas Auer wrote: > Hallo > > Ich hätte hier mal eine Frage zum JTAG Protokoll, das bei den AVR > Mikrocontrollern verwendet wird. Die Spezifikation wann welche Signale > kommen müssen, sind in den Atmel Datenblättern ja zumindest qualitativ > beschrieben. Aber welchen Wert ich jetzt z.B. in das IR Register clocken > mussen, damit ich spezielle interne Register lesen kann, ist nicht > beschrieben. > Hallo Andreas, JTAG ist ein IEEE Standard, daher ist die Spezifikation der Signale bzw. deren zeitliche Abfolge fix. Falls Du interesse hast kann ich dir eine detailierte Beschreibung über alle JTAG relevanten Dinge geben. Die möglichen Instruktionen sind im Boundary Scan Descrption File (BSD) zusammengetragen, welches vom Hersteller zu beziehen ist, bzw. auch aus dem Datenblatt. Darin wird die Scan-Kette, die entsprechenden Zellentypen ,die verfügbaren Instruktionen uvm. definiert. Normalerweise ist das Instruktionsregister 4, 8 oder 16 Bit lang. Es gibt einige Instruktionen die immer vorhanden sind: BYPASS (alles 0) EXTEST (alles 1) IDCODE (Herstellerspezifisch) ... Um eine Instruktion zu laden mußt du in den IR-SCAN Pfad gehen und mit 4,8 oder 16 SHIFT-IR clocks den Befehl laden. Beim Verlassen des UPDATE-IR States wird zwischen TDI und TDO das gewünschte Register freigeschalten. Z.B wird nach dem Laden der Instruktion BYPASS lediglich eine Zelle zwischen TDI und TDO geschaltet. Wenn du jetzt in den SCAN-DR Pfad wechselst kannst du dieses Register beschreiben, um z.B den Ausgang eines Ports zu setzten, oder lesen, um. z.B den Eingang eines Ports zu lesen. Details zum Laden: # Das erste Datum das geladen werden muß ist LSB! # Zelle 0 liegt beim TDO # Daten an TDI werden bei der steigenden Flanke von TCK gelatched. # Daten an TDO werden mit der fallenden Flanke von TCK gültig. # Das erste Bit (LSB) wird bei beim zweiten Zustand SHIFT-DR/IR gelatched. # Das letzte Bit (MSB) wird beim erreichen des EXIT-1-DR/IR Zustandes gelatched. Hoffe das hilft ein wenig weiter. Christian > Ich nehm mal an, dass Atmel die Spezifikation nicht wirklich rausgeben > will, da ich bei Google und Co nichts gefunden habe. Deshalb wollt ich > mal fragen, ob jemand vielleicht die Spezifikation hat bzw. ob sich > jemand schonmal etwas genauer damit beschäftigt hat. > > Der Grund, warum ich diese Informationen brauche, ist, weil ich ein > Projekt an der Uni mache, bei dem wir einen JTAG ICE MK II kompatiblen > Debugger machen sollen (jedoch mit einem Cypress Controller). Die > Möglichkeit die Controller Software des AVR Studios zu verwenden besteht > also nicht. > > Vielleicht hat jemand ja ein paar Informationen. > > mfg > Andreas
Andreas Auer wrote: > Also momentan bin ich mir nicht wirklich einer kriminellen Handlung > bewusst. Das schützt nicht vor Strafe. > Ich hab ja nicht vor ein JTAG Konkurenzprodukt zu Atmel zu > bauen, das ich dann im großen Stil verkaufen will. Das ist vollkommen nebensächlich. Informationen sind auch werthaltig. Und damit ist es Unrecht, sie sich gegen den Willen des Besitzers zu verschaffen. Frag doch einfach mal bei Atmel nach, ob sie sie rausrücken oder nichts gegen ein Reverse Engineering haben. Bzw. es kann auch sein, daß sie die Nutzung gestatten, wenn Du ein NDA unterschreibst. Peter
Hallo Ch. Kupnick wrote: > JTAG ist ein IEEE Standard, daher ist die Spezifikation der Signale bzw. > deren zeitliche Abfolge fix. Falls Du interesse hast kann ich dir eine > detailierte Beschreibung über alle JTAG relevanten Dinge geben. Zum IEEE Standard (Doku) hab ich über die Uni zugang. Ich hab das Datenblatt zu JTAG aber nur mal überflogen. Jedoch hab ich mitbekommen, wie das mit der State Machine (TAP Controller) funktionieren soll. Was mir aber gefehlt hat, waren die IR Werte für die Atmel Controller. Dank deiner Hilfe hab ich nun aber auch die BSD Files von Atmel gefunden, in dem zumindest schonmal die Instruktionen stehen (IR ist ein 4 Bit Register). Damit kann ich auf jedenfall schonmal was anfangen. Dank dir jedenfalls schonmal. > Hoffe das hilft ein wenig weiter. Das hilft auf jedenfall sehr weiter! mfg Andreas
Peter Dannegger wrote: > Andreas Auer wrote: >> Ich hab ja nicht vor ein JTAG Konkurenzprodukt zu Atmel zu >> bauen, das ich dann im großen Stil verkaufen will. > > Das ist vollkommen nebensächlich. Laut Stefan ist das gar nicht so nebensächlich. > Frag doch einfach mal bei Atmel nach, ob sie sie rausrücken oder nichts > gegen ein Reverse Engineering haben. > > Bzw. es kann auch sein, daß sie die Nutzung gestatten, wenn Du ein NDA > unterschreibst. Genau das hab ich auch schon gemacht. Hab an Atmel eine Anfrage gestellt, ob es gestattet ist und ob sie mehr Informationen haben. Noch hab ich keine Antwort bekommen. Je nach Antwort muss man dann weitersehen. mfg Andreas
Andreas Auer wrote: > Genau das hab ich auch schon gemacht. Hab an Atmel eine Anfrage > gestellt, ob es gestattet ist und ob sie mehr Informationen haben. Noch > hab ich keine Antwort bekommen. > Je nach Antwort muss man dann weitersehen. Ruf doch einfach mal bei Ineltek oder MSC an. Peter
Wie gesagt hab ich an Atmel eine Anfrage gestellt, ob sie weitere Infos haben bzw. ob es legal ist, wenn ich sowas an der Uni als Projekt mach. Zurück kam nun folgendes: > Unfortunately there are not so much information on our JTAGICE mkII > available. Please see http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3353 for the > available information. You will also find some information in AVR Tool User > Guide in AVR Studio Help files. > > Good luck with your project. Ich denke also, dass wir das Projekt mit gutem Gewissen fortsetzen dürfen. Und es ist ja "nur" ein Projekt ohne gewerbliche Absichten und damit nach diesem Semester wieder vorbei (mit der kleinen Zugabe, dass ich danach einen JTAG Debugger besitze und 350 Euro gespart habe). Ich danke nochmal allen für ihre Informationen zu JTAG selbst sowie zum rechtlichen Aspekt. mfg Andreas
> mit der kleinen Zugabe, dass ich danach einen JTAG Debugger besitze und 350 Euro
gespart habe
Dann rechne dir mal aus wieviel du verdient hättest, wenn du die Zeit
stattdessen irgendwo gearbeitet hättest ;)
Hallo Andreas, habt Ihr schon Ergebnisse? Bin auch gerade am zusammensammeln für Informationen, um einen komplett freien AVR JTAG Debugger zu basteln. Werde wohl aus dem Projekt FreeICE die Hardware gipper irgendwie als Basis verwenden. Dort haben sich die Jungs schon alles an Informationen hergeholt was man so braucht. Also wenn das jetzt nicht gezielt eine Projektarbeit oder so von dir ist wuerde ich sagen wir sollten und fast gemeinsam die zentralen Funktionen schreiben. (Bin auch noch Student) Gruss Bene
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.