Leitungslänge beim Dragon

Das ist allerdings in der Tat seltsam.  Die Leitungslängen bei meinen
Versuchen sind ähnlich wie deine, lediglich dass ich bunte Hosenträger-
leitung für das HVProg-Kabel benutzt habe (das mit der Widerstands-
farbcodierung).

Welche Firmwareversion hast du denn benutzt?

bei dem Aufbau wirst du bestimmt auch mit Kontaktprobleme zu kämpfen 
haben.

Fred S. wrote:

> danke für Deinen Kommentar. Ich programmiere mit dem AVRStudio 4.14
> unter XP SP2; der Dragon hat das neueste Update (leider sagt einem das
> AVR Studio nicht, welche Firmware Version; es führt einfach immer wieder
> ein Update durch, auch wenn schon die neueste Firmware im Dragon ist!).

In irgendeinem der kleinen Nachrichten-Fenster ganz unten oder
irgendwo da sollte das stehen.  Aber ich mag AVR Studio nicht wirklich.
Nicht nur, dass ich dafür ein Windows haben müsste, ich finde es auch
alles in allem ziemlich unübersichtlich.

Die Firmware meines Dragon dürfte leicht älter sein und irgendeiner
Version von AVR Studio 4.13 entstammen.  Allerdings mimmt AVRDUDE
nicht die XML-Dateien direkt, sondern hat die HV-Parameter daraus
irgendwann einmal übernommen.  Möglicherweise könnte das Problem also
auch durch einen geänderten HV-Parameter in der XML-Datei entstanden
sein.  Kannst du eventuell auch mal ein AVRDUDE testen?

teste mal mit einem anderem Resetpullup vielleicht ist der eine µC 
bezüglich der Standart 10 kOhm etwas grenzwertig oder der Programmer ist 
in der hinsicht etwas schwach. Oder verwendest du Werte unter 10 kOhm?

Thomas O. wrote:

> teste mal mit einem anderem Resetpullup

Thema verfehlt. :-o  Lies dir den ersten Beitrag nochmal ganz in Ruhe
durch...

Fred S. wrote:

>> Kannst du eventuell auch mal ein AVRDUDE testen?

> Werde ich mal versuchen. Mit dem Studio kenne mich gut aus, bei AVRDUDE
> habe ich allerdings die gleichen Probleme wie Du mit Windoof und dem
> Studio...

1

avrdude -p atmega644p -c dragon_pp -P usb

sollte genügen um zu sehen, ob das überhaupt funktioniert.  Allerdings
musst du die passende libusb haben.  Meiner Erinnerung nach ist die
libusb, die bei WinAVR mitkommt dafür gedacht, standalone als eigener
Treiber zu arbeiten.  Wenn du oberhalb des Jungo-Treibers arbeiten
willst, der bei AVR Studio dabei ist, dann solltest du die libusb0.dll
von WinAVR wegwerfen und die "Filter"-Version installieren:

http://sourceforge.net/projects/libusb-win32/

Ist schon seltensam...

Im avrdude.conf steht:

1

    pp_controlstack     =

2

        0x0E, 0x1E, 0x0F, 0x1F, 0x2E, 0x3E, 0x2F, 0x3F,

3

        0x4E, 0x5E, 0x4F, 0x5F, 0x6E, 0x7E, 0x6F, 0x7F,

4

        0x66, 0x76, 0x67, 0x77, 0x6A, 0x7A, 0x6B, 0x7B,

5

        0xBE, 0xFD, 0x00, 0x01, 0x00, 0x00, 0x00, 0x02;

6

    hventerstabdelay    = 100;

7

    progmodedelay       = 0;

8

    latchcycles         = 6;

9

    togglevtg           = 0;

10

    poweroffdelay       = 0;

11

    resetdelayms        = 0;

12

    resetdelayus        = 0;

13

    hvleavestabdelay    = 15;

14

    chiperasepulsewidth = 0;

15

    chiperasepolltimeout = 10;

16

    programfusepulsewidth = 0;

17

    programfusepolltimeout = 5;

18

    programlockpulsewidth = 0;

19

    programlockpolltimeout = 5;

Die Herkunft müsste ich mal im CVS nachsehen, kann sein, dass das mal
aus einer älteren XML-Datei des ATmega644P stammte, kann auch sein,
dass es durch copy&paste ohne eingehende Kontrolle aus dem Eintrag
des ATmega644 entstanden ist.

Wenn ich die Parameter aus der aktuellen XML-Datei konvertiere, ergibt
sich:

1

    pp_controlstack     =

2

        0x0E, 0x1E, 0x0F, 0x1F, 0x2E, 0x3E, 0x2F, 0x3F,

3

        0x4E, 0x5E, 0x4F, 0x5F, 0x6E, 0x7E, 0x6F, 0x7F,

4

        0x66, 0x76, 0x67, 0x77, 0x6A, 0x7A, 0x6B, 0x7B,

5

        0xBE, 0xFD, 0x00, 0x01, 0x00, 0x00, 0x00, 0x02;

6

    hventerstabdelay    = 100;

7

    progmodedelay       = 0;

8

    latchcycles         = 6;

9

    togglevtg           = 1;

10

    poweroffdelay       = 15;

11

    resetdelayms        = 1;

12

    resetdelayus        = 0;

13

    hvleavestabdelay    = 15;

14

    chiperasepulsewidth = 0;

15

    chiperasepolltimeout = 10;

16

    programfusepulsewidth = 0;

17

    programfusepolltimeout = 5;

18

    programlockpulsewidth = 0;

19

    programlockpolltimeout = 5;

Die Unterschiede sind also insbesondere togglevtg, poweroffdelay und
resetdelayms.

Du kannst ja probieren, diese Parameter manuell in deiner
ATmega644P.xml zu editieren um zu sehen, ob's dann auch mit dem AVR
Studio funktioniert.  Wirklich seltsam daran ist nur, dass AVRDUDE
mit ,,falschen'' Parametern hier besser funktioniert.

Fred S. wrote:

> Danke für den Tipp! Ich glaube, ich
> schreibe noch mal an den Atmel Support...

Gute Idee.  Du wirst ja eh' noch 'ne Ticketnummer haben.

Fred S. wrote:

> Ob das nicht auch für Beitrag "Drei Fragen zu AVR Dragon"
> relevant sein könnte??

Da sehe ich zwar auch Parameterunterschiede, aber nichts, von dem
ich erwarten würde, dass das die Relevanz wie bei dir hat.
Insbesondere ist poweroffdelay sowohl in avrdude.conf als auch in
der XML-Datei gleich 15.

Hallo, das könnte evtl. auch die Lösung beim ATTiny26 sein hier hat mein 
Dragon im HV/PP Mode auch immer eine falsche Signatur ausgelesen. 
Nachdem dann nichts mehr ging habe ich in der Hilfedatei gelesen das der 
Dragon Probleme mit dem ATTiny im HV/PP Modus hat das STK500 dagegen 
nicht. Ich könnte ihn dann vom STK500 aus wieder reanimieren. Werde mir 
mal den Wert in der XML Datei anschauen.