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.
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.
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.
/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
