Hallo zusammen, diese Fehlermeldung avrdude: stk500v2_recv_mk2: error in USB receive ist wahrlich kein Einzelfall, dennoch war es mir bisher nicht möglich, einen Grund oder gar eine Lösung dafür zu finden hier. Die letzten Meldungen, die ich fand, waren zudem >4 Jahre alt. Trotzdem habe ich ihn heute immer noch. Ausgemerzt ist er also nicht. Ich nutze avrdude 6.1 auf einem Mac mit 10.10.3, also einem BSD-System. Als Programmer habe ich einen Atmel AVR ISP mkII mit der FW 1.10 am Start. Mein avrdude-Aufruf ist stets dieser: $ avrdude -P usb -c avrispmkII -p t85 .... Nach allem, was ich gelesen habe hierzu, ist mir völlig unklar, ob das Problem im USB-Stack des OS ist, ob die Firmware des ISP oder avrdude eine Macke hat. Weiß hierzu jemand mehr? Dann könnte ich gezielter suchen. Laut Atmel gäbe es wohl Firmware-Updates für den mkII, diese allerdings in deren Windows-only-Programmierstudio, oder als Standalone-Installer in einer atfw.exe oder so. Auch Windows. Eigentlich will ich auch nicht in dem Teil herumstochern, auch nicht mit Büroklammer als Jumper, wie Atmels Webseite beschreibt, denn der mkII funzte immer gut und ich sehe den eher als verläßliche Größe im Dreikampf aus eigenem Code (buggy), eigener Hardware (buggy) und dem ISP. Wer kann mich etwas erleuchten? Die Fehlermeldung an sich wäre ja zu tolerieren, nur legt der mkII immer lange Bedenkpausen hierüber ein, was die Turnaroundzeiten echt in die Länge zieht. VG, Jan.
AVRDUDE kümmert sich ja nicht selbst um die USB-Kommunikation, sondern wickelt das alles über die libusb ab. Ich habe allerdings lange kein JTAGICEmkII mehr an einem OSX ausprobiert. Kannst du mal gucken, ob du mit dtruss eine Erleuchtung bekommst, an welcher Stelle das klemmt?
Jörg Wunsch schrieb: > AVRDUDE kümmert sich ja nicht selbst um die USB-Kommunikation, > sondern wickelt das alles über die libusb ab. > > Ich habe allerdings lange kein JTAGICEmkII mehr an einem OSX > ausprobiert. > > Kannst du mal gucken, ob du mit dtruss eine Erleuchtung bekommst, an > welcher Stelle das klemmt? Hallo Jörg, besonders erleuchtet werde ich durch die SysCalls nicht; hier paste ich mal ein paar Zeilen rings um die Stelle mit der Fehlermeldung. Um hier im Forum nicht alles vollzukleistern (dtruss hustet echt eine Menge raus), habe ich den ganzen Auswurf im http://pastebin.com/7WzvRM9z abgelegt. Hier der Auszug: poll(0x7FC569730140, 0x3, 0xEA60) = 1 0 read(0x8, "@\0", 0x10) = 16 0 write(0x9, "@\0", 0x10) = 16 0 poll(0x7FC569730140, 0x3, 0xEA60) = 1 0 read(0x8, "@\0", 0x10) = 16 0 avrdude: stk500v2_recv_mk2: error in USB receive write(0x9, "@\0", 0x10) = 16 0 poll(0x7FC569730140, 0x3, 0xEA60) = 1 0 read(0x8, "@\0", 0x10) = 16 0 write_nocancel(0x2, "avrdude: stk500v2_recv_mk2: error in USB receive\n\0", 0x31) = 49 0 write(0x9, "@\0", 0x10) = 16 0 poll(0x7FC569730140, 0x3, 0xEA60) = 1 0 read(0x8, "@\0", 0x10) = 16 0 avrdude: stk500v2_recv_mk2: error in USB receive write(0x9, "\0", 0x10) = 16 0 poll(0x7FC56B0000F0, 0x3, 0xEA60) = 1 0 read(0x8, "\0", 0x10) = 16 0 write_nocancel(0x2, "avrdude: stk500v2_recv_mk2: error in USB receive\n\0", 0x31) = 49 0 write(0x9, "@\0", 0x10) = 16 0 poll(0x7FC569730140, 0x3, 0xEA60) = 1 0 read(0x8, "@\0", 0x10) = 16 0 write(0x9, "\260yPi\305\177\0", 0x10) = 16 0 poll(0x7FC569507590, 0x3, 0xEA60) = 1 0 read(0x8, "\260yPi\305\177\0", 0x10) = 16 0 VG, Jan.
Hallo,
um die lästigen und mir unerklärlichen Wartezeiten loszuwerden, nach
denen der Programmierschritt ja stets dennoch funktionierte, hatte ich
mich entschlossen, es mit einem Firmware-Update im mkII anzugehen. Dies
schien mir der überfälligste und auch der einzige gehbare Schritt zu
sein.
Da Atmel ja Windows-only ist, beschaffte ich mir übergangsweise eine VM
mit Windows. Dort mußte ich zunächst ein SP installieren, dann kam
Visual Studio Runtime irgendwas und dann war Atmel Studio befriedigt, es
ließ sich installieren. Kurz nach seinem Start vermeldete es xxx Updates
aus allen erdenklichen Sparten, auch eins für "Tools" war dabei. Das
wollte ich runterladen und wählte es aus. Das Download-Layover-Fenster
blieb aber leider leer. Der Klick zum Fensterschließen führt jedesmal
unweigerlich zum Absturz der Applikation Atmel Studio. Visual Studio
kriegt das mit und fragt mich dann keck, welchen Debugger ich denn jetzt
wohl gerne einsetzen möchte, um dem Ganzen auf den Grund zu gehen ...
Also ließ ich Downloads innerhalb von Atmel Studio sein. Immerhin hatte
die gerade heruntergeladene und installierte 6.2sp2_1563 schon ein
neueres im Bauch für den mkII, nämlich das 1.17, als meiner in seinem
Flash hat: v1.a. Was ist "a" denn für eine Zahl? Warum ändert man
unterwegs das Versionsschema?
Dieses 1.17 wollte ich dennoch in den mkII reinflashen. Zuvor überprüfte
ich die Funktion des mkII vom AStudio aus, wählte Port und Part aus und
holte mir Signatur und anderes aus meiner Schaltung mit dem tiny85. Kaum
war das Update angestoßen, war der Vorgang auch schon wieder zu Ende.
Der mkII blinkte schnell und bunt, AStudio warf einen Fehler "Verbindung
unterbrochen". Natürlich ließ ich alles unberührt, während das lief. Ich
probierte es erneut, das Resultat bleibt immer gleich.
In diesem Fall schlägt die Atmel-Webseite eine dafür vorbereitete
Handlungsliste vor (ja, die haben sie extra dafür). Es gibt noch einen
atfw.exe in einem Verzeichnis, dem ich die neurere FW und die
vollständige Seriennummer (incl. der führenden 3 Nullen!!! Obwohl diese
nicht auf dem Gehäuseetikett gedruckt sind) des mkII mitgab, den Pfad
und Namen der Datei auch, und dann ... schlug auch dieses Tool fehl,
obwohl es doch der Rettungsanker von Atmel für genau solche Fälle sein
sollte. Die Brücke von Pin1 zu 3 im mkII hatte ich gem. Doku
geschlossen.
Jetzt habe ich also einen frischen Eindruck von der SW-Quali von Atmel
bekommen (der von MS geht nicht mehr zu verschlechtern) und ich habe
einen Programmer, der außer Blinken nichts mehr macht. Er antwortet
schon noch am USB, aber programmieren tut er nicht mehr. Außerdem habe
ich keine besonders gute Laune nach den verschwendeten Stunden
Lebenszeit mit diesem Schund, denn ich kann auch nicht an meinem Projekt
weitermachen.
Ich fragte mich oft während der Klickerei-und-Warterei, wer mit solcher
Pre-Alpha-Qualität eigentlich arbeitet? Vor allem beruflich? Und die
schreiben eine sechs im Major Release ihrer SW. Unfaßbar.
Euch noch einen (viel) schöneren Tag,
Jan.
Jan R. schrieb: > Also ließ ich Downloads innerhalb von Atmel Studio sein. Immerhin hatte > die gerade heruntergeladene und installierte 6.2sp2_1563 schon ein > neueres im Bauch für den mkII, nämlich das 1.17, als meiner in seinem > Flash hat: v1.a. Was ist "a" denn für eine Zahl? Warum ändert man > unterwegs das Versionsschema? Das hat man nicht geändert. Die geben seit ewig aus mir völlig unverständlichen Gründen die Zahlen hexadezimal aus. In AVRDUDE hab' ich diesen Quatsch jedoch nicht adoptiert, sondern gebe die Versionsnummern dezimal aus. Du hattest also eine 1.10 und würdest eine 1.23 bekommen. > Kaum > war das Update angestoßen, war der Vorgang auch schon wieder zu Ende. > Der mkII blinkte schnell und bunt, AStudio warf einen Fehler "Verbindung > unterbrochen". Natürlich ließ ich alles unberührt, während das lief. Ich > probierte es erneut, das Resultat bleibt immer gleich. Was für eine VM hast du? VirtualBox? Deren USB-Implementierung ist leider nicht die beste. Das Problem bei dieser Firmwarefummelei ist, dass ja initial ein anderes USB-Gerät da ist als später, wenn der Bootloader aktiv ist, d. h. das meldet sich zwischendrin vom Bus ab und dann mit neuer PID wieder an. Das muss deine VM dann so schnallen, dass sie das auch schnell wieder durchreicht. Irgendwo bei VMware bekommst du eine kostenlose, funktional leicht eingeschränkte (bspw. keine Snapshots) Version vom VMware Player (nicht Player Pro, der kostet Geld!). Probier mal, ob du dein schon installiertes Windows dahin migrieren kannst (könnte ggf. über Export der VM aus VirtualBox gehen). Ich habe bislang unter VMware erst ein einziges USB-Gerät gehabt, welches partout nicht zum Spielen zu bekommen war(*), die Firmwarefummelei der Atmel-Teile klappt damit. Alternativ kann ich dir anbieten, dir den FW-Update zu machen, wenn du willst. (*) MSP-FET430UIF, laut Aussage von IAR (unter dem es nicht ging) liegt es am Treiber von TI, aber trotz kompletten USB-Sniffer-Traces habe ich von TI dann nie wieder etwas zurück gehört … naja, wenigstens ging das billige Launchpad, da es via HID arbeitet.
Jörg Wunsch schrieb: > Jan R. schrieb: > >> Also ließ ich Downloads innerhalb von Atmel Studio sein. Immerhin hatte >> die gerade heruntergeladene und installierte 6.2sp2_1563 schon ein >> neueres im Bauch für den mkII, nämlich das 1.17, als meiner in seinem >> Flash hat: v1.a. Was ist "a" denn für eine Zahl? Warum ändert man >> unterwegs das Versionsschema? > > Das hat man nicht geändert. Die geben seit ewig aus mir völlig > unverständlichen Gründen die Zahlen hexadezimal aus. Ach so! Na, da wäre ich vllt. mit Blick auf mehrere Nummern drauf gekommen, mit diesen zwei Stück noch nicht. > In AVRDUDE hab' ich diesen Quatsch jedoch nicht adoptiert, sondern > gebe die Versionsnummern dezimal aus. Du hattest also eine 1.10 und > würdest eine 1.23 bekommen. Verstehe. Danke für die Aufklärung und daß Du das bei avrdude dezimal gelassen hast. >> Kaum war das Update angestoßen, war der Vorgang auch schon wieder zu Ende. >> Der mkII blinkte schnell und bunt, AStudio warf einen Fehler "Verbindung >> unterbrochen". Natürlich ließ ich alles unberührt, während das lief. Ich >> probierte es erneut, das Resultat bleibt immer gleich. > > Was für eine VM hast du? VirtualBox? Deren USB-Implementierung > ist leider nicht die beste. Ja, korrekt: VirtualBox. > Das Problem bei dieser Firmwarefummelei > ist, dass ja initial ein anderes USB-Gerät da ist als später, wenn > der Bootloader aktiv ist, d. h. das meldet sich zwischendrin vom Bus > ab und dann mit neuer PID wieder an. Das muss deine VM dann so > schnallen, dass sie das auch schnell wieder durchreicht. Aha, verstehe. > Irgendwo bei VMware bekommst du eine kostenlose, funktional leicht > eingeschränkte (bspw. keine Snapshots) Version vom VMware Player > (nicht Player Pro, der kostet Geld!). Probier mal, ob du dein > schon installiertes Windows dahin migrieren kannst (könnte ggf. über > Export der VM aus VirtualBox gehen). Möglich, daß das gehen könnte. Dann hätte ich allerdings immer noch das Versagen des aktuellen Atmel Studios an der Backe, das ja beim Runterladen von neuen Tools, Parts, etc. stets abschmierte in dieser VM. Das riecht für mich schlimm, zum Weglaufen. Und nicht nach weiterem Zeitinvest. > Alternativ kann ich dir anbieten, dir den FW-Update zu machen, wenn > du willst. Wenn Du das netterweise anbietest, nehme ich das gerne an. Vielen Dank, das wäre toll! Ich habe zwar noch einen alten AVR-Doper wieder ausgegraben, den ich am WE versuchen werde an den Start zu bringen, aber der mkII soll ja trotzdem wieder laufen. Wie kann ich Dir den denn zukommen lassen? Viele Grüße, Jan.
Jan R. schrieb: > Dann hätte ich allerdings immer noch das Versagen des aktuellen Atmel > Studios an der Backe, das ja beim Runterladen von neuen Tools, Parts, > etc. stets abschmierte in dieser VM. Kannst ja einen Bugreport bei Atmel aufmachen. ;-) Derart extreme Instabilitäten habe ich darüber allerdings bisher weder selbst erlebt noch gehört. Allerdings kann ich das Teil auch nicht wirklich leiden (und bin froh, dass ich normalerweise nicht damit geplagt bin).
Kleine Entwarnung. Gestern Abend habe ich meinen Atmel-ICE mit VistaHome in einer Virtualbox, wo dann das AS6 SP2 drauf lief, gebrickt. Die Virtualbox kannte beide pid (2141/2142). Mit "atfw.exe -t atmelice -a ..\xxx\xfw.zip" gab es kurz vor Schluss den GenericError. Heute Morgen selbiges noch mal unter qemu ausprobiert. Selbes Vista, allerdings SP1 vom Atmel Studio. Und es funktionierte anstandslos; mein Atmel-ICE lebt wieder. Aufruf:
1 | qemu-system-i386 -enable-kvm -m 1G -cpu host -smp cpus=2 -vga vmware -drive file=VistaHomePremium32.img -usb -device usb-ehci,id=ehci -device usb-host,bus=ehci.0,vendorid=0x03eb,productid=0x2141 -device usb-host,bus=ehci.0,vendorid=0x03eb,productid=0x2142 |
Also ist die VirtualBox der Bösewicht in diesem undurchsichtigen Spiel. Meine udev-Regel, damit die Virtualisierung nicht als root laufen muss:
1 | #Atmel Corp. ATMEL-ICE |
2 | SUBSYSTEM=="usb", ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="2141", GROUP="users", MODE="0666"
|
3 | |
4 | #Atmel Corp. ATMEL-HIDBLDR |
5 | SUBSYSTEM=="usb", ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="2142", GROUP="users", MODE="0666"
|
Hab das selbe Problem. Gestern den avrispmk2 (Klon) bekommen. Hundert Versuche mit verschiednen avrdude-Versionen, Timings und avrdude-Parametern... Der mk2 wird im Gerätemanager erkannt und als ordnungsgemäss funktionierend dargestellt, die LED leuchtet nach einigem Blinken grün... Aber: avrdude: stk500v2_recv_mk2: error in USB receive Muss ich jetzt die ganze AVR-Studio-Suite installieren, nur um ab und zu nen kleinen Tiny10 in Assembler zu programmieren...?
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.