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
>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.
mach mal sudo avrdude -p m32 -c avrispmkII -P usb -B 10 -U 2.hex (drosselt die ISP Geschwindigkeit)
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.
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/
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.
1 | avrdude -p atmega16 -P usb -c avrispv2 -B 10 -U flash:w:main.hex |
2 | |
3 | avrdude: AVR device initialized and ready to accept instructions |
4 | |
5 | Reading | ################################################## | 100% 0.01s |
6 | |
7 | avrdude: Device signature = 0x1e9403 |
8 | avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed |
9 | To disable this feature, specify the -D option. |
10 | avrdude: erasing chip |
11 | avrdude: reading input file "main.hex" |
12 | avrdude: input file main.hex auto detected as Intel Hex |
13 | avrdude: writing flash (1032 bytes): |
14 | |
15 | Writing | ################################################## | 100% 1.07s |
16 | |
17 | avrdude: 1032 bytes of flash written |
18 | avrdude: verifying flash memory against main.hex: |
19 | avrdude: load data flash data from input file main.hex: |
20 | avrdude: input file main.hex auto detected as Intel Hex |
21 | avrdude: input file main.hex contains 1032 bytes |
22 | avrdude: reading on-chip flash data: |
23 | |
24 | Reading | ################################################## | 100% 0.89s |
25 | |
26 | avrdude: verifying ... |
27 | avrdude: 1032 bytes of flash verified |
28 | |
29 | avrdude: stk500v2_recv_mk2: error in USB receive |
30 | avrdude: stk500v2_cmd(): short reply, len = 0 |
31 | avrdude: safemode: Verify error - unable to read lfuse properly. Programmer may not be reliable. |
32 | avrdude: safemode: Fuses OK |
33 | |
34 | avrdude done. Thank you. |
Ausgabe 2: Hängt beim Writing, rote LED am USBprog bleibt an...
1 | avrdude -p atmega16 -P usb -c avrispv2 -B 10 -U flash:w:main.hex |
2 | |
3 | avrdude: AVR device initialized and ready to accept instructions |
4 | |
5 | Reading | ################################################## | 100% 0.00s |
6 | |
7 | avrdude: Device signature = 0x1e9403 |
8 | avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed |
9 | To disable this feature, specify the -D option. |
10 | avrdude: erasing chip |
11 | avrdude: reading input file "main.hex" |
12 | avrdude: input file main.hex auto detected as Intel Hex |
13 | avrdude: writing flash (2614 bytes): |
14 | |
15 | Writing | ################################################# | 97% 2.63savrdude: stk500v2_recv_mk2: error in USB receive |
16 | avrdude: stk500v2_recv_mk2: error in USB receive |
17 | avrdude: stk500v2_recv_mk2: error in USB receive |
18 | avrdude: stk500v2_recv_mk2: error in USB receive |
19 | avrdude: stk500v2_recv_mk2: error in USB receive |
20 | avrdude: stk500v2_recv_mk2: error in USB receive |
21 | avrdude: stk500v2_recv_mk2: error in USB receive |
22 | avrdude: stk500v2_recv_mk2: error in USB receive |
23 | avrdude: stk500v2_recv_mk2: error in USB receive |
24 | avrdude: stk500v2_recv_mk2: error in USB receive |
25 | avrdude: stk500v2_recv_mk2: error in USB receive |
26 | avrdude: stk500v2_recv_mk2: error in USB receive |
27 | avrdude: stk500v2_recv_mk2: error in USB receive |
28 | avrdude: stk500v2_recv_mk2: error in USB receive |
29 | avrdude: usbdev_send(): wrote 0 out of 1 bytes, err = No error |
30 | avrdude: stk500_send_mk2(): failed to send command to serial port |
31 | make: *** [program] Fehler 1 |
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!
>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
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
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.
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
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.
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
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/openSUSE_11.2/ 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
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...
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.
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!
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.
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?
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.
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.
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:
1 | ~> ldd /usr/bin/avrdude |
2 | linux-vdso.so.1 => (0x00007fffb4dff000) |
3 | libusb-0.1.so.4 => /usr/lib64/libusb-0.1.so.4 (0x00007f0e62576000) |
4 | libm.so.6 => /lib64/libm.so.6 (0x00007f0e62321000) |
5 | libreadline.so.6 => /lib64/libreadline.so.6 (0x00007f0e620dc000) |
6 | libc.so.6 => /lib64/libc.so.6 (0x00007f0e61d81000) |
7 | libusb-1.0.so.0 => /usr/lib64/libusb-1.0.so.0 (0x00007f0e61b73000) |
8 | libncurses.so.5 => /lib64/libncurses.so.5 (0x00007f0e6192c000) |
9 | /lib64/ld-linux-x86-64.so.2 (0x00007f0e6277b000) |
10 | librt.so.1 => /lib64/librt.so.1 (0x00007f0e61723000) |
11 | libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f0e61507000) |
12 | libdl.so.2 => /lib64/libdl.so.2 (0x00007f0e61303000) |
13 | |
14 | ~> rpm -q -a | grep libusb |
15 | libusb-1_0-devel-1.0.8-15.1.x86_64 |
16 | libusb-compat-devel-0.1.3-7.2.x86_64 |
17 | libusb-1_0-0-1.0.8-15.1.x86_64 |
18 | libusb-0_1-4-0.1.13-7.2.x86_64 |
19 | libusb-1_0-0-32bit-1.0.8-15.1.x86_64 |
20 | libusb-1_0-devel-32bit-1.0.8-15.1.x86_64 |
21 | |
22 | ~> rpm -q -a | grep avrdude |
23 | avrdude-5.10-257.5.x86_64 |
24 | |
25 | ~> find /usr/lib64/ -name "libusb*so" | xargs nm -A | grep usb_get_string |
26 | /usr/lib64/libusb-1.0.so:0000000000003cd0 T libusb_get_string_descriptor_ascii |
27 | /usr/lib64/libusb.so: U libusb_get_string_descriptor_ascii |
28 | /usr/lib64/libusb.so:0000000000001b70 T usb_get_string |
29 | /usr/lib64/libusb.so:0000000000001c70 T usb_get_string_simple |
30 | |
31 | ~> find /usr/lib/ -name "libusb*so" | xargs nm -A | grep usb_get_string |
32 | /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.
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
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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.