www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Drei Fragen zu AVR Dragon


Autor: Thomas Kusch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!

Ich moechte von meinem guten GALep3 auf einen USB-Programmer umsteigen, 
denn LPT-Schnittstellen werden rar. Dazu habe ich mir das AVRDragon 
zugelegt. Benoetigt wird er fuer Mega8 und Mega644. Nach einiger 
Bastelarbeit zwecks Erstellung der Kabel habe ich nun paar 
Probleme/Fragen:
-ISP (getestet mit Mega8). Sobald ich die Frequenz auf 250kHz oder mehr 
einstelle, wird die Uebertragung nicht mehr stabil (ID-Bytes "wackeln"). 
Woher kommt diese geringe Frequenz? Kann doch nicht sein, dass die sechs 
ca. 8cm lange Leitungen das Problem sind?
-PP/HV (getestet mit Mega8). Diesen Modus brauche ich unbedingt wegen 
Zugriff auf alle Fuses und wegen der Geschwindigkeit. Leider kriege ich 
keine Verbindung auf das Target im PP/HV-Modus (z.B. ID kann nicht 
gelesen werden). Kabel ist mittlerweile mehrfach geprueft. Gibt es etwas 
zu beachten ausser der korrekten Verkabelung??
-1Wire-Debug. Gehe ich richtig von der Annahme aus, dass ich damit auch 
auf den Mega644 debuggen kann, vorausgesetzt nur die unteren 32kB Flash 
werden verwendet?

Danke im Vorraus.
Th.Kusch

Autor: Rudolph R. (rudolph)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> zugelegt. Benoetigt wird er fuer Mega8 und Mega644. Nach einiger
> Bastelarbeit zwecks Erstellung der Kabel

Einige Bastel-Arbeit?
Was ist an einem 1:1 6poligem Flachkabel so schwierig?
Oder 10 polig für JTAG?

> -ISP (getestet mit Mega8). Sobald ich die Frequenz auf 250kHz oder mehr
> einstelle, wird die Uebertragung nicht mehr stabil (ID-Bytes "wackeln").
> Woher kommt diese geringe Frequenz? Kann doch nicht sein, dass die sechs
> ca. 8cm lange Leitungen das Problem sind?

Wie man direkt im Dialog der Einstellung der ISP-Frequenz im AVR-Studio 
lesen kann geht der ISP bis 1/4 der Target-Frquenz.
Hast Du noch die ClkDiv8 Fuse drin?

> -PP/HV (getestet mit Mega8). Diesen Modus brauche ich unbedingt wegen
> Zugriff auf alle Fuses und wegen der Geschwindigkeit.

Sorry, den verstehe ich nicht.
Für PP/HV habe ich überhaupt noch keine Verwendung gehabt.

> -1Wire-Debug. Gehe ich richtig von der Annahme aus, dass ich damit auch
> auf den Mega644 debuggen kann, vorausgesetzt nur die unteren 32kB Flash
> werden verwendet?

Erstens kann der Mega644 kein One-Wire-Debug und zweitens funktioniert 
Debuggen über den Dragon generell nicht mit Steinen die mehr als 32 KB 
FLASH haben, das hat leider nichts mit der Codegrösse zu tun.

Autor: Thomas Kusch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Rudolph:

>> zugelegt. Benoetigt wird er fuer Mega8 und Mega644. Nach einiger
>> Bastelarbeit zwecks Erstellung der Kabel
>Einige Bastel-Arbeit?
>Was ist an einem 1:1 6poligem Flachkabel so schwierig?
>Oder 10 polig für JTAG?
Da der Mega8 kein JTAG hat und das Programmieren ueber ISP fuer mich 
nicht in Frage kommt (1.dauert zu lange, 2. RESET-Leitung kann nicht als 
IO verwendet werden), muss ein HV/PP-Kabel gebaut werden. Mit 20 
Leitungen ist es schon ein gefrickel. Das war aber auch nicht der Kern 
meiner Fragen.

>> -ISP (getestet mit Mega8). Sobald ich die Frequenz auf 250kHz oder mehr
>> einstelle, wird die Uebertragung nicht mehr stabil (ID-Bytes "wackeln").
>> Woher kommt diese geringe Frequenz? Kann doch nicht sein, dass die sechs
>> ca. 8cm lange Leitungen das Problem sind?
>Wie man direkt im Dialog der Einstellung der ISP-Frequenz im AVR-Studio
>lesen kann geht der ISP bis 1/4 der Target-Frquenz.
>Hast Du noch die ClkDiv8 Fuse drin?
Der Atmel ist out-of-the-Box und hat noch nie einen Programmer gesehen.. 
Aber danke fuer den Hinweis, denn das macht Sinn. Die sind per Default 
auf 1MHz gefused.

>> -PP/HV (getestet mit Mega8). Diesen Modus brauche ich unbedingt wegen
>> Zugriff auf alle Fuses und wegen der Geschwindigkeit.
>Sorry, den verstehe ich nicht.
>Für PP/HV habe ich überhaupt noch keine Verwendung gehabt.
Dann hast du entweder noch nie groessere Anzahl auf ein mal brennen 
muessen, hast noch nie mit einem schnellen Programmen gearbeitet (GALep 
braucht mit Erase und Verify vllt. 5-6sek fuer einen Mega8) und du hast 
noch nie ein Design gehabt, bei dem der Reset-Pin als IO verwendung 
findet.
Der ISP ist fuer mich unbrauchbar.

>> -1Wire-Debug. Gehe ich richtig von der Annahme aus, dass ich damit auch
>> auf den Mega644 debuggen kann, vorausgesetzt nur die unteren 32kB Flash
>> werden verwendet?
>Erstens kann der Mega644 kein One-Wire-Debug und zweitens funktioniert
>Debuggen über den Dragon generell nicht mit Steinen die mehr als 32 KB
>FLASH haben, das hat leider nichts mit der Codegrösse zu tun.
Stimmt! Dann halt JTAG. Der zweite Teil der Aussage leuchtet mir aber 
nicht ein. Wenn ich dafuer sorge, dass keine Zugriffe auf die obere 
Haelfte des Flash erfolgen, sollte der Dragon imstande sein damit 
umzugehen. Das Problem sind doch nur die 32kB RAM auf dem Dragon. Es ist 
dann auch nichts anderes als ein Mega324.

Gruss
Th

Autor: Thomas Kusch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Aehm... nochmal ein Posting reduziert auf eine Frage: hat schon jemand 
geschafft einen Mega8 mit dem Dragon ueber HV/PP zu programmieren?
Das restliche Geplaenkel ist irrelevant. :)

Gruesse,
Th

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mit ISP schaffst Du den ATMega8 bei 1Mhz ISP-Frequenz locker in 3 
Sekunden zu programmieren. Nicht schnell genug? Wenn Du den Reset-Pin 
als I/O brauchst, solltest Du über einen Controller mit mehr Pins 
nachdenken oder Deine Hardware optimieren. Der ISP braucht auf einer 
Platine lediglich 5 kleine Pads oder Headerpins. Was, wenn Du später 
noch erweitern/updaten willst? 20 Leitungen anbenzeln?

Autor: Thomas Kusch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!

OK, Argument gegen Geschwindigkeit ist vom Tisch. Das Design steht nicht 
zur Debatte (mehrere hundert Exemplare im Umlauf, Update ueber 
Chiptausch, kein "Freischaufeln" des Reset-Pins moeglich, da es 
Aenderung der Hardware nach sich zieht.) Bevor ich mich auf so etwas 
einlasse, bleibe ich beim GALep. Alles andere waere der totale Unsinn: 
Hardwareredesign wegen Umstellung des Programmiermodus???

Meine Frage ist weiterhin offen: hat schon jemand geschafft einen Mega8 
mit dem Dragon ueber HV/PP zu programmieren?

Gruss,
Th

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nö, aber mit dem STK. Aber warum soll´s mit dem Drachen nicht gehen? Ist 
Dein USB-Port stark genug? Bricht die Power-LED in der Helligkeit ein?

Autor: Thomas K. (thkusch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Aber warum soll´s mit dem Drachen nicht gehen? Ist
Genau das frage ich mich :)

>Dein USB-Port stark genug? Bricht die Power-LED in der Helligkeit ein?
Nein. Sieht gut aus. An dem Port laeuft sonst eine 2.5" Platte 
problemlos.

Werde wohl doch mal mit dem Oszi messen muessen. :(

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wichtig: versorgst Du Deinen Target-Controller vom Dragon? Falls nicht, 
kann es arge Probleme geben! Desweiteren darf der Resetpin nicht durch 
PullUps und/oder Kondensatoren oder gar andere Scahltungen, die an 5V 
liegen, beschaltet sein. Lies Dir nochmal die HVSP_Description zum 
Dragon im AVR-Studio (mind. Ver. 4.13 SP2) durch.

Autor: Thomas K. (thkusch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!

AVRStudio ist 4.14. AVRDragon ist ueber das Studio aktualisiert worden. 
Der uC ist auf dem Prototype Area des Dragons in einem DIL-Sockel. Die 
Beschaltung ist nach dem Device Sheet fuer Mega8 aus der Dragon Doku. Es 
gibt keine externe Beschaltung des uC oder Fremdversorgung.

Gruss,
Th.

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Miß nochmal alle Spannungen am Controller und check die Verdrahtung. 
Sonst habe ich keine Idee mehr.

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zum Speicher auf dem Dragon siehe hier:
Beitrag "AVM DRAGON 32k Begrenzug aufheben"
Kurzfassung: Es sind 128KiB drauf, ein alternativer Footprint für 512 
KiB ist vorhanden, ein Austausch bringt aber nichts. Ich habe es 
ausprobiert, siehe ca. zweite Hälfte des Threads.
Die Limitierung steckt in der (verschlüsselten) Firmware.

Autor: Thomas Kusch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!

Habe in der Mittagszeit einen HV/PP-Adapter fuer den Mega644 gebaut mit 
dem gleichen Ergebnis :( Komme leider erst morgen dazu zu messen.

Gruss
Th

Autor: Fred S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Thomas,
> ...geschafft einen Mega8 mit dem Dragon ueber HV/PP zu programmieren?
> Das restliche Geplaenkel ist irrelevant. :)
mehr Geplänkel: nein, bisher nur den ATmega32 (ging ohne 
Schwierigkeiten). Welche Version des AVR-Studio nutzt Du? Es gibt einen 
Bug ("7052: Removed erroneous check on the JTAG frequency when 
programming in HV or ISP mode."), der mit dem Studio 4.14 beseitigt 
wurde. Keine Ahnung, ob dieser Bug evtl. eine erfolgreiche 
Programmierung verhindern kann.

Gruß

Fred

Autor: Thomas Kusch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Fred!

Danke :) Studio ist leider schon 4.14..

Gruss,
Th

Autor: Fred S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Thomas,
> Danke :) Studio ist leider schon 4.14..
hattest Du ja auch schon oben geschrieben - und ich hab's überlesen...

Viel Erfolg!

Fred

Autor: Thomas Kusch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So. habe nun den Support von Atmel angetriggert. ISP laeuft bei beiden 
Megas, JTAG funktioniert auch. PP/HV macht bei keinem einen Muck.

Mal schauen was kommt :)

Gruss,
Th

Autor: Mehmet Kendi (mkmk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hatte letzthin ein paar Atmega88 zerschossen, weshalb ich mir für 
den Dragon auf die Schnelle einen PP-Adapter zusammengelötet habe.
Resultat: Nachdem ich die verlöteten Kabel mehrmals kontrolliert habe, 
gab ich es auf: die Atmega88 sind billiger als mein Stundenlohn.

Autor: Fred S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

die HVPP-Dragon-Verdrahtung für den ATmega32 und den ATmega644p sind ja 
identisch. Deshalb habe ich gerade mal versucht, einen ATmega644p im 
HVPP-Modus zu programmieren. Statt 0x1E liest der Dragon immer 0xff als 
erstes "signature byte", die beiden anderen stimmen. Mit dem Mega32 gibt 
es im HVPP-Modus keine Probleme, auch nicht mit dem 644p per ISP. Wohl 
doch eher ein systematischer Fehler beim Dragon?

Viele Grüße

Fred

Autor: Fred S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

> HVPP-Modus.... Statt 0x1E liest der Dragon immer 0xff als
> erstes "signature byte", die beiden anderen stimmen. Mit dem Mega32 gibt
> es im HVPP-Modus keine Probleme, auch nicht mit dem 644p per ISP.

Habe dies gerade dem Atmel-Kundendienst mitgeteilt. Mal sehen, wie die 
das kommentieren.

Viele Grüße

Fred

Autor: Thomas O. (kosmos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ATTiny26 hatte ich mit Dragon im PP Modus auch Probleme mit dem Studio 
4.13, das ganze ist bekannt und steht auch in der Hilfe Datei so drin. 
Hatte mal absichtlich den Resetpin deaktiviert um ihn im PP Modus wieder 
zu aktivieren mit dem STK500 konnte ich ihn ersrt wieder aktivieren.

Autor: Thomas K. (thkusch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hai!

Ich kriege beim Versuch die Signature zu lesen entweder

Setting device parameters.. OK!
Entering programming mode.. OK!
Reading lockbits .. FAILED!
Leaving programming mode.. OK!

oder (selten) als Signature 0xff 0xff 0xff.

Ich hoffe mal, Atmel laesst von sich hoeren.

Weiss jemand eine bezahlbare Alternative fuer einen (funktionierenden) 
HV/PP-USB-Programmer? Einen GALep4 zulegen will ich mir nicht 
unbedingt...

Gruss,
Th.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thomas Kusch wrote:

> -1Wire-Debug. Gehe ich richtig von der Annahme aus, dass ich damit auch
> auf den Mega644 debuggen kann, vorausgesetzt nur die unteren 32kB Flash
> werden verwendet?

Der ATmega644 hat keine debugWIRE-Schnittstelle.  Du kannst ihn aber
mit dem AVR Dragon per JTAG debuggen.  Das setzt allerdings einige
Modifikationen voraus, da du dem Dragon vorgaukeln musst, dein
Controller hätte nur 32 KiB Flash-ROM.  Beim AVR Studio musst du
das ATmega644.xml editieren, beim AVaRICE die Datei src/devdescr.cc.

Die HV-Programmierung eines ATmega8 mit dem Dragon kann ich heute
abend mal zu Hause testen, allerdings habe ich kein Windows und damit
kein AVR Studio, kann's also nur mit AVRDUDE testen.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch wrote:

> Die HV-Programmierung eines ATmega8 mit dem Dragon kann ich heute
> abend mal zu Hause testen, allerdings habe ich kein Windows und damit
> kein AVR Studio, kann's also nur mit AVRDUDE testen.

Funktioniert problemlos (naja, so problemlos wie halt das Gefummel
mit den HV-Drähten da ist).

Autor: Thomas K. (thkusch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Jörg!

Welches AVRStudio? Welche HW-Version des Dragons? Welche 
Firmwareversion?

Gruss,
Th.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thomas Kusch wrote:

> Welches AVRStudio?

Gar keins, schrieb ich doch.  Läuft bei mir nicht, da ich kein Windows
habe (und keins haben will).  Getestet mit AVRDUDE.

> Welche HW-Version des Dragons?

Eine relativ alte, kann ich dir so genau nicht sagen.  Wird aber nicht
wichtig sein.

> Welche
> Firmwareversion?

Müsste die sein, die bei AVR Studio 4.13.irgendwas mit dabei war.
Bin jetzt nicht zu Hause, kann also nicht nachgucken.  Ich vermute,
4.13 build 528 war das letzte Mal, dass ich ihn an ein AVR Studio
geschleppt habe für einen Firmwareupgrade.  Ein 4.14 hat er bestimmt
noch nie gesehen.

Autor: Thomas K. (thkusch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hai!

danke! Werde avrdude mal probieren.

Gruss,
Th

Autor: Fred S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

> ... Deshalb habe ich gerade mal versucht, einen ATmega644p im
> HVPP-Modus zu programmieren. Statt 0x1E liest der Dragon immer 0xff als
> erstes "signature byte", die beiden anderen stimmen. Mit dem Mega32 gibt
> es im HVPP-Modus keine Probleme, auch nicht mit dem 644p per ISP.

Nachricht von Atmel: ich solle mal die Leitungslängen der 
HV-PP-Verdrahtung überprüfen; bei Atmel konnte der von mir beschriebene 
Fehler nicht reproduziert werden. Vielleicht liegt es ja auch am 
ATmega644p (habe momentan nur einen zum Testen, und der kam frisch aus 
der ESD-Verpackung)?

Gruß

Fred

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hab gerade keine Zeit, das Gefummel auch noch für den '644P zu basteln.

Viel wahrscheinlicher, dass dein Dragon selbst eine Macke hat.
Vielleicht ist ja die 12-V-Reset-Mimik kaputt?

Autor: Fred S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Halo Jörg,
> Viel wahrscheinlicher, dass dein Dragon selbst eine Macke hat.
> Vielleicht ist ja die 12-V-Reset-Mimik kaputt?

bin nicht sicher, wem Du hier antwortest. Falls ich gemeint bin: mit dem 
ATmega32 klappt der HV-PP-Modus ja, nur eben mit dem ATmega644p nicht; 
das schließt ein Problem mit den 12V auf der Reset-Leitung IMHO aus.

Gruß

Fred

Autor: coldtobi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ähm: Wenn Du Debug-Wire verwenden wolltest, wieso hast kannst Du dann 
den Reset-Pin nicht auch für ISP hernehmen?

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Fred S. wrote:

> Halo Jörg,

Ich bin aber gar kein Himmelskörper. ;-)

(http://de.wikipedia.org/wiki/Halo_%28Lichteffekt%29)

> bin nicht sicher, wem Du hier antwortest.

Das kommt davon, wenn man anderer Leute Threads hijackt...  Mir war
nicht mehr klar, dass es hier um zwei verschiedene Fragen ging.

> Falls ich gemeint bin: mit dem
> ATmega32 klappt der HV-PP-Modus ja, nur eben mit dem ATmega644p nicht;
> das schließt ein Problem mit den 12V auf der Reset-Leitung IMHO aus.

Ja, stimmt.

Ich habe also doch nochmal das Kabelgewusel aus der Kiste geholt.
Ergebnis: ATmega32L, ATmega324P, ATmega644 und ATmega644PV
funktionieren allesamt problemlos.

Hier noch die gewünschten statistischen Angaben (avrdude -v):
M_MCU:
  boot-loader FW version:        255
  firmware version:              1.01
  hardware version:              1
S_MCU:
  boot-loader FW version:        255
  firmware version:              1.09
  hardware version:              2

Autor: Fred S. (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hal(l)lo Jörg,

> Ich bin aber gar kein Himmelskörper. ;-)
siehe Bild.

> Das kommt davon, wenn man anderer Leute Threads hijackt...
Danke für diesen Vorwurf durch einen Moderator. Schade, dass ich hier so 
missverstanden werde. Eigentlich geht aus der Entwicklung des Threads 
hervor, dass es sich nicht um Hijacking handelt. In Zukunft werde ich es 
einfach vermeiden, Material zur Diskussion beizutragen; man lernt ja aus 
solchen Vorwürfen.

Gruß

Fred

Autor: Thomas Kusch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!

@Fred.S: nee. bloss nicht. Stoert mich nicht, dass mein Thread hijacked 
wurde. Kann jeden Hinweis gebrauchen.

@coldtobi:
>Ähm: Wenn Du Debug-Wire verwenden wolltest, wieso hast kannst Du dann
>den Reset-Pin nicht auch für ISP hernehmen?
Weil der Mega8 keins hat. Da muss ich HV/PP nehmen.

Sonst habe ich von Atmel keine Antwort erhalten. Kam leider auch noch 
nicht dazu den Dude zu probieren (Master-Studium neben Hauptberuf und 
Selbststaendigkeit ist hart :) ).

Gruss,
Thomas

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Fred S. wrote:

>> Das kommt davon, wenn man anderer Leute Threads hijackt...

> Danke für diesen Vorwurf durch einen Moderator. Schade, dass ich hier so
> missverstanden werde. Eigentlich geht aus der Entwicklung des Threads
> hervor, dass es sich nicht um Hijacking handelt.

Du hast einfach dein eigenes Problem gehabt, das nicht notwendigerweise
mit dem des OP gleich ist.  Wie du siehst, kommt man dann als Leser
des Threads nach einer Woche auch schnell durcheinander und hat gar
nicht mehr in Erinnerung, dass es sich eigentlich um zwei Probleme
gehandelt hat.  Ein separater Thread (und ggf. hier ein Posting, was
darauf hinweist, dass da ein möglicherweise ähnliches Problem
vorliegen könnte) wäre da einfach klarer.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier nochmal eine Antwort auf einen ganz alten Beitrag.  Ich hatte
vorher dort nicht weitergelesen, weil Thomas dann erstmal alles auf
die Frage reduziert hatte, ob jemand je erfolgreich einen ATmega8 mit
dem Dragon HV-programmiert hat.

Thomas Kusch wrote:

>>Erstens kann der Mega644 kein One-Wire-Debug und zweitens funktioniert
>>Debuggen über den Dragon generell nicht mit Steinen die mehr als 32 KB
>>FLASH haben, das hat leider nichts mit der Codegrösse zu tun.

> Stimmt! Dann halt JTAG. Der zweite Teil der Aussage leuchtet mir aber
> nicht ein. Wenn ich dafuer sorge, dass keine Zugriffe auf die obere
> Haelfte des Flash erfolgen, sollte der Dragon imstande sein damit
> umzugehen. Das Problem sind doch nur die 32kB RAM auf dem Dragon. Es ist
> dann auch nichts anderes als ein Mega324.

Nein.  Du verkennst das Problem.  Der RAM auf dem Dragon hat damit rein
gar nichts zu tun, der ist groß genug.  Die Begrenzung auf 32 KiB
Flash-ROM ist rein künstlich innerhalb der Firmware, damit der Dragon
keine Konkurrenz zum JTAG ICE mkII selbst ist.

Allerdings kann man das zu einem "Jein" abschwächen: der Dragon
verweigert die Debug-Arbeit nur, wenn man ihm im device descriptor eine
Flash-ROM-Größe von mehr als 32 KiB angibt.  Wenn man ihm nur 32 KiB
angibt, dann debuggt er auch einen größeren Prozessor.  Ich weiß nur
nicht, was passiert, wenn der PC dann jenseits der 32 KiB springt,
schließlich weiß die CPU ja nichts davon, dass der Debugger denkt,
sie hätte nur 32 KiB. ;-)

Die Änderung im device descriptor kann man bei AVR Studio über das
partdescription XML file machen, bei AVaRICE nimmt man sie in
src/devdescr.cc vor.

Autor: Fred S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Jörg Wunsch,

danke für die Aufklärung. Ich habe einen separaten Thread eröffnet. 
Ursprünglich dachte ich, es handele sich um das gleiche Problem.

Viele Grüße

Fred

Autor: Thomas K. (thkusch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!

@Joerg: danke fuer die Infos zu dem Debug-Limit!!

Habe hier nun den Dude 5.5... benoetige ich irgeneinen Treiber um auf 
den Dragon zuzugreifen (mit dem Studio kann ich mich doch nicht 
anfreunden.. ist mir zu viel Mausgeklicke..)? Ich kriege naemlich 
folgendes:

>avrdude -c dragon_isp -p m644 -P usb
avrdude: usbdev_open(): did not find any USB device "usb"

Gruesse,
Th.

Autor: Thomas K. (thkusch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vergisst es mit dem Treiber... habe die libusb vergessen.

Dude weigert sich jedoch wie das Studio im hv/pp-Modus zu programmieren:


C:\Downloads\avrdude>avrdude -c dragon_pp -p m644 -P usb

avrdude: AVR device initialized and ready to accept instructions

Reading |                                                    | 0% 
0.00savrdude:
stk500v2_jtagmkII_recv(): failed
Reading | ################################################## | 100% 
0.59s

avrdude: Device signature = 0xc3ffff
avrdude: Expected signature for ATMEGA644 is 1E 96 09
         Double check chip, or use -F to override this check.

avrdude done.  Thank you.


:(

Gruss,
Th

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das

stk500v2_jtagmkII_recv(): failed

stimmt bedenklich.  Das deutet auf tiefer liegende Probleme,
möglicherweise mit deinem USB selbst, hin.  Ggf. einen anderen
USB-Hub benutzen, insbesondere sollte der Hub möglichst einen
eigenen Netzteil besitzen.

Autor: Thomas Kusch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!

Das Problem ist erledigt.Ich habe das 1.8m lange USB Kabel durch ein 
30cm kurzes ersetzt. Jetzt funktioniert auch HVPP!

Gruss
Th.

Autor: Michel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,
hat jemand in Zwischenzeit mal ausprobiert ob debuggen jenseits des 32KB 
Bereichs mit dem Dragon funktioniert?

-michel

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.