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? :)
>(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 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.)
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.
> 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?
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.
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:
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?
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