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
Hm, ich habe es jetzt auch nochmal mit einem Atmega32 probiert, gleiches Problem... hat niemand eine Idee woran das liegen könnte?
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.
Asche auf mein Haupt, in der letzten Version des Tools scheint sich ein Timing Fehler eingeschlichen zu haben der auf einigen rechnern auftritt. Probier mal diese Version: http://shop.ullihome.de/catalog/userdownloads/10403_0de_0avrlabtool_i386-win32-5_8.exe oder nimm die STK500 Firmware. lg Christian
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...
Bitte 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.