avrdude <-> uisp

[Max M. (gbl1)]

Hallo,

Ich verwende als Programmer von Embedded Projects den AVRMK2 - USB 
Programmer und als OS Ubuntu 11. Soweit so gut.

Leider scheint AVRDUDE ein Problem mit manchen HEX Files zu haben, sodaß 
der Write oder auch der Verify Vorgang fehlschlägt.

Ich möchte eine andere Programmier-Software verwenden. Ich habe jedoch 
nur UISP gefunden.

Ist UISP in meinem Anwendungsfall brauchbar? Ich habe zumindest keine 
Möglichkeit entdeckt meinen USB Programmer ansprechen zu können.

Oder gibt es eine Alternative die auch immer funktioniert?



LG
Günter

[Bernhard M. (boregard)]

Günter W. schrieb:
> Leider scheint AVRDUDE ein Problem mit manchen HEX Files zu haben, sodaß
> der Write oder auch der Verify Vorgang fehlschlägt.

Das halte ich für ein Gerücht...
Bei mir passiert das immer nur, wenn die Programmiergeschwindigkeit zu 
hoch ist. So ist der default zu hoch für Controller die mit internen 
1MHz Takt laufen. Damuß man dann bei avrdude '-B 10' setzen...

[Max M. (gbl1)]

Bernhard M. schrieb:
> Das halte ich für ein Gerücht...

Das dumme an Gerüchten ist, die sind meistens wahr. Siehe: 
http://forum.embedded-projects.net/viewtopic.php?id=204

> Bei mir passiert das immer nur, wenn die Programmiergeschwindigkeit zu
> hoch ist. So ist der default zu hoch für Controller die mit internen
> 1MHz Takt laufen. Damuß man dann bei avrdude '-B 10' setzen...

-B 10 habe ich probiert. Mit -B 30 erhalte ich:

avrdude -p atmega32 -P usb -c avrisp2 -B 30    -U flash:w:vfomain.hex -U lfuse:w:0xe4:m -U hfuse:w:0xd9:m


:
avrdude: 8246 bytes of flash written
avrdude: verifying flash memory against vfomain.hex:
avrdude: load data flash data from input file vfomain.hex:
avrdude: input file vfomain.hex auto detected as Intel Hex
avrdude: input file vfomain.hex contains 8246 bytes
avrdude: reading on-chip flash data:

Reading |                                                    | 0% 0.00s*** stack smashing detected ***: avrdude terminated
======= Backtrace: =========
/lib/i386-linux-gnu/libc.so.6(__fortify_fail+0x50)[0x401b9df0]
/lib/i386-linux-gnu/libc.so.6(+0xe5d9a)[0x401b9d9a]
avrdude[0x806efbb]
[0x0]
======= Memory map: ========
08048000-08089000 r-xp 00000000 08:11 11810542   /usr/bin/avrdude
08089000-0808a000 r--p 00040000 08:11 11810542   /usr/bin/avrdude
0808a000-0808b000 rw-p 00041000 08:11 11810542   /usr/bin/avrdude
0808b000-0808f000 rw-p 00000000 00:00 0 
096c9000-098ba000 rw-p 00000000 00:00 0          [heap]
40000000-4001c000 r-xp 00000000 08:11 6029648    /lib/i386-linux-gnu/ld-2.13.so
4001c000-4001d000 r--p 0001b000 08:11 6029648    /lib/i386-linux-gnu/ld-2.13.so
4001d000-4001e000 rw-p 0001c000 08:11 6029648    /lib/i386-linux-gnu/ld-2.13.so
4001e000-4001f000 r-xp 00000000 00:00 0          [vdso]
4001f000-40021000 rw-p 00000000 00:00 0 
40039000-4003f000 r-xp 00000000 08:11 6029460    /lib/libusb-0.1.so.4.4.4
4003f000-40040000 r--p 00005000 08:11 6029460    /lib/libusb-0.1.so.4.4.4
40040000-40041000 rw-p 00006000 08:11 6029460    /lib/libusb-0.1.so.4.4.4
40041000-40042000 rw-p 00000000 00:00 0 
40042000-40066000 r-xp 00000000 08:11 6029647    /lib/i386-linux-gnu/libm-2.13.so
40066000-40067000 r--p 00023000 08:11 6029647    /lib/i386-linux-gnu/libm-2.13.so
40067000-40068000 rw-p 00024000 08:11 6029647    /lib/i386-linux-gnu/libm-2.13.so
40068000-40069000 rw-p 00000000 00:00 0 
40069000-40097000 r-xp 00000000 08:11 6029409    /lib/libreadline.so.6.2
40097000-40098000 r--p 0002e000 08:11 6029409    /lib/libreadline.so.6.2
40098000-4009b000 rw-p 0002f000 08:11 6029409    /lib/libreadline.so.6.2
4009b000-4009c000 rw-p 00000000 00:00 0 
4009c000-400d0000 r-xp 00000000 08:11 6029922    /lib/libncurses.so.5.7
400d0000-400d1000 ---p 00034000 08:11 6029922    /lib/libncurses.so.5.7
400d1000-400d3000 r--p 00034000 08:11 6029922    /lib/libncurses.so.5.7
400d3000-400d4000 rw-p 00036000 08:11 6029922    /lib/libncurses.so.5.7
400d4000-4022e000 r-xp 00000000 08:11 6029440    /lib/i386-linux-gnu/libc-2.13.so
4022e000-4022f000 ---p 0015a000 08:11 6029440    /lib/i386-linux-gnu/libc-2.13.so
4022f000-40231000 r--p 0015a000 08:11 6029440    /lib/i386-linux-gnu/libc-2.13.so
40231000-40232000 rw-p 0015c000 08:11 6029440    /lib/i386-linux-gnu/libc-2.13.so
40232000-40235000 rw-p 00000000 00:00 0 
40235000-40237000 r-xp 00000000 08:11 6029645    /lib/i386-linux-gnu/libdl-2.13.so
40237000-40238000 r--p 00001000 08:11 6029645    /lib/i386-linux-gnu/libdl-2.13.so
40238000-40239000 rw-p 00002000 08:11 6029645    /lib/i386-linux-gnu/libdl-2.13.so
40239000-4023b000 rw-p 00000000 00:00 0 
4023b000-40255000 r-xp 00000000 08:11 6029380    /lib/i386-linux-gnu/libgcc_s.so.1
40255000-40256000 r--p 00019000 08:11 6029380    /lib/i386-linux-gnu/libgcc_s.so.1
40256000-40257000 rw-p 0001a000 08:11 6029380    /lib/i386-linux-gnu/libgcc_s.so.1
bfe59000-bfe7a000 rw-p 00000000 00:00 0          [stack]
make: *** [program] Abgebrochen

LG
Günter

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

Günter W. schrieb:

> Das dumme an Gerüchten ist, die sind meistens wahr. Siehe:
> http://forum.embedded-projects.net/viewtopic.php?id=204

Ja, leider hat AVRDUDE noch keine Logik, um kaputte Programmer, die
am USB offenbar nicht mehr reagieren, zu reparieren. :-/

Ein originales AVRISPmkII benutze ich schon hin und wieder, sodass
dieses zu den noch vergleichsweise gut getesteten Programmern
gehört (zusammen mit dem JTAGICEmkII, das ich am häufigsten nehme).

> Reading |                                                    | 0%
> 0.00s*** stack smashing detected ***: avrdude terminated
> ======= Backtrace: =========
> /lib/i386-linux-gnu/libc.so.6(__fortify_fail+0x50)[0x401b9df0]
> /lib/i386-linux-gnu/libc.so.6(+0xe5d9a)[0x401b9d9a]
> avrdude[0x806efbb]
> [0x0]
> ======= Memory map: ========
> 08048000-08089000 r-xp 00000000 08:11 11810542   /usr/bin/avrdude
> 08089000-0808a000 r--p 00040000 08:11 11810542   /usr/bin/avrdude
> 0808a000-0808b000 rw-p 00041000 08:11 11810542   /usr/bin/avrdude

Was auch immer mir dieser Trace sagen will - tut mir leid, ich kann
mit den Zahlen da nichts anfangen.  Wenn es sich um einen AVRDUDE-Bug
handelt, dann hätte ich dafür gern einen Bugreport auf savannah,
wobei die Daten irgendwie so aufbereitet sein sollten, dass ich sie
auch verstehen kann (und das bitte, ohne dass ich das entsprechende
Betriebssystem auch selbst besitzen muss).

Dann kann ich das auch versuchen zu bearbeiten.  (Es gibt ein oder
zwei Bugs in dieser Richtung, die mir bekannt sind, aber die können
eigentlich prinzipbedingt nur zuschlagen, wenn man mit -c jtag2isp
oder -c dragon_isp arbeitet.)

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

Günter W. schrieb:
> Ist UISP in meinem Anwendungsfall brauchbar?

Nein, überhaupt nicht.  Es ist

1.) seit vielen Jahren völlig ungepflegt und
2.) hat von den originalen Atmel-Tools auch in seinen besten Zeiten
    nur den STK500 (und den auch nur in der Protokollversion 1)
    unterstützt