Hallo, ich habe mir bei eBay einen USBtinyISP Programmer gekauft. Außerdem besitze ich 2 Boards mit einmal dem Atmega32 und dem Atmega644p. Ich verwende zum Programmieren des Flash das Programm AVRBurner. Wie man im Screenshot erkennen kann, bekomme ich jedoch die Fehlermeldung: initialization failed, rc=-1. Hier (http://www.ladyada.net/make/usbtinyisp/help.html) habe ich gelesen, woran dies alles liegen könnte. Das Wiring kann man hoffentlich im Foto erkennen. Ich denke nicht, dass ich dabei einen Fehler gemacht habe. (Die beiden schwarzen Kabel an der Stromversorgung des µC-Boards stehen nicht unter Strom.) Von dem Rest der Punkte, die in der Liste stehen verstehe ich nicht ganz viel, da das µC-Gebiet für mich noch Neuland ist. Ich habe es im Laufe des Tages einmal hinbekommen unter Ubuntu (Windows habe ich auch ausprobiert) den Flash des Atmega32 zu programmieren. Seitdem jedoch nicht mehr. Der Programmer sollte deswegen also wohl funktionieren. Die Boards funktionieren auch beide. Ich habe beide schonmal benutzt. Vielleicht habt ihr eine Idee? :)
Angehängte Dateien:
-
avrburner.png
14 KB -
79.jpg
140 KB
>(Die beiden schwarzen Kabel an der Stromversorgung des µC-Boards stehen >nicht unter Strom.) Ohne Spannungsversorgung kannst du den leider nicht programmieren.
holger schrieb: > Ohne Spannungsversorgung kannst du den leider nicht programmieren. Er bekommt den Strom über das USB Kabel, das mit dem Programmer verbunden ist. Ich kann das bereits programmierte Programm auch auf dem Mikrocontroller ausführen, ohne weiteren Strom dazuzugeben. Habe außerdem versucht, 5V auf die "schwarzen Kabel" zu geben. (Vorher den Jumper vom Programmer entfernt.) Das hat aber auch zu keinem Erfolg geführt. Muss ich den Jumper vielleicht drauf lassen? Ich habe Angst, dass mir nachher etwas durchbrennt.
Der Atmega32 (den ich schonmal erfolgreich programmiert habe) hat lediglich Strom über den Programmer bekommen. *
Der USBtinyISP hat einen Jumper, mit dem man einschalten kann, ob er das Target versorgt oder nicht. Das hat mich schon mal zwei LR44- Zellen gekostet, ich hatte nicht dran gedacht, dass der noch so konfiguriert war, und hatte sonst auf dem Board nur mit einem AVRISPmkII gearbeitet. Das auf dem Tisch herumfliegende Innenleben der Zellen war eine ziemliche Sauerei :-o, naja, wenigstens war es keine Lithiumzelle ... Mit diesem lapidaren Stück Screenshot kann ich nichts anfangen. Das mindeste, was man braucht, wäre die komplette AVRDUDE-Kommandozeile, die benutzt worden ist. Dafür muss man aber wohl erstmal die GUI zur Seite lassen und zu Fuß programmieren. (Allein schon die Meldung, dass die -E-Option für diesen Programmer nicht benutzbar ist, zeigt ja, dass da irgendwas im Aufruf nicht ganz kosher ist.)
Angehängte Dateien:
-
command.png
6,6 KB
Ja, ich weiß über den Jumper bescheid. ;) Habe jetzt noch mal den Befehl "avrdude -c usbtiny -p m644p -u -U flash:w:filename.hex -vvvv" ausgeführt und die Ausgabe angehangen. Ich hoffe das macht es euch etwas leichter?! :)
Die Ansage rc=-1 besagt, dass der Programmer den AVR nicht findet. Klingel mal alle Leitungen zwischen Programmer und AVR durch. Ich habe auch einen UBStiny (und bin sehr zufrieden), bei mir hilft es meist, zuerst die Verbindung Programmer-AVR zu stecken und danach erst USB-Programmer.
Hallo, ich habe zwar mit avrdude nichts am Hut, aber wieso meldet dieser bei einem USB-Programmer Using Port : lpt1 ?? Gruß aus Berlin Michael
> aber wieso meldet dieser bei einem USB-Programmer Using Port : lpt1
Das macht er bei mir auch wenn man die Portangabe weglässt, ist aber nur
ein Schönheitsfehler und hat keine Auswirkung. Mit expliziter Angabe des
Ports "-P usb" kann man das schöner machen.
Michael U. schrieb: > ich habe zwar mit avrdude nichts am Hut, aber wieso meldet dieser bei > einem USB-Programmer Using Port : lpt1 ?? Weil keine -P-Option angegeben ist und der Default lpt1 ist. Sollte beim USBtinyISP aber nicht interessieren, denn dessen Implementierung kümmert sich gar nicht um die -P-Option, sondern sie grast den USB durch, bis sie auf den ersten USBtinyISP gestoßen ist, der am Bus zu finden war. Das CMD: [ac 53 00 00] ist das ISP-Initialisierungskommando. Das liest nur Nullen zurück, d. h. MISO ist die ganze Zeit auf low. Irgendwas stimmt da mit der Hardware nicht. Hast du es möglicherweise beim ersten Programmierversuch geschafft, die Fuses zu verbiegen, sodass der Controller jetzt keinen Takt mehr hat?
Das weiß ich leider nicht. Wie hätte ich das denn hinkriegen müssen? Wie kann ich das Problem mit den Fuses denn beheben?
> Wie kann ich das Problem mit den Fuses denn beheben? http://www.mikrocontroller.net/articles/AVR_Fuses
Ok, habe den Artikel jetzt gelesen und befürchte, dass ich RSTDISBL programmiert habe. Beim Atmega32 habe ich einen Bootloader drauf, auf dem Atmega644p jedoch nicht. Heißt das, dass ich den Atmega32 noch retten kann und der Atmega644p nur noch für die Mülltonne zu gebrauchen ist? Ich habe den Artikelteil "Reaktivieren bei fehlerhaften Taktquellen-Fuse-Einstellungen" nicht ganz verstanden. (Für mich zu hoch) Was ist der XTAL1? Ist das ein Pin des µCs?
Peter Physatty schrieb: > Ok, habe den Artikel jetzt gelesen und befürchte, dass ich RSTDISBL > programmiert habe. Beim Atmega32 habe ich einen Bootloader drauf, auf > dem Atmega644p jedoch nicht. Heißt das, dass ich den Atmega32 noch > retten kann und der Atmega644p nur noch für die Mülltonne zu gebrauchen > ist? Du kannst ihn mit einem "parallel programmer" retten. > Was ist der XTAL1? Ist das ein Pin des µCs? Das ist im Datenblatt ausführlich erklärt.
Also muss ich mir auch noch nen Parallel Programmer kaufen? (Oh man, ich hab schon 60 Euro für alles ausgegeben und bisher tut nichts. :( ) Danke, das mit dem XTAL1 hat sich damit geklärt. Also wie muss ich denn genau vorgehen? Ich schließe einen Pin eines anderen µC an XTAL1 an, welcher immer zwischen high und low wechselt. Ist das alles, was ich an den µC anschließen muss? Oder muss ich GND noch irgendwomit verbinden? Tut mir echt leid, dass ich so wenig Ahnung habe. :(
Tschuldigung, dass mir das erst jetzt auffällt, aber der Atmega644p kann außerdem sein bisher programmiertes Programm durchlaufen lassen. Das muss ja heißen, dass er den Takt noch über den Quarz bekommt. Der Atmega32 macht bisher gar nichts.
Peter Physatty schrieb: > Also muss ich mir auch noch nen Parallel Programmer kaufen? Oder jemanden finden, der einen besitzt. Wenn das DIL-Gehäuse sind, könnte ich dir anbieten, dass du mir die Teile in einem frankierten Rückumschlag zusendest, und ich lösche sie dir einschließlich der Fuses. Jedoch: eine RSTDSBL-Fuse gibt es weder beim ATmega644P noch beim ATmega32. Bist du dir in deiner Einschätzung sicher?
Danke für den Tipp. Habs gerade versucht geht aber leider trotzdem nicht
:(
Hier mal mein ganzer Log:
:\Program Files\WinAVR\bin\avrdude.exe -C C:\Program
Files\WinAVR\bin\avrdude.conf -p m8 -P usb -c usbasp -U
hfuse:r:C:\Users\CD\AppData\Local\Temp\hfuse3929158235426714167.hex:r -U
lfuse:r:C:\Users\CD\AppData\Local\Temp\lfuse619866261166831823.hex:r
avrdude.exe: warning: cannot set sck period. please check for usbasp
firmware update.
avrdude.exe: error: programm enable: target doesn't answer. 1
avrdude.exe: initialization failed, rc=-1
Double check connections and try again, or use -F to
override
this check.
avrdude.exe done. Thank you.
An der Firmware liegt es aber sicher nicht. Andere Boards die mit 5V
laufen kann ich damit Problemlos brennen.
Warum hier die Fusebits aus Dateien geholt werden, ist mir irgendwie schleierhaft. mfg mf PS: Du bist garnicht der TO... Bemüh mal die Forensuche. Zum USBasp sollte sich einiges finden lassen.
Jack P. schrieb: > avrdude.exe: warning: cannot set sck period. please check for usbasp > firmware update. Diesen Ratschlag solltest du wohl mal befolgen.
Hallo, probiere gerade mit einem USBtiny eine Platine zu flashen aber leider kommt immer raus:
1 | avrdude: initialization failed, rc=-1 |
2 | Double check connections and try again, or use -F to override |
3 | this check. |
und komme leider nicht weiter. Folgende Situation ist seltsam: - Wenn ich auf der Platine die Taster "reset" gedrückt halte dann lässt sich programmieren. - Die Platine lässt sich mit einem AVRISPmkII problemlos flashen AVRDUDE mit dem Option -VVVV gibt foldes aus:
1 | avrdude: Version 6.0rc1, compiled on May 16 2013 at 10:35:47 |
2 | Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/ |
3 | Copyright (c) 2007-2009 Joerg Wunsch |
4 | |
5 | System wide configuration file is "C:\WinAVR-20100110\bin\avrdude.conf" |
6 | |
7 | Using Port : usb |
8 | Using Programmer : usbtiny |
9 | avrdude: usbdev_open(): Found USBtinyISP, bus:device: bus-0:\\.\libusb0-0001--0x1781-0x0c9f |
10 | AVR Part : ATmega328P |
11 | Chip Erase delay : 9000 us |
12 | PAGEL : PD7 |
13 | BS2 : PC2 |
14 | RESET disposition : dedicated |
15 | RETRY pulse : SCK |
16 | serial program mode : yes |
17 | parallel program mode : yes |
18 | Timeout : 200 |
19 | StabDelay : 100 |
20 | CmdexeDelay : 25 |
21 | SyncLoops : 32 |
22 | ByteDelay : 0 |
23 | PollIndex : 3 |
24 | PollValue : 0x53 |
25 | Memory Detail : |
26 | |
27 | Block Poll Page Polled |
28 | Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack |
29 | ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- --------- |
30 | eeprom 65 20 4 0 no 1024 4 0 3600 3600 0xff 0xff |
31 | Block Poll Page Polled |
32 | Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack |
33 | ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- --------- |
34 | flash 65 6 128 0 yes 32768 128 256 4500 4500 0xff 0xff |
35 | Block Poll Page Polled |
36 | Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack |
37 | ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- --------- |
38 | lfuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00 |
39 | Block Poll Page Polled |
40 | Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack |
41 | ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- --------- |
42 | hfuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00 |
43 | Block Poll Page Polled |
44 | Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack |
45 | ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- --------- |
46 | efuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00 |
47 | Block Poll Page Polled |
48 | Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack |
49 | ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- --------- |
50 | lock 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00 |
51 | Block Poll Page Polled |
52 | Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack |
53 | ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- --------- |
54 | calibration 0 0 0 0 no 1 0 0 0 0 0x00 0x00 |
55 | Block Poll Page Polled |
56 | Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack |
57 | ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- --------- |
58 | signature 0 0 0 0 no 3 0 0 0 0 0x00 0x00 |
59 | |
60 | Programmer Type : USBtiny |
61 | Description : USBtiny simple USB programmer, http://www.ladyada.net/make/usbtinyisp/ |
62 | avrdude: programmer operation not supported |
63 | |
64 | avrdude: Using SCK period of 10 usec |
65 | CMD: [ac 53 00 00] [ac 52 00 00] |
66 | CMD: [ac 53 00 00] [00 00 00 00] |
67 | avrdude: initialization failed, rc=-1 |
68 | Double check connections and try again, or use -F to override |
69 | this check. |
70 | |
71 | |
72 | avrdude done. Thank you. |
73 | |
74 | make.exe: *** [program] Error 1 |
Wo kann ich noch suchen??
Martin schrieb: > Folgende Situation ist seltsam: > > - Wenn ich auf der Platine die Taster "reset" gedrückt halte dann lässt > sich programmieren. Gut. Wie sieht die Beschaltung des Reset-Pins auf der Platine aus?
Angehängte Dateien:
-
Resetleitung.png
11 KB
Karl Heinz Buchegger schrieb:
> Wie sieht die Beschaltung des Reset-Pins auf der Platine aus?
Siehe Bild.
Das komische daran ist dass ich die Platine mit eien AVRISPmkII
problemlos flashen kann bzw. der USBtiny verhält sich bei alle Platine
genau gleich (habe paar Andere Platine die mit dem AVRISPmkII
eindwanfrei gehen).
100n sind an dieser Stelle ein wenig groß. Verkleinere den mal oder leb damit, dass du den Taster drücken musst. Hintergrund: Der Programmer muss als erstes die Reset-Leitung nach Masse ziehenh. Daraufhin meldet sich der im µC eingebaute ISP Teil. Nur: Der Programmer gibt dem µC nicht ewig Zeit dazu. Er erwartet, dass nachdem er Reset nach Masse gezogen hat, sich der ISP Teil nach einer bestimmten maximalen Zeit meldet. Hast du da aber ein zu großes RC-Glied, dann dauert es seine Zeit vom ziehen der Resetleitung, bis dann auch tatsächlich die Spannung weit genug gesunken ist, dass der µC in den ISP Modus geht. Dauer das zu lange, dann meldet deine Progrmmiersoftware folgerichtig 'konnte den µC nicht ansprechen'.
Karl Heinz Buchegger schrieb: > 100n sind an dieser Stelle ein wenig groß. Verkleinere den mal > oder leb > damit, dass du den Taster drücken musst. Ok aber warum geht mit dem AVRISPmkII eindwandfrei?
Martin schrieb: >> 100n sind an dieser Stelle ein wenig groß. Verkleinere den mal >> oder leb >> damit, dass du den Taster drücken musst. > > Ok aber warum geht mit dem AVRISPmkII eindwandfrei? Der wartet länger oder hat einen stärkeren Treiber auf der Reset Leitung.
Hi
>Ok aber warum geht mit dem AVRISPmkII eindwandfrei?
Weil der 10µF am Reset-Pin verträgt. Dein Programmer ist halt in der
Beziehung etwas schach auf der Brust.
MfG Spess
Karl Heinz Buchegger schrieb: > 100n sind an dieser Stelle ein wenig groß. Verkleinere den mal oder leb > damit, dass du den Taster drücken musst. spess53 schrieb: > Mach mal den 100nF Kondensator weg. Gesagt, getan aber funktioniert auch nicht hmmm...
Martin schrieb: > Karl Heinz Buchegger schrieb: >> 100n sind an dieser Stelle ein wenig groß. Verkleinere den mal oder leb >> damit, dass du den Taster drücken musst. > > spess53 schrieb: >> Mach mal den 100nF Kondensator weg. > > Gesagt, getan aber funktioniert auch nicht hmmm... Dann sind noch irgendwo Kapazitäten im Spiel. Denn dein Programmer macht auch nichts anderes, als das er 'den Reset Taster drückt'. Nur macht er es elektrisch und nicht mechanisch. Hast du denn schon mal kontrolliert, ob die Reset-Leitung überhaupt nach Masse geht? Vielleicht ist ja auch dein Kabel defekt oder sonst irgendwas verhindert, dass dieser Programmer die Reset-Leitung ziehen kann?
Karl Heinz Buchegger schrieb: > Hast du denn schon mal kontrolliert, ob die Reset-Leitung überhaupt nach > Masse geht? Vielleicht ist ja auch dein Kabel defekt oder sonst > irgendwas verhindert, dass dieser Programmer die Reset-Leitung ziehen > kann? Ich habe auch an das Kabel gedacht, mache morgen ein neues und melde mich noch mal. Gruß Martin
So, neue Erkenntnisse: Kabel neu gemacht und alles läuft bestens Vilen Dank für eure Hilfe.
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.