mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Probleme mit usbprog


Autor: Apo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin, habe die Tage angefangen mit MCs zu basteln und mir gleich ein 
usbprog geholt - klappt aber leider nicht ganz so, wie ich es will. 
Kleinere Dateien kann ich locker uebertragen:

----------
apo@eyecookie:~/atmega$ sudo avrdude -p m32 -c avrispmkII -P usb -U 
2.hex

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 
0.36s

avrdude: Device signature = 0x1e9502
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be 
performed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "2.hex"
avrdude: input file 2.hex auto detected as Intel Hex
avrdude: writing flash (30 bytes):

Writing | ################################################## | 100% 
3.67s

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

Reading | ################################################## | 100% 
3.53s

avrdude: verifying ...
avrdude: 30 bytes of flash verified

avrdude: safemode: Fuses OK

avrdude done.  Thank you.

apo@eyecookie:~/atmega$
----------

aber sobald es etwas groesser wird, laeuft nix mehr:

----------
apo@eyecookie:~/atmega$ sudo avrdude -p m32 -c avrispmkII -P usb -U 
1.hex

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 
0.36s

avrdude: Device signature = 0x1e9502
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be 
performed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "1.hex"
avrdude: input file 1.hex auto detected as Intel Hex
avrdude: writing flash (158 bytes):

Writing |                                                    | 0% 0.00s
avrdude: usbdev_send(): wrote -110 out of 64 bytes, err = No error
avrdude: stk500_send_mk2(): failed to send command to serial port
apo@eyecookie:~/atmega$
----------

Der MC ist wie man sehen kann ein atmega32... Habe es auch bereits unter 
Windows mit AVR Studio von Atmel versucht, da klappt's auch nicht.

Ach ja: Nachdem die grosse Datei nicht uebertragen werden konnte, bleibt 
die rote LED am usbprog an...

Weiss jemand, wie ich mein Problem loesen koennte? Danke.

--Apo

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Ach ja: Nachdem die grosse Datei nicht uebertragen werden konnte, bleibt
>die rote LED am usbprog an...

Das Problem kenne ich. Das SPI Modul im USBProg hatte sich
bei mir öfter aufgehängt. Kontaktiere Benedikt.

Autor: Apo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hab ich gemacht, danke.

Autor: Benedikt Sauter (Firma: embedded projects GmbH) (flopper)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
mach mal sudo avrdude -p m32 -c avrispmkII -P usb -B 10 -U 2.hex

(drosselt die ISP Geschwindigkeit)

Autor: Herrmann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo

Habe auch immer wieder Probleme beim schreiben hört er öfters bei 98% 
auf und meldet dann

Writing | #################################################avrdude: 
stk500v2_recv_mk2: error in USB receive


danach geht nix mehr nur gut das ich noch meinen STK200 und einen alten 
Notebokk habe mit lpt dann lässt sich der flasch wieder beschreiuben 
nachdem ich mit bascom den chip neu beschreibe und verifiziere.
Danach kann ich wieder mit dem USB Prog flashen aber nicht lange.Dann 
das selbe problem.Egal ob Mega8 oder Mega128.

avrdude -p atmega8 -P usb     -c avrisp2   -y -B 10 -U flash:w:main.hex


Wieso ist das so mit meinen STK200 noch nie Probleme gehabt.
Entwickle aber vorrangig an meinem neuen Rechner der hat leider kein lpt 
mehr deshalb die USB Variante von Herrn Sauter.

Autor: Toby (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jap, das -B 10 hat bei mir auch geholfen..
Und seit ich mir ne Platine gemacht hab hab ich selbst ohne die -B - 
Option keine Probleme mehr..

Wir haben so'ne Art Evu-Board für Atmega8/16/32 gemacht, und so viel 
Pins wie möglich nach Aussen geführt..Wer's haben will einfach nen 
Kommentar aufs Infolex schreiben..

http://www.infolexikon.de/blog/usbprog-atmel-evu-board/

Autor: Daniel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei mir funktioniert die Option -B 10 nicht. Auch wenn ich die Zahl 
weiter erhöhe hängt das USBprog.

Gibt es inzwischen eine nachhaltige Lösung des Problems oder war die 
Investition rausgeschmissenens Geld?

Wie die Lösung aussieht ist mir eigentlich egal. Aber ich bitte darum 
mir nicht solche "grandiosen" Sachen vorzuschlagen wie unsinnigen Code 
ins Programm einzufügen, wie es an anderer Stelle als Problemlösung 
vorgeschlagen wurde.

Da ich unter Linux arbeite bleibt mir ja nur avrdude? Oder gibt es da 
Alternativen, die ich ausprobieren könnte? uisp und ponyprog 
funktionieren ja nicht über usb oder habe ich was übersehen?


Falls das alles nichts hilft: Welche Hardwarealternativen gibt es sonst 
noch? Ob kommerziell oder Selbstbau ist mir relativ egal. Hauptsache das 
Ding funktioniert einwandfrei und läuft über USB... Und gegen günstig 
hätte ich auch nichts einzuwenden. Sprich ein USBprog was 
funktioniert...

Besten Dank.
Daniel



Als "Anhang" noch zwei avrdude Ausgaben mit Fehlern. Zwei Programme, 
zwei unterschiedliche Fehler... Die Fehler treten immer auf, ob ich -B 
komplett weglasse, -B 10 wie vorgeschlagen hinschreibe, oder -B auch 
noch weiter erhöhe...

Ausgabe1: Hängt einige Zeit nach "avrdude: 1032 bytes of flash 
verified", macht dann aber irgendwann weiter. Das Programm scheint aber 
richtig geschrieben zu sein.
avrdude -p atmega16 -P usb -c avrispv2 -B 10    -U flash:w:main.hex                                                             

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x1e9403
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.                        
avrdude: erasing chip                                                           
avrdude: reading input file "main.hex"                                          
avrdude: input file main.hex auto detected as Intel Hex                         
avrdude: writing flash (1032 bytes):                                            

Writing | ################################################## | 100% 1.07s

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

Reading | ################################################## | 100% 0.89s

avrdude: verifying ...
avrdude: 1032 bytes of flash verified

avrdude: stk500v2_recv_mk2: error in USB receive
avrdude: stk500v2_cmd(): short reply, len = 0
avrdude: safemode: Verify error - unable to read lfuse properly. Programmer may not be reliable.
avrdude: safemode: Fuses OK

avrdude done.  Thank you.



Ausgabe 2: Hängt beim Writing, rote LED am USBprog bleibt an...
avrdude -p atmega16 -P usb -c avrispv2 -B 10    -U flash:w:main.hex                                                                   

avrdude: AVR device initialized and ready to accept instructions

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

avrdude: Device signature = 0x1e9403
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.                        
avrdude: erasing chip                                                           
avrdude: reading input file "main.hex"                                          
avrdude: input file main.hex auto detected as Intel Hex                         
avrdude: writing flash (2614 bytes):                                            

Writing | #################################################  | 97% 2.63savrdude: stk500v2_recv_mk2: error in USB receive
avrdude: stk500v2_recv_mk2: error in USB receive                                                                        
avrdude: stk500v2_recv_mk2: error in USB receive                                                                        
avrdude: stk500v2_recv_mk2: error in USB receive                                                                        
avrdude: stk500v2_recv_mk2: error in USB receive                                                                        
avrdude: stk500v2_recv_mk2: error in USB receive                                                                        
avrdude: stk500v2_recv_mk2: error in USB receive                                                                        
avrdude: stk500v2_recv_mk2: error in USB receive                                                                        
avrdude: stk500v2_recv_mk2: error in USB receive
avrdude: stk500v2_recv_mk2: error in USB receive
avrdude: stk500v2_recv_mk2: error in USB receive
avrdude: stk500v2_recv_mk2: error in USB receive
avrdude: stk500v2_recv_mk2: error in USB receive
avrdude: stk500v2_recv_mk2: error in USB receive
avrdude: usbdev_send(): wrote 0 out of 1 bytes, err = No error
avrdude: stk500_send_mk2(): failed to send command to serial port
make: *** [program] Fehler 1

Autor: Karl Karl (karlkarlkarl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich glaub man kann das Problem umgehen. Ich habe festgestellt dass sich 
der usbprog anscheinend mit bestimmten Intel Hex Dateien aufhängt. ELFs 
und andere Kompilierte Programme lassen sich Problemlos rüberschieben.

Ich habe das Problem mit dem Intel Hex noch weiter einschränken können. 
Mit anderen Compiler-Optionen kann der usbprog wieder problemlos 
Programmieren. Ich verwende Eclipse 3.4 (Ganymede), und habe folgende 
Einstellungen ändern müssen:

Alles findet sich unter: "Project->Properties->c/C++ Build->Settings"; 
Reiter "Tool Settings":

Listeneintrag "Additional Tools in Toolchain":
 x Generate HEX file for Flash memory
 x Generate HEX file for EEPROM
 x Generate Estended Listing
 x Print Size
 o AVRDude

Listeneintrag "AVR Compiler->Optimization"
 o Pack structs (-fpack-stuct)
 o Short enums (-fshort-enums)

Listeneintrag "AVR Compiler->Language Standard"
 x char is unsigned (-funsigned-char)
 x bitfield are unsigned (-funsigned-bitfields)


Wobei
 x Hacken gesetzt
 o Hacken nicht gesetzt.


Ich hoffe das löst das Problem bei einigen euch da draußen. Und 
hoffentlich müsst ihr euren Code nicht revisionieren. Habs selber noch 
nicht 100%ig getestet. Viel Erfolg!

Autor: Christian U. (z0m3ie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Falls das alles nichts hilft: Welche Hardwarealternativen gibt es sonst
>noch? Ob kommerziell oder Selbstbau ist mir relativ egal. Hauptsache das
>Ding funktioniert einwandfrei und läuft über USB... Und gegen günstig
>hätte ich auch nichts einzuwenden. Sprich ein USBprog was
>funktioniert...

http://www.ullihome.de/index.php/Hauptseite#USB_AVR-Lab

Autor: Michael U. (amiga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Du glaubst nicht, wie egal einem Programmer der Inhalt der Hex-Datei zu 
sein hat.
Auch wenn ich die Goethes Faust im .doc-Format nach Intel-Hex ab Adresse 
0x00000 konvertiere und auf einen Mega128 schieben würde, hat der 
Progarmmer das kommentarlos zu erledigen.

Ich habe ein USB-AVR-Lab in meiner obligatorischen Lochrasterverdrahtung 
hier liegen, der auch etwas Würfel spielt.
Ursache sind wohl Übertragungsfehler beim USB, die der SoftUSB nicht 
nicht erkennen kann. Liegt bei mir wohl an der etwas ungünstigen 
USB-Verdrahtung und dem Betrieb mit den knapp 5V des USB.
Z-Dioden (2,7V waren gerade da und eine normale Diode in Reihe) haben es 
von "geht nur mit sehr kurzen File ziemlich oft und mit langen ganz 
selten" nach "geht mit kurzeb Files 100% und mit langen (ziemlich voller 
Mega32) zu 95%" geändert.

Wenn ich mal Lust habe, schaue ich da nochmal nach, wenn AVR-Lab gerade 
keine Lust hat, nehme ich eben den Dragon oder das STK500...

Gruß aus Berlin
Michael

Autor: Christian U. (z0m3ie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Z-Dioden in den Datenleitungen sind schon seit über 2 Jahren kein 
aktueller Stand des Labś mehr. Da sind übertragungsfehler kein 
wirkliches Wunder. Bau mal die aktuelle Version oder bestell sie für die 
15 Eur, damit geht das auch sauber.

Autor: Vali (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Für alle, die dieses Problem auch haben: Probiert mal, einen andern 
Optimierungsgrad des Compilers zu wählen. Damit hat es bei mir 
funktioniert. Keine Ahnung warum, aber das war mein ergebnis von einigen 
Stunden Forschung.

lg
Vali

Autor: Andreas Schweigstill (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael U. schrieb:
> Du glaubst nicht, wie egal einem Programmer der Inhalt der Hex-Datei zu
> sein hat.
> Auch wenn ich die Goethes Faust im .doc-Format nach Intel-Hex ab Adresse
> 0x00000 konvertiere und auf einen Mega128 schieben würde, hat der
> Progarmmer das kommentarlos zu erledigen.

In der Theorie mag das zwar korrekt sein. Fakt ist jedoch, dass es bei 
einigen AVR-Programmieradaptern REPRODUZIERBAR Fehler gibt, die offenbar 
vom Inhalt der zu programmierenden Datei abhängen. Ich habe auch solch 
einen Fall vorliegen, d.h. ein AVRISP mkII in Verbindung mit avrdude 
5.10. Schon kleinste Änderungen am generierten Code genügen, um das 
Problem wieder verschwinden zu lassen.

Besonders komisch ist dabei, dass ich hier nicht etwa Fehler des Targets 
gemeldet bekommen, sondern USB-Fehler:

avrdude: stk500v2_recv_mk2: error in USB receive

Nachtrag:
Selbst gleichzeitiges Abziehen des AVRISP vom USB und Ausschalten der 
Target-Versorgung beheben den Fehler nicht.

Autor: Michael U. (amiga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

als Ausgleich biete ich ein AVR-ASM-Projekt für einen Tiny2313 mit 
vollem Flash. 7 Bytes Rest frei geht, 6 Bytes Rest oder weniger ergibt 
Verify-Error am Anfang des Flashs. Programmer ist ein Dragon, wer da 
nicht zählen kann weiß icht nicht...

Gruß aus Berlin
Michael

Autor: Andreas Schweigstill (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!

Ich habe mittlerweile recht viel Zeit mit der Suche nach dem USB-Problem 
bei avrdude verbracht und habe endlich die Erklärung und die Lösung 
gefunden!

Verursacht werden die USB-Probleme durch eine fehlerhafte Behandlung von 
Datenpaketen auf USB-Bulk-Endpoints. Ist die Größe eines zu sendenden 
Blocks exakt ein Vielfaches der Endpoint-Puffer-Größe, muss das Ende 
durch ein sog. ZLP (zero length packet) gekennzeichnet werden. Dies wird 
bei avrdude in der Funktion usbdev_send() bewerkstelligt, siehe 
Kommentar

  /*
   * Split the frame into multiple packets.  It's important to make
   * sure we finish with a short packet, or else the device won't know
   * the frame is finished.  For example, if we need to send 64 bytes,
   * we must send a packet of length 64 followed by a packet of length
   * 0.
   */

In der o.a. Funktion werden die Pakete dann per usb_bulk_write() in der 
Bibliothek libusb verschickt. Hierbei wird das API gemäß Version 0.1 
verwendet.

Auf Linux-Systemen, die einigermaßen aktuell sind, kommt jedoch die 
libusb 1.0 zum Einsatz, wobei zusätzlich noch eine Wrapper-Bibliothek 
(libusb-compat) installiert wird, die das ausschließlich synchrone API 
der libusb 0.1 auf das völlig andere API der libusb 1.0, die auch 
asynchrone USB-Kommunikation erlaubt, abbildet. Die Implementierung muss 
jedoch mit den entsprechenden Kernel-Funktionen korrespondieren.

Hierbei gibt es jedoch ein Problem, nämlich dass die o.a. ZLP nicht 
einfach nur null Byte Länge besitzen, sondern durch die libusb als ZLP 
gekennzeichnet werden müssen. Bei Linux-Kerneln <=2.6.30 und libusb 
<=1.0.2 gibt es hier aber Probleme, die dazu führen, dass 
usb_bulk_write() hängenbleibt, und zwar unabhängig von dem beim Aufruf 
ebenfalls übergebenen Timeout-Wert.

Um das Problem zu beheben, gibt es folglich zwei Möglichkeiten:

1. Kernel-Update auf >=2.6.31 UND libusb >=1.0.3
2. Uralt-System verwenden, das noch keine libusb 1.0 anbietet

Ich habe es nicht untersucht, ob man bei einem mittelmäßig aktuellen 
Kernel die libusb 1.0 einfach komplett herunterwerfen und durch eine 
libusb 0.1 ersetzen kann. Ggf. macht dies Probleme bei einigen neueren 
Applikationen, die das neue asynchrone API benötigen.

Avrdude funktioniert bei mir nun einwandfrei auf einem System mit 
openSUSE 11.2 (Kernel 2.6.31.12-0.2-desktop), und zwar nach Hinzufügen 
des optionalen Repositories

http://download.opensuse.org/repositories/hardware...

und manueller Auswahl der alternativen libusb 1.0.6 und abhängiger 
Pakete.

Die ganze Thematik wird u.a. hier diskutiert; man beachte, dass der 
ursprünglich als Bugfix eingereichte Patch offenbar stark 
diskussionswürdig ist:

http://www.libusb.org/ticket/6

Gruß
Andreas Schweigstill

Autor: Justus Skorps (jussa)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas Schweigstill schrieb:
> Besonders komisch ist dabei, dass ich hier nicht etwa Fehler des Targets
> gemeldet bekommen, sondern USB-Fehler:
>
> avrdude: stk500v2_recv_mk2: error in USB receive

Den Fehler kenne ich auch aber afaik hängt der von der Größe des zu 
übertragenden Files ab (nach dem Forum von usbprog) und daher bringen 
geringe Code-Änderungen was. Wobei es bei aber auch mit dieser 
Fehlermeldung danach nie Probleme mit dem übertragenen Programm gab, das 
wurde trotzdem richrig in den µC geladen...

Autor: Andreas Schweigstill (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Justus Skorps schrieb:
> Den Fehler kenne ich auch aber afaik hängt der von der Größe des zu
> übertragenden Files ab (nach dem Forum von usbprog) und daher bringen
> geringe Code-Änderungen was. Wobei es bei aber auch mit dieser
> Fehlermeldung danach nie Probleme mit dem übertragenen Programm gab, das
> wurde trotzdem richrig in den µC geladen...

Exakt dieser Fall wird doch durch meine ausführliche Beschreibung der 
Fehlerursache behandelt. Ein Abbruch erfolgt genau dann, wenn der letzte 
Block ein Vielfaches von 64 Byte lang ist, d.h. bei einem Overhead von 
10 Byte für das Kommando (z.B. CMD_PROGRAM_FLASH_ISP) die Bedingung

Dateigröße = (n* 64) + 54

erfüllt ist.

Autor: bluesocks (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gibt es mittlerweile eine "wirkliche" Lösung des Problems?

Ich erfülle:
1. Kernel-Update auf >=2.6.31 UND libusb >=1.0.3
genauer: 2.6.32 und libusb in 1.0.8 und 0.1.12 parallel dazu (debian)
avrdude habe ich in Version 5.10

Und trotzdem tritt das Problem auf... mit der entwicklungs- und der 
uralten firmware des usbprog für avrisp mkII

Offtopic: Weis außerdem jemand zufällig warum man sich beim usbprog 
Forum nicht anmelden kann, und ob/wann der Fehler behoben wird, ist 
jetzt schon wochenlang so...

Freue mich sehr über eine Lösung!

Autor: Andreas Schweigstill (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
bluesocks schrieb:
> Gibt es mittlerweile eine "wirkliche" Lösung des Problems?

Das Problem lässt sich nicht durch eine Anpassung von Avrdude o.ä. 
lösen, da es bei einer fehlerhaften Kombination von Kernel/libusb 
definitiv nicht möglich ist, die ZLPs zu senden.

> Ich erfülle:
> 1. Kernel-Update auf >=2.6.31 UND libusb >=1.0.3
> genauer: 2.6.32 und libusb in 1.0.8 und 0.1.12 parallel dazu (debian)
> avrdude habe ich in Version 5.10

Kann es sein, dass avrdude statisch mit der libusb gelinkt ist? Dann 
nützt es natürlich nichts, die dynamischen Bibliothek auszutauschen. 
Neukompilieren sorgt da ggf. für Abhilfe.

Autor: bluesocks (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Leider nein, avrdude ist dynamisch gegen /lib/libusb-0.1.so.4 gelinkt, 
welches in Debian im Paket libusb-0.1-4 enthalten ist, und bei mir in 
Version 0.1.12-15 installiert ist.

Also Debian bringt wohl auch noch die alte libusb mit sich, mit der es 
funktionieren sollte.

Insofern hab ich einen Mix aus "2. Uralt-System verwenden, das noch 
keine libusb 1.0 anbietet" und einem neueren Kernel...

Gibt nur noch die Möglichkeit einen alten Kernel zu testen, bezweifle 
aber, dass das die Ursache sein soll?

Autor: Andreas Schweigstill (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wende Dich doch bitte an die Avrdude-Entwickler, um das weitere Vorgehen 
zu klären. Ich habe die o.a. Untersuchungen nur durchgeführt, um unser 
eigenes Fertigungstestsystem zum Laufen zu bekommen. Und es funktioniert 
nun, so dass ich derzeit keine weiteren Anstrengungen mehr unternehmen 
muss/werde.

Autor: Eduard Steinberg (rfk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas Schweigstill schrieb:
> Ich habe es nicht untersucht, ob man bei einem mittelmäßig aktuellen
> Kernel die libusb 1.0 einfach komplett herunterwerfen und durch eine
> libusb 0.1 ersetzen kann. Ggf. macht dies Probleme bei einigen neueren
> Applikationen, die das neue asynchrone API benötigen.

Das funktioniert (zumindest bei mir) leider nicht. Mein Gentoo läuft mit 
Kernel 2.6.31.6 (Vanilla Sources) und der Bug tritt sowohl mit 
libusb-0.1.x (getestet mit 0.1.11 und 0.1.12-r1) als auch mit 
libusb-1.0.x in Kombination mit libusb-compat-0.1.3 auf.

> Avrdude funktioniert bei mir nun einwandfrei auf einem System mit
> openSUSE 11.2 (Kernel 2.6.31.12-0.2-desktop), und zwar nach Hinzufügen
> des optionalen Repositories [...]
> und manueller Auswahl der alternativen libusb 1.0.6 und abhängiger
> Pakete.

Hierbei stellt sich mir die Frage, wie du avrdude (bei mir in Version 
5.10) mit USB-Unterstützung übersetzen kannst. Wenn ich alle alten 
libusb Versionen (inklusive des Kompatibilitätslayers libusb-compat) 
kleiner als 1.0.3 entferne, verweigert mir avrdude die 
USB-Unterstützung: bereits das configure-Script sucht nach der Funktion 
usb_get_string_simple(), welche nicht mehr vorhanden ist. Getestet mit 
allen libusb Versionen von 1.0.3 bis 1.0.8.

Könntest du vielleicht mal die Ausgabe von "ldd `which avrdude`" posten, 
um zu sehen, gegen welche libusb dein avrdude tatsächlich linkt? Danke.

Autor: Andreas Schweigstill (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Auf meinem System, bei dem mittlerweile per Online-Update die 
libusb-1.0.6 durch eine libusb-1.0.8 ersetzt wurde, sieht es wie folgt 
aus:
~> ldd /usr/bin/avrdude
        linux-vdso.so.1 =>  (0x00007fffb4dff000)
        libusb-0.1.so.4 => /usr/lib64/libusb-0.1.so.4 (0x00007f0e62576000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f0e62321000)
        libreadline.so.6 => /lib64/libreadline.so.6 (0x00007f0e620dc000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f0e61d81000)
        libusb-1.0.so.0 => /usr/lib64/libusb-1.0.so.0 (0x00007f0e61b73000)
        libncurses.so.5 => /lib64/libncurses.so.5 (0x00007f0e6192c000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f0e6277b000)
        librt.so.1 => /lib64/librt.so.1 (0x00007f0e61723000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f0e61507000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007f0e61303000)

~> rpm -q -a | grep libusb
libusb-1_0-devel-1.0.8-15.1.x86_64
libusb-compat-devel-0.1.3-7.2.x86_64
libusb-1_0-0-1.0.8-15.1.x86_64
libusb-0_1-4-0.1.13-7.2.x86_64
libusb-1_0-0-32bit-1.0.8-15.1.x86_64
libusb-1_0-devel-32bit-1.0.8-15.1.x86_64

~> rpm -q -a | grep avrdude
avrdude-5.10-257.5.x86_64

~> find /usr/lib64/ -name "libusb*so" | xargs nm -A | grep usb_get_string
/usr/lib64/libusb-1.0.so:0000000000003cd0 T libusb_get_string_descriptor_ascii
/usr/lib64/libusb.so:                 U libusb_get_string_descriptor_ascii
/usr/lib64/libusb.so:0000000000001b70 T usb_get_string
/usr/lib64/libusb.so:0000000000001c70 T usb_get_string_simple

~> find /usr/lib/ -name "libusb*so" | xargs nm -A | grep usb_get_string
/usr/lib/libusb-1.0.so:000034c0 T libusb_get_string_descriptor_ascii

Man sieht, dass usb_get_string_simple nur in der 
libusb-0.1-Kompatibilitätsbibliothek enthalten ist. Ich hatte "damals" 
bei der Fehlersuche Avrdude auch selbst kompiliert, was auch keinerlei 
Probleme bereitete.

Wollte ich auf dem betreffenden Rechner jedoch einen 32-Bit-Avrdude 
laufen lassen, müsste ich vermutlich die Kompatibilitätsbibliothek auch 
in 32 Bit installlieren.

Autor: ibuddy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

hatte am Wochenende auch Probleme mit dem Brennen mittels USBprog von 
Benedikt Sauter (übrigens schickes Teil und als Programmer 
empfehlenswert). Bei mir fings mit einem Kurzschluss der 
Versorgungsspannung des USBs an (oho, Windows reagierte nur mit einem 
Ballon-Tip, cool cool). Ich glaube aber nicht, dass das das Problem 
hervorrief.
Bin aber kurz vorher von AVR-Studio auf Eclipse umgestiegen. Das Problem 
trat beim Brennen von Eclipse mit avrdude aus auf. Habe ich die gleiche 
*.hex-Datei dann über AVR-Studio gebrannt, funktionierte es! Ich habe 
dann in Eclipse mal die Delay-Zeit auf 8us gestellt, was einer 
Übertragungsfrequenz von 125kHz entspricht (so mein Gedanke). Damit 
konnte ich dann die problematische *.hex-Datei wieder übertragen.

Vielleicht kann damit wer was anfangen!? Wie gesagt, unter Windows mit 
XP SP3.

Viele Grüße,
ibuddy

Autor: Gerhard Pauls (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Als Umgehungslösung kann man die Verifikation ausschalten mit "-V".
Damit ist der Fehler "avrdude: stk500v2_recv_mk2: error in USB receive" 
nie mehr aufgetreten.

Gerd

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.