Hallo Leute,
ich brauche mal Hilfe bei der Auswahl eines passenden JTAG Atapters,
bzw. ISP. Mein Haupt-Ziel wird es sein, mal ein laufendes Programm auf
einem AVR anzuhalten und zu debuggen.
Allerdings halten sich meine Erfahrungen mit JTAG in Grenzen. Ich habe
mal einen WRT54GL beim Aufspielen von DD-WRT geschrottet. Anschließend
konnte ich ihn mit einem selbstgebauten JTAG Kabel aus einem Sub-D
Stecker und ein paar Widerständen wiederbeleben. Der JTAG Anschluss war
damals 12-Polig
Dann gibt es irgendwie 10 Pin JTAG Ports oder auch 6 Port Ports.
Was ich momentan nicht verstehe ist, was ich denn so brauche, damit es
so eine Art Universal-Tool wird. Es gibt z.B. den Bus Blaster für rund
30 EUR, oder den AVR JTAG ICE MKII für 350 EUR.
Alternativ gibt es in der Bucht auch z.B. die Riff Box, mit der
Bootloader-Probleme bei verschiedenen Mobiltelefonen wiederherstellen
kann.
Als Anfänger bin ich da momentan irgendwie voll überfragt, was ich mir
denn für ein Device kaufen sollte.
Könnt ihr mir da etwas helfen?
JTAG ist nur die Schnittstelle. Die Funktion ist ein anderes Paar
Schuhe.
Ganz grob gibt es
- Programmierer (günstig, nur Flash-Programmieren und -Lesen)
- Debugger (etwas teurer, zum Debuggen wie der Name schon sagt)
- Emulatoren (teuer, sehr leistungsfähig zur Entwicklung)
Der AVRISP ist ein reiner Programmer, damit kann man nicht debuggen.
Der AVRDragon ist ein meines Wissens schon ein echter Debugger.
Der AVRICE ist ein "In Circuit Emulator" und entsprechend leistungsfähig
und teuer.
Bronco schrieb:> Der AVRICE ist ein "In Circuit Emulator" und entsprechend leistungsfähig> und teuer.
Nein, es ist klassenmäßig ähnlich dem AVR Dragon angesiedelt (oder
einem nicht ganz so teuren JTAGICE3).
„Echte“ Emulatoren waren früher üblich und wirklich sehr teuer. Basis
dabei war ein FPGA, das den digitalen Code des Prozessors enthielt,
ergänzt um (diskret hinzugefügte) wesentliche Peripherie des
Controllers.
Auf diese Weise erhielt man einen einigermaßen originalgetreuen Nachbau
des Controllers, bei dem man aber interne Busse „anzapfen“ konnte (aus
dem FPGA rausführen).
All die JTAG-Debugger sind keine wirklichen Emulatoren mehr, das sie
ja direkt auf der Ziel-CPU aufsetzen (statt sie zu emulieren). Man hat
also in der echten Hardware Eingriffspunkte geschaffen, und greift
über die (bereits aus anderen Gründen vorhandene) JTAG-Schnittstelle
darauf zu. Das ist deutlich preiswerter als ein Voll-Emulator.
Hmmm... Mir ist momentan nicht klar, ob es sich wirklich lohnt, den AVR
ICE MKII zu holen oder das Dragon Board.
Und was ist jetzt der Unterschied dieser Tools zu den ganzen angebotenen
JTAG Boxen, wie z.B. hier auf der Seite:
http://www.fonefunshop.co.uk/Unlocking/sagemjigs.htm
Jetzt einfach mal laut gedacht. Heute möchte ich mit dem Teil ISP und
Debugging eines AVRs machen. Wenn ich es richtig verstehe, reicht mir da
ein Dragon Board aus.
Und mal so gefragt: Als damals mein WRT54GL Router sich verabschiedet
hat, hatte mein Rechner noch einen LPT Port. Kann ich mit dem Dragon
Board oder mit dem ICE KMII genauso die Firmware wiederherstellen, wie
mit dem zusammengelöteten Kabel?
@ Mathias Ahrens (Gast)
>Jetzt einfach mal laut gedacht. Heute möchte ich mit dem Teil ISP und>Debugging eines AVRs machen. Wenn ich es richtig verstehe, reicht mir da>ein Dragon Board aus.
Ja.
>Und mal so gefragt: Als damals mein WRT54GL Router sich verabschiedet>hat, hatte mein Rechner noch einen LPT Port. Kann ich mit dem Dragon>Board oder mit dem ICE KMII genauso die Firmware wiederherstellen, wie>mit dem zusammengelöteten Kabel?
Ja.
Mathias Ahrens schrieb:> Und was ist jetzt der Unterschied dieser Tools zu den ganzen angebotenen> JTAG Boxen
Dass bei JTAG nur die Hardwareschnittstelle selbst sowie die
Funktionalität für den ursprünglichen Verwendungszweck
(Verdrahtungstests komplexer Platinen; JTAG = “Joint Test Access
Group”) genormt ist.
Die Erweiterungen der Schnittstelle zum Debuggen sind aufgesetzt und
nicht standardisiert. Vielfach werden sie komplett herstellerspezifisch
und proprietär realisiert; lediglich bei ARM ist die ganze Sache durch
ARM selbst wieder genormt, weshalb dort 3rd-party-Lösungen preiswert
zu haben sind (aber teilweise mit Abstrichen in der Funktionalität
gegenüber den „aufgebohrten“ Debuggern der Hersteller).
Kurz und gut: einen AVR kannst du nur mit einem der Atmel-Tools
debuggen,
die JTAG (bzw. PDI bei Xmega oder debugWIRE bei den kleinen AVRs)
anbieten. Mit diesen wiederum kannst du aber weder einen ARM noch dein
Smartphone debuggen.
Rene H. schrieb:> Kann der Ice III auch ISP? So wie ich das verstanden habe nein.
Dann hast du das falsch verstanden. Seitdem es debugWIRE gibt, welches
für das Handling unbedingt auch ISP zusätzlich benötigt, hatte man
bereits im JTAGICEmkII ISP implementiert, und genauso ist das auch im
JTAGICE3.
Jörg Wunsch schrieb:> Dann hast du das falsch verstanden. Seitdem es debugWIRE gibt, welches> für das Handling unbedingt auch ISP zusätzlich benötigt, hatte man> bereits im JTAGICEmkII ISP implementiert, und genauso ist das auch im> JTAGICE3.
Danke! Das heisst das wenn ich den JTAG ICE III habe, der AT AVR ISP2
redundant ist?
Korrekt?
Grüsse,
René
Rene H. schrieb:> Das heisst das wenn ich den JTAG ICE III habe, der AT AVR ISP2 redundant> ist?
Nun ja, sagen wir mal, die Zielrichtung des AVRISPmkII liegt etwas
anders: das soll ein robuster Massenprogrammierer sein, der schnell
und zuverlässig ist. Daher ist er recht robust gegen Fehlbedienungen
gebaut worden. Sofern man einen Controller mit genügend hohem
CPU-Takt programmiert, ist er auch deutlich schneller als ein
JTAGICE{mkII,3} (bei den standardmäßigen 1 MHz spielt das aber keine
Rolle).
Aber wenn es nur um die Möglichkeit, ISP zu machen, überhaupt geht, ja,
dann decken sowohl JTAGICEmkII als auch JTAGICE3 (oder der AVR Dragon)
dies mit ab.
> Aber wenn es nur um die Möglichkeit, ISP zu machen, überhaupt geht, ja,> dann decken sowohl JTAGICEmkII als auch JTAGICE3 (oder der AVR Dragon)> dies mit ab.
Der MKII kennt keinen Atmega8.
mfg.
PS: Das ist aber schade. Heul.
Jörg Wunsch schrieb:> Die Erweiterungen der Schnittstelle zum Debuggen sind aufgesetzt und> nicht standardisiert. Vielfach werden sie komplett herstellerspezifisch> und proprietär realisiert; lediglich bei ARM ist die ganze Sache durch> ARM selbst wieder genormt, weshalb dort 3rd-party-Lösungen preiswert> zu haben sind (aber teilweise mit Abstrichen in der Funktionalität> gegenüber den „aufgebohrten“ Debuggern der Hersteller).
Tut mir Leid, aber ich verstehe das nicht.
Beim JTAG habe ich ja eigentlich nur vier Leitungen.
TMS für den Mode Select
TCK für den Tackt
TDI für den Input
TDO für den Output
Und über diese vier Leitungen spreche ich dann mit dem Chip. Ich
verstehe desahlb nicht, was die Debugger voneinander unterscheidet. IMHO
ist das einzig-wichtige das setzen der richtigen Pegel. Alles andere ist
eine Software-Geschichte.
@Mathias Ahrens (Gast)
>> zu haben sind (aber teilweise mit Abstrichen in der Funktionalität>> gegenüber den „aufgebohrten“ Debuggern der Hersteller).>Tut mir Leid, aber ich verstehe das nicht.>Beim JTAG habe ich ja eigentlich nur vier Leitungen.>TMS für den Mode Select>TCK für den Tackt>TDI für den Input>TDO für den Output>Und über diese vier Leitungen spreche ich dann mit dem Chip.
Ja. Das ist die Hardware und unterste Logikebene. Die ist überall
gleich.
> Ich>verstehe desahlb nicht, was die Debugger voneinander unterscheidet.
Die Software, die in den höheren Ebenen sitzt. Ausserdem haben die
einzelnen JTAG-Boxen meist alle eigenständige, unterschiedliche, nicht
kompatible, nicht standardisierte Treiber. Damit ist eine universelle
Nutzung weiter verhindert.
> IMHO>ist das einzig-wichtige das setzen der richtigen Pegel. Alles andere ist>eine Software-Geschichte.
Na dann mach mal das bisschen Software ;-)
Klar, EIGENTLICH könnte das alles schon standardisiert sein, ist es aber
nicht.
Thomas Eckmann schrieb:> Der MKII kennt keinen Atmega8.
Quatsch mit Soße.
Dem Adapter ist das shitegal, welchen Controller er programmiert. Die
gesamte Parametrierung erfolgt zur Laufzeit.
Was ein ATmega8 natürlich nicht hat, ist debugWIRE (und JTAG erst
recht nicht), folglich kannst du ihn damit nur programmieren, nicht
debuggen.
Mathias Ahrens schrieb:> Alles andere ist eine Software-Geschichte.
Ja, es gab/gibt in der Tat Versuche, die durch Atmel nicht dokumentierte
Debugfunktionalität in 3rd-party-Tools nachzubauen. Opensource sind
mir dabei nur in den Kinderschuhen steckende Aktivitäten von USBprog
(bei shop.embedded-projects.net) bekannt. Inwiefern die chinesischen
Cloner des JTAGICEmkII tatsächlich eigene Firmware gezimmert haben,
oder ob es ihnen gelungen ist, Atmels Verschlüsselung ihrer Firmware
aufzubrechen, habe ich keine Ahnung.
Wenn du jetzt und heute etwas Funktionierendes haben willst und nicht
nur "aus Prinzip" an besagter Opensource-Lösung auf Basis USBprog
weiterbasteln möchtest, dann nimm einen AVR Dragon oder vielleicht
ein JTAGICE3. Oder ein JTAGICEmkII halt, aber die Dinger sind
vergleichsweise teuer.
Jörg Wunsch schrieb:> Wenn du jetzt und heute etwas Funktionierendes haben willst und nicht> nur "aus Prinzip" an besagter Opensource-Lösung auf Basis USBprog> weiterbasteln möchtest, dann nimm einen AVR Dragon oder vielleicht> ein JTAGICE3. Oder ein JTAGICEmkII halt, aber die Dinger sind> vergleichsweise teuer.
Ich möchte tatsächlich etwas funktionierendes haben. Ich habe momentan
nur ein Problem, was ich immer noch nicht verstehe.
Wenn ich jetzt ein Dragon Board oder JTAGICE3 / 2 MKII hole, dann
bekomme ich da sicherlich eine Software, mit der ich per Clicki Bunti
den AVR programmieren kann. Ebenso werde ich ja dann wohl ein
entsprechendes Interface haben, um den laufenden Code auf dem AVR zu
debuggen.
Aber wie sieht es z.B. aus, wenn ich sagen wir mal z.B. mit dem JTAG
Finder http://www.jtagfinder.com mir bei einem Gerät einen JTAG
Anschluss suche, kann ich dann mit den Tools mal auf die
undokumentierten Debug-Funktionen zugreifen?
Und dann verstehe ich leider immer noch nicht, was den (Preis-)
unterschied des Dragon Boards, des JTAGICE3 und des JTAGICE2 MKII
ausmachen.
Hi
>Was ein ATmega8 natürlich nicht hat, ist debugWIRE (und JTAG erst>recht nicht), folglich kannst du ihn damit nur programmieren, nicht>debuggen.
Nur taucht der ATMega8 auch nicht im ISP-Programmer-Dialog des AVR ICE
MKII auf. Wird allerdings auch nur Leute abschrecken, die von den AVRs
aus >10 Jahre alten Tutorials nicht loskommen.
MfG Spess
Jörg Wunsch schrieb:> Thomas Eckmann schrieb:>> Der MKII kennt keinen Atmega8.>> Quatsch mit Soße.
Daß das jetzt kommt, war klar.
> Dem Adapter ist das shitegal, welchen Controller er programmiert. Die> gesamte Parametrierung erfolgt zur Laufzeit.
Meinem ist das nicht egal.
> Was ein ATmega8 natürlich nicht hat, ist debugWIRE (und JTAG erst> recht nicht), folglich kannst du ihn damit nur programmieren, nicht> debuggen.
Na das ist ja ganz was Neues.
mfg.
Mathias Ahrens schrieb:> Wenn ich jetzt ein Dragon Board oder JTAGICE3 / 2 MKII hole, dann> bekomme ich da sicherlich eine Software, mit der ich per Clicki Bunti> den AVR programmieren kann. Ebenso werde ich ja dann wohl ein> entsprechendes Interface haben, um den laufenden Code auf dem AVR zu> debuggen.
Ja, die Software ist der Koloss, der sich da Atmel Studio nennt.
> Aber wie sieht es z.B. aus, wenn ich sagen wir mal z.B. mit dem JTAG> Finder http://www.jtagfinder.com mir bei einem Gerät einen JTAG> Anschluss suche, kann ich dann mit den Tools mal auf die> undokumentierten Debug-Funktionen zugreifen?
Das hängt von deiner Software ab. ;-)
> Und dann verstehe ich leider immer noch nicht, was den (Preis-)> unterschied des Dragon Boards, des JTAGICE3 und des JTAGICE2 MKII> ausmachen.
Das JTAGICEmkII ist der Großvater dieser Geräte. Wurde ziemlich teuer
verkauft (offiziell wohl USD 300, was sich aber mit Umsatzsteuer und
Eurolandzuschlag hierzulande in EUR 300 übersetzt hat). Da das für
den chinesischen Markt dann irgendwie doch zu teuer war, hat man den
Dragon als Abrüstvariante entwickelt. Ist im Großen und Ganzen etwas
einfacher gehalten, keine Kabel dabei, einfacher gestrickte
Schutzbeschaltungen. Dafür konnte man ihn für < USD 100 dann
anbieten (und hat nebenbei noch die HV-Programmierung aus dem STK500
mit reingestopft).
Beim JTAGICE3 hat man nun recht konsequent aber an anderen Stellen
abgespeckt. Möglich wurde das durch das völlig neu konzipierte
Atmel Studio 5 bzw. 6, bei dem man nicht mehr wie zuvor wesentliche
Teile des Debuggers in die Firmware des JTAGICE ausgelagert hat, denn
das zugrunde liegende Visual Studio besitzt bereits einen ordentlichen
Debugger. Dadurch ist das JTAGICE3 bei mit dem JTAGICEmkII
vergleichbarem Funktionsumfang beinahe so preiswert geworden wir
einstmals der Dragon. Als Folge des neuen Konzepts läuft es aber
natürlich nicht mehr zusammen mit dem alten AVR Studio 4, sondern nur
noch mit dem neuen Atmel Studio 6.
Spess53 schrieb:> Nur taucht der ATMega8 auch nicht im ISP-Programmer-Dialog des AVR ICE> MKII auf.
Kann ja sein, das heißt aber nur, dass die aktuelle Atmel-Software
dafür keine Beschreibungsdatei mitliefert. Warum auch immer.
Die kann man sich entweder selbst stricken (ist ein simples Schnipsel
XML), oder man nimmt halt was anderes, AVRDUDE zum Bleistift. Dem ist
das egal, welche XML-Dateien Atmel Studio gerade mal mitliefert,
das kennt sowohl den ATmega8 als auch ein JTAGICEmkII und kann folglich
auch beide miteinander verheiraten.
Für Thomas:
1
$ avrdude -c jtag2isp -P usb -B 5 -p atmega8 -v
2
3
avrdude: Version 6.0rc1, compiled on Jul 11 2013 at 23:35:06
4
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
5
Copyright (c) 2007-2009 Joerg Wunsch
6
7
System wide configuration file is "/usr/local/etc/avrdude.conf"
8
User configuration file is "/home/joerg/.avrduderc"
9
10
Using Port : usb
11
Using Programmer : jtag2isp
12
Setting bit clk period : 5.0
13
avrdude: usbdev_open(): Found JTAGICE mkII, serno: 00B0000011AE
Auch wenn ich hier nicht zu den Pros gehöre, aber im Simulator vom AVR
Studio kann ich das Programm auch ablaufen lassen und in gewisser Weise
auch so debuggen.
Es gibt da jede Menge Videos auf YT dazu.
Diese Videos von Atmel sind wirklich gut gemacht und man kann ne Menge
dadurch auf einfache und schnelle Weise lernen.
Das ist dann zumindest der billigste Debugger.
Ich bin ja ein Drachen Fan.
Jörg Wunsch schrieb:
> avrdude: Version 6.0rc1, compiled on Jul 11 2013 at 23:35:06
> Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/> Copyright (c) 2007-2009 Joerg Wunsch
Ok, es geht.
Aber mit sowas:
> $ avrdude -c jtag2isp -P usb -B 5 -p atmega8 -v
quäle ich mich nicht mehr ab.
Ich weiss, das ist ganz einfach. Und vi ist auch der beste Editor der
Welt. Ich hab aber keine Lust auf so ein Gefriggel.
Allerdings ist es schon merkwürdig, daß Atmel den 8er einfach
rausgeschmissen hat. In gewisser Weise natürlich konsequent, da er kein
dW hat. Aber irgendwie auch kleinkariert.
mfg.
F. Fo schrieb:> Auch wenn ich hier nicht zu den Pros gehöre, aber im Simulator vom AVR> Studio kann ich das Programm auch ablaufen lassen und in gewisser Weise> auch so debuggen.
Naja, bei realen Programmen scheitert das früher oder später, wenn
man Echtzeiteingaben aus der „richtigen Welt“ bräuchte. Kann man im
Prinzip (zumindest teilweise) mit Stimuli noch nachhelfen, aber
irgendwann stoßen auch die an ihre Grenzen.
Wirklich sinnvoll simulieren lassen sich eigentlich nur Algorithmen.
Thomas Eckmann schrieb:> Aber mit sowas:>> $ avrdude -c jtag2isp -P usb -B 5 -p atmega8 -v> quäle ich mich nicht mehr ab.
Deine Sache. Ich quäle mich nicht mit so einem Koloss wie Atmel Studio
ab, das Ding ist mir zu zäh und unflexibel. ;-)
(Das bisschen AVRDUDE-Aufruf kann man ja auch problemlos in ein
Makefile einbauen oder anderweitig in eine IDE integrieren.)
> Allerdings ist es schon merkwürdig, daß Atmel den 8er einfach> rausgeschmissen hat.
Ja, zumal sie ihn als ATmega8A noch neu aufgelegt haben. Aber du bist
$KUNDE, es wäre also an dir, dich beim Support darüber zu beklagen.
Ich benutze kein Atmel Studio, insofern habe ich keine Veranlassung,
da einen Supportcall aufzumachen.
Der AVRDUDE-Support zeigt zumindest, dass es kein grundsätzliches
technisches Problem dabei gibt.
Vor einiger Zeit hatte ich mal hier an dieser Stelle eine echte
Alternative zum Programmieren/Debuggen vom z.B. ATMega128 aufgezeigt:
Beitrag "AVR-Developmentboard & Planarspulenbaukasten"
Leider fand das nicht die erhoffte Resonanz, so dass zunächst die
weiteren Arbeiten daran unterbrochen wurden.
Es erfreut mich deshalb, da dass es offensichtlich dennoch Leute gibt,
die sich mit solchen Dingen wie JTAG (bei AVR) befassen...
Da die Dinge doch etwas komplizierter liegen, als oben ausgeführt, hatte
ich mich schon sehr eingehend damit auseinandergesetzt. Nach wie vor bin
ich der Auffassung, dass insbesondere JTAG ein willkommenes Werkzeug bei
der Programm-Entwicklung anspruchsvoller µC-Anwendungen ist.
Grüsse aus Berlin
PSblnkd
PSblnkd schrieb:> vom z.B. ATMega128
Naja, für den ATmega128 würde es ja noch ein Uralt-Clone eines
JTAGICE (mkI) tun. Allerdings ist der ATmega128 mittlerweile ein
ziemliches Urgestein, auf dem ich eher keine Neuentwicklung mehr
ansetzen würde.
Jörg Wunsch schrieb:> PSblnkd schrieb:>> vom z.B. ATMega128>> Naja, für den ATmega128 würde es ja noch ein Uralt-Clone eines> JTAGICE (mkI) tun. Allerdings ist der ATmega128 mittlerweile ein> ziemliches Urgestein, auf dem ich eher keine Neuentwicklung mehr> ansetzen würde.
Aber selbst der wurde noch von Atmel ge A delt.
mfg.
Thomas Eckmann schrieb:> Aber selbst der wurde noch von Atmel ge A delt.
Ja, aber ich würde auch keine Neuentwicklung mehr mit einem ATmega8[A]
starten …
Was sie nun als A neu aufgelegt haben und was nicht, dürfte doch in
erster Linie widerspiegeln, welche Controller nach wie vor in großen
Stückzahlen gekauft werden.
Jörg Wunsch schrieb:> Thomas Eckmann schrieb:>> Aber selbst der wurde noch von Atmel ge A delt.>> Ja, aber ich würde auch keine Neuentwicklung mehr mit einem ATmega8[A]> starten …
Natürlich nicht. Wenn mich da einer zu zwingen würde, würde ich bei
einem Atmega88 eine 8 wegkratzen oder durchstreichen.
mfg.
