Problem mit AVR DRAGON und AVRDUDE unter ECLIPSE

[Peter K. (peta)]

Hallo zusammen,

ich steige für meine AVR-Entwicklungen gerade von AtmelStudio auf 
Eclipse um. Die Installation und Konfiguration von Eclipse ist nahezu 
abgeschlossen, jedoch gestaltet sich der Zugriff auf das Target (in 
meinem Fall ein ATmega162 über AVR-Dragon JTAG und USB) 
problematisch.


SITUATION

Installiert und aktiviert ist für den USB, an dem der AVR-Dragon 
hängt, der aktuelle Treiber libusb-win32 (v1.2.6). Der Zugriff z.B. 
zum Auslesen der Statuswerte funktioniert über den DOS-Prompt wunderbar:

avrdude -pm162 -cdragon_jtag -Pusb -v

Allerdings macht Eclipse beim Zugriff auf die Hardware (für mich) 
nicht nachvollziehbare Sachen: Wenn ich in den Projekteinstellungen 
unter "AVR / Target Hardware" den Button "Load from MCU" betätige, wird 
der CPU-Typ korrekt und automatisch mit folgender Konsolen-Ausgabe 
ausgelesen:

Launching C:\PROGS\WinAVR-20100110\bin\avrdude -cdragon_jtag -Pusb -pm162
Output:

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e9404

avrdude done.  Thank you.

avrdude finished

PROBLEM

Wenn ich aber nun z.B. über "AVR / AVRDude" die Fuse-Bits auslesen 
möchte, erscheint folgende Ausgabe:

Launching C:\PROGS\WinAVR-20100110\bin\avrdude -cdragon_jtag -Pusb -pm162
Output:

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e9404

avrdude done.  Thank you.

avrdude finished


Launching C:\PROGS\WinAVR-20100110\bin\avrdude -cdragon_jtag -Pusb -pm162 "-Ulfuse:r:C:\Users\...\AppData\Local\Temp\fuse0.hex:h" "-Uhfuse:r:C:\Users\...\AppData\Local\Temp\fuse1.hex:h" "-Uefuse:r:C:\Users\...\AppData\Local\Temp\fuse2.hex:h"
Output:
avrdude: usbdev_open(): did not find any USB device "usb"
avrdude execution aborted

Es wird also zweimal auf die Schnittstelle zugegriffen und obwohl die 
Parameter passen, beim zweitenmal eine Fehlermeldung generiert. Diese 
besagt, dass das USB-Gerät (auf das einige Millisekunden vorher noch 
erfolgreich zugegriffen wurde) nun nicht mehr gefunden wird.

Hat jemand eine Idee, woran das liegen könnte und was dagegen zu tun 
wäre?

Vielen Dank.
Peter

[da1l6 (Gast)]

Der Dragon braucht eventuell eine kurze Pause zwischen den Zugriffen. 
Schmeiß den ersten (sinnlosen) mal raus.

[Peter K. (peta)]

da1l6 schrieb:
> Der Dragon braucht eventuell eine kurze Pause zwischen den Zugriffen.
> Schmeiß den ersten (sinnlosen) mal raus.

wenn ich wüsste, WIE man Eclipse beim Aufruf von avrdude dazu bringt, 
den ersten sinnlosen Teil weg zu lassen, würde ich es gern tun. Ist der 
Ort bekannt, über den man die Einstellungen entsprechend verändern kann?

Ich habe mal in den Programmer-Einstellungen einen "Delay between 
avrdude invocations" von 1000ms eingestellt (mitt 900ms ging es noch 
nicht). Nun funktioniert das Auslesen:

Launching C:\PROGS\WinAVR-20100110\bin\avrdude -cdragon_jtag -Pusb -pm16 
Output:

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e9404
avrdude: Expected signature for ATMEGA16 is 1E 94 03
         Double check chip, or use -F to override this check.

avrdude done.  Thank you.

avrdude finished

>>> avrdude invocation delay: 999 milliseconds
>>> avrdude invocation delay: finished


Launching C:\PROGS\WinAVR-20100110\bin\avrdude -cdragon_jtag -Pusb -pm162 "-Ulfuse:r:C:\Users\...\AppData\Local\Temp\fuse0.hex:h" "-Uhfuse:r:C:\Users\...\AppData\Local\Temp\fuse1.hex:h" "-Uefuse:r:C:\Users\...\AppData\Local\Temp\fuse2.hex:h" 
Output:

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e9404
avrdude: reading lfuse memory:

Reading | ################################################## | 100% 0.00s

avrdude: writing output file "C:\Users\...\AppData\Local\Temp\fuse0.hex"
avrdude: reading hfuse memory:

Reading | ################################################## | 100% 0.00s

avrdude: writing output file "C:\Users\...\AppData\Local\Temp\fuse1.hex"
avrdude: reading efuse memory:

Reading | ################################################## | 100% 0.00s

avrdude: writing output file "C:\Users\...\AppData\Local\Temp\fuse2.hex"

avrdude done.  Thank you.

avrdude finished

Allerdings ist mir diese Zeit etwas zu lang. Daher würde ich schon gern 
wissen, woran diese zeitliche Rahmenbedingung geknüpft ist und wie man 
sie für den Betrieb von avrdude auflöst.

Gruß
Peter

[Jörg W. (dl8dtl) (Moderator)]

da1l6 schrieb:
> Der Dragon braucht eventuell eine kurze Pause zwischen den Zugriffen.

Der Dragon selbst nicht, aber das Betriebssystem.  Der Dragon meldet
sich nämlich vom USB ab, wenn man ihm "Tschüss!" sagt, und danach
neu an.  Dann muss das OS ihn erst wieder in den Bus eingliedern,
erst danach kann AVRDUDE wieder mit ihm reden.

Peter K. schrieb:
> Daher würde ich schon gern
> wissen, woran diese zeitliche Rahmenbedingung geknüpft ist

Ans Betriebssystem.

[Peter K. (peta)]

Kann man das irgendwie umgehen bzw. dem Dragon per Einstellung 
mitteilen, dass er sich NICHT abmelden braucht? Oder stört diese 
Einschränkung im Betrieb ohnehin nicht, da die avrdude-Aufrufe generell 
nicht so schnell auf einander folgen brauchen? Man könnte sich ja 
vorstellen, dass dann zwischen jedem zu schreibenden Byte 1 Sekunde 
gewartet werden müsste, was so einen FLASH-Vorgang dann unerträglich in 
die Länge zöge...

[Jörg W. (dl8dtl) (Moderator)]

Peter K. schrieb:
> Kann man das irgendwie umgehen

Ja, das erste leere Kommando weglassen.

> bzw. dem Dragon per Einstellung
> mitteilen, dass er sich NICHT abmelden braucht?

Nein, die Firmware besteht letztlich darauf, dass man sich abmeldet.
Meine Vermutung, warum dies so ist: der Dragon ist vom JTAGICEmkII
abgeleitet, und jenes hatte zwei verschiedene Schnittstellen, USB
und RS-232.  Beim Anmelden über eine von beiden wird die jeweils
andere außer Betrieb genommen, beim abschließenden Abmelden wird
wahrscheinlich dann ein interner Reset ausgelöst, damit das Spiel
wieder von vorn beginnen kann.

Andere Atmel-Tools (AVRISPmkII, JTAGICE3) zeigen dieses Verhalten
nicht.

> Man könnte sich ja
> vorstellen, dass dann zwischen jedem zu schreibenden Byte 1 Sekunde
> gewartet werden müsste, was so einen FLASH-Vorgang dann unerträglich in
> die Länge zöge...

Nein, den Flash kannst du sowieso mal nur seitenweise beschreiben,
das wäre die kleinsten Einheit, die innerhalb einer Session zu
behandeln ist.  In der Praxis fackelt man aber innerhalb einer Session
so viel wie möglich ab, also den kompletten Flash, und in deinem
Falle auch gleich noch die Fuses.

[Peter K. (peta)]

Alles klar.

Vielen Dank.

Gruß
Peter