Hi,
vor einiger Zeit bereits habe ich mir das USB AVR Lab zugelegt
(http://wiki.ullihome.de/index.php/USBAVR-ISP/de) und versuche nun,
damit einen ATMEGA 8 zu programmieren.
Leider klappt das überhaupt nicht.
Wenn ich das USB AVR Lab als Entwicklungsplattform benutze (also eine
hex-Datei mit dem beiliegenden Tool aufspiele), klappt das wunderbar.
Wenn ich aber die AVRISPmkII Firmware aufspiele (im Gerätemanager wird
es richtig erkannt und kein Fehler angezeigt), bekomme ich es nicht hin,
einen anderen ATMEGA 8 zu programmieren.
Immer wenn ich im AVR Studio auf "Connect" klicke (mit AVRISPmkII und
USB ausgewählt), passiert einige Zeit lang gar nichts, bis schließlich
der Connect-Dialog wieder erscheint mit der Meldung "connection failed"
im Titel.
Ich habe folgende Schaltung nachgebaut:
http://code.rancidbacon.com/images/avrm8ledtest-0.5-circuit.gif
(Die LED an Pin 28 habe ich weggelassen), und die ganze Schaltung mit
einer externen Spannung von etwas mehr als 5 V versorgt.
Am USB AVR Lab leuchtet nur die blaue LED, die andere ist einfach aus
(als hätte ich kein Target angeschlossen).
Woran könnte das liegen? Was mache ich falsch? Für Hinweise, die mir
helfen, eventuelle Fehlerquellen zu eliminieren, wäre ich wirklich
dankbar!
Vielen Dank und herzliche Grüße,
Donner
Du hast höchstwarscheinlich die Treiber des AVRISPmkII nicht
mitinstalliert. Die musst du bei der Installation des AVR Studios mit
anhaken. Siehe Hilfe Seite zur Lab AVRISPmkII Firmware.
lg
Christian
Hi,
also vielen Dank zunächst mal. Nun leuchtet das grüne Lämpchen und wenn
man im AVR Studio auf Connect klickt kommt nun auch der Dialog, mit dem
ich den Prozessor flashen kann. Die Spannung liegt auch konstant bei 5V
(wenn ich sie in dem Dialog auslese).
Wenn ich nun aber verusche, eine .hex-Datei in den in den Flash-Speicher
zu programmieren, kommt immer:
Entering programming mode... OK
Erasing device... OK
Programming FLASH... FAILED
und eine Fehlermeldung "ISP Mode Error", die mich darauf hinweist, die
ISP Frequenz auf höchstens 1/4 der internen Frequenz zu setzen. Laut den
unter Fuses ausgelesenen Werten liegt die Taktfrequenz aber bei 1MHz,
die ISP Frequenz habe ich auf 125 kHz eingestellt.
Was mache ich jetzt noch falsch?
Übrigens leuchtet die LED am USB AVR Lab grün, aber während des
Flash-Versuchs erlischt sie und die rote LED leuchtet auch nicht. Wenn
dann die Fehlermeldung kommt, leuchtet sie wieder grün...
Vielen Dank nochmal...
Gruß,
Donner
Versuche erst einmal die Signatur des Kontrollers zu lesen, das ist eine
der einfachsten ISP-Aktionen und wenn das klappt (oder nicht), kann man
weiterraten.
>und eine Fehlermeldung "ISP Mode Error", die mich darauf hinweist, die>ISP Frequenz auf höchstens 1/4 der internen Frequenz zu setzen.
Falsch
Dort steht < 1/4
Warum wird das immer verkehrt gelesen?
Hm also Signatur auslesen klappt.
Sorry, ja, es müsste < 1/4 heißen. Ich hab die Frequenz übrigens auf 125
KHz, das sollte doch klein genug sein, oder?
Gruß,
Donner
Donner schrieb:> Ich hab die Frequenz übrigens auf 125> KHz, das sollte doch klein genug sein, oder?
Nö, gehe mal Stufenweise höher.
Immer mit Signatur Lesen kontrollieren.
125 kHz ISP bei 1MHz Kontrollertakt ist doch ganz in Ordnung?
höhere ISP Frequenz ist im Moment uninteressant.
Wenn das Signatur-lesen klappt, ist ISP in Ordnung.
Da liegt die Gefahrenquelle in der Richtung des .hex-files.
Eventuell lehnt die Progger-software das file ab, weil es einen Fehler
im file erkennt.
Ist dem Progger auch das richtige .hex-file mitgeteilt?
Das Fenster für die .hex-file-Anzeige ist so klein, dass man den genauen
Namen garnicht erkennt.
Siehe auch den thread von gestern: atmega 16-16 macht nichts
Wenn z-B. beim Assemblieren ein fehler gemeldet worden ist, verweigert
die Progger-Software das Programmieren dieses file.
Signatur lesen klappt bis einschließlich 250 kHz, alles darüber ergibt
die Fehlermeldung, die immer beim Flashen kommt... Beim flashen kommt
sie allerdings immernoch...
Also, das Signatur - Lesen verhält sich genau so wie es sich verhalten
sollte.
Schließlich arbeitet der atmega8 im Auslieferungszustand der fuses mit
interner Takrfrequenz von 1 MHz und da darf ISP nicht schneller als 250
kHz sein.
@ Peter:
Ja, also die hex-File müsste auch stimmen... habe es gerade nochmal neu
kompiliert, ergibt auch keinen Fehler und keine Warnungen. Auch bei
anderen Projekten ergibt sich das gleiche Problem.
Auch das Auslesen des Flashes klappt, wenn ich die originale ausgelesene
.hex-Datei aber wieder versuche in den Flash zu programmieren, erscheint
der selbe Fehler...
Da muss ich jetzt passen.
Ein Stochern im Nebel:
Eventuell könnte da eine Leitung durch C oder R belastet sein, so, dass
das Lesen zwar klappt, nicht aber das Schreiben. Da müsste man die
Hardware auf dem Target prüfen. Eventuell könnte auch der Ausgang
gemordet sein, der beim Schreiben Ausgang ist (MOSI-Leitung).Da könnte
ein Scope helfen.
Eine Verzweiflungstat:
Irgendwie hab ich im Hinterkopf, dass das mit dem mkII anspruchsvoll in
bezug auf die Treibersoftware ist.
Installiere auf den AVR-Lab doch die Firmware vom STK500, und versuche
damit zu proggen, das läuft bei mir so einwandfrei, dass ich noch
garnicht die Idee hatte, die mkII-Firmware auszuprobieren.
Damit ließe sich dann klären, dass es nicht an der hardware liegt.
Und es liegt doch vermutlich daran, dass das falsche .hex-file
herumgeistert.
Versuch doch das einfachste file zu programmieren:
schleife:
nop
rjmp schleife
oder ein entsprechendes in C
Wenn auch das abgelehnt wird, liegt der Schluss nahe, dass irgendetwas
kaputt ist.
Prüfe auch die Spannungsversorgung: Vielleicht ist die so schwach auf
der Brust, dass das lesen/antworten noch klappt, das Programmieren aber
nicht.
Zitat:
USB AVR-Lab ist eine universelle Experimentier- und Labor-Plattform mit
USB Anschluss.
Sie kann durch verschiedene Firmwares in unterschiedliche Geräte
gewandelt werden.
Die Firmwares lassen sich einfach mit einem kleinen PC-Programm, genannt
USB AVR Lab Tool, im laufenden Betrieb austauschen. So kann das Lab z.B.
als Experimentierplattform für eigene kleine AVR Programme, AVR-ISP
Programmeradapter, JTAG Adapter, I2C,-SPI,-RS232/RS485 Logger,
Oszilloskop u.v.m. genutzt werden.
Kauft doch nicht so einen gefrickelten Murks!
Hi Christian,
wo war denn der Timingfehler? Bzw. unter welchen Umständen tritt er auf?
Inzwischen habe ich drei Stück aufgebaut, alle funktionieren und machen
mir das Leben leichter. Nur an den Uni-Rechnern funktioniert es nicht,
firmware ist avrisp mkII, OS Linux.
@Murks
Ich benutze das Teil seit >1 Jahr.
Läuft gut, nur sehr selten mal ein kleiner Aussetzer.
FW wird auf dem aktuellen Stand gehalten.
In der Firma benutze ich den Original MKII, privat das AVR-Lab. Macht
keinen großen Unterschied.
@Christian
Hab mir eine 1-seitige Platine dafür layoutet, die einfacher nachzubauen
ist und ein paar kleine Modifikationen enthält (z.B. auch 6-pol Stecker)
Hab mehrere davon im Einsatz. Eine zum Programmieren, den Rest für
Versuche.
Wirklich super Arbeit, Danke!
Dieter,
naja meine Lab Leiterplatten sind nicht wirklich auf nachbauen getrimmt
deswegen auch SMD, eher auf Preis und Funktioanität. Ich bin nicht davon
ausgegangen das es bei dem Preis doch noch so viele Nachbauer gibt. Was
mich aber keineswegs stört. Es wird wohl übern Winter wieder eine neue
Hardware geben aber ich will noch nicht zuviel versprechen ;)
lg
Christian
Hallo Christian,
es ging mir nicht um den Preis, sondern eher um den Spaß und die kleinen
(für mich) hilfreichen Modifikationen. Für das Layouten brauche ich ja
schließlich deutlich länger als ich normal arbeite, um das Geld für
Deine Platine zu verdienen. Hab aber auch SMD benutzt.
Falls Du Dir einen finanziellen Ausgleich wünscht, bin ich gerne zu
einer kleinen Spende bereit.
Wirst Du die FW für die alte HW weiter pflegen? Immerhin haben einige ja
Deine HW gekauft.
Gruß, Dieter
PS: Bin mal gespannt, was Du so vorhast.
Um Gottes willen nein, ich möcht dafür keinen Finanziellen Ausgleich
haben. Wenn jemand das ganze vertreiben will werd ich schon mal
hellhörig aber doch nicht bei Bastlern für die hab ich das ganze ja
gemacht :)
Die neue Hardware wird soweit möglich abwärtskompatibel bleiben brauchst
die also keine Sorgen machen die neuen Firmwares werden auch auf den
alten laufen, und wenn das wirklich nicht möglich wird werd ich trotsdem
noch kompilate für die "alten" anbieten. Wird also nichts
vernachlässigt.
lg
Christian
Hi,
also vielen Dank für die Hilfe aber daran lag es auch nicht. Hab jetzt
echt alles versucht, naja, ich krieg es wohl einfach nicht hin^^
Naja, mit dem USB AVR Lab Tool Programmer (in Verbindung mt der
USBasp-Firmware) kann ich problemlos die Programme draufladen, d.h.
sowohl die .HEX-Files als auch die Hardware sind als Fehlerquellen
auszuschließen...
Naja, mit diesem Umweg lässt es sich auch leben... Vielleicht fidnet
sich die Lösung ja irgendwann noch...
Vielen Dank für die Hilfe aber euch allen, find ich echt nett
Gruß,
Donner
Der "gefrickelte Murks" ist bei Vielen im Einsatz, auch bei mir
jahrelang als STK500, (Bootloader ist von 21.12.08, und das war schon
ein update) in selbst hergestellter Hardware und in einem Exemplar von
Christians SMD. Dafür Vielen Dank an Christian.
bugs zeigen sich, dank der so völlig offenen Dokumentation von Windows
oft erst auf fremden Systemen in irgendwelchen extremen
Softwaregeflechten. Anderes als Murks ist unter Windows wohl nicht zu
schaffen.
@Donner,
Du hast das alte USB AVR LAb Tool aufgespielt, und dann auch die
AVRISPmkI Firmware neu geflasht ?
hast du auch die STK500v2 Firmware probiert ?
lg
Christian
Hallo Donner,
solch ein Fehlerbild habe ich auch bis heute gehabt.
ATmega 8, Attiny2313 und Atmega 162 haben alle diese Fehlermeldung
gebracht.
Ich war schon am verzweifeln. Ein Umflashen auf STK500v2 Firmware hat
nicht richtig geholfen. Atmega8 klappte besser, aber Attiny wollte
nicht.
Heute hatte ich die Idee, eine andere Targetplatine zu nutzen. Alte
Sebstbauplatine aus der Bastelkiste geholt und siehe da, alle obigen
Atmegas ließen sich problemlos programmieren.
Als Fehlerquelle habe ich die Quarze auf dem Pollin Evaluationsboard 2.0
ausgemacht. Alle Quarze durch 4 MHz Werte ersetzt. Vorher waren 8 und
16MHz drin. Ob es daran lag oder Lötfehler?
Zumindest hatte vorher dieses Board mit Ponyprog funktioniert.
Egal. Das USB LAB ist eine feine Sache.
Dank an Christian.
MfG
Bodo
Hallo!
Habe die Schaltung auch nachgebaut.
Allerdings mit 16MHz Quarz (habe keinen anderen und beim bestellen ist
der Versand teurer als der Quarz.
Erfolg(?): rote und grüne LED leuchten und USB: Gerät nicht erkannt.
Weiterhin habe ich aus Mangel an Z-Dioden 2 Dioden in Reihe zu den 5V
des USB.
Gibt es ein Upgrade der Firmware?
Beim VUSB (ist doch ein Teil des Codes?) wird u.a. 16MHz unterstützt.
http://www.obdev.at/products/vusb/index.html
Wäre toll, wenn´s geht!
Leider kann (naja, es geht - für mich reichts halt) ich nur Bascom.
Kein Plan von Hex oder C. Irgendwo habe ich gelesen, dass einer im
Quellcode die usbconfig.h mit der vom VUSB ersetzt und angepasst hat.
Danach lief auch USB mit 16MHz-Quarz...
