Hallo, ich habe ein Problem mit der Flash-Programmierung meines Atmega8. Wenn ich versuche den Flash mit einem Programm-Code zu beschreiben kommt eine Fehlermeldung. Das komische an der Sache ist, dass das Board mit dem selben Controller vorher noch ging. Im Forum habe ich schon ähnliche Probleme gefunden, jedoch haben mir die Beiträge nicht weiter geholfen. Hier erstmal ein paar Informationen zum Aufbau: selbst zusammengelötetes Board mit Spannungsversorgung(7805), Taster, LEDs, RS232 Schnittstelle(MAX232), µC Atmega8 (1MHz interner Takt) und einem 6pol ISP Anschluss. - Programmierer ist ein AVR mySmartUSB light,6-polig, 30cm Flachbandkabel - Programmierumgebung Atmel Studio 6.2 - Der ISP Takt liegt bei 57kHz Was habe ich schon versucht: - Spannungsversorgung geprüft - Verbindung vom ISP zum Controller gecheckt - ISP Takt erhöht und verringert - Anstatt Atmel Studio ProgTool verwendet - dann habe ich mal die Fuses-Bits ausgelesen. Diese sollten i.O. sein. Dann aber hab ich die Lock-Bits ausgelesen und musste feststellen, dass diese auf "disabled" gestellt sind. Also das ich den Flash nicht beschreiben kann. Aber wie kommt das? Ich habe da überhaupt nichts eingestellt. Als nächstes hab ich versucht mit "erase chip" alles vom Controller zu löschen. Ich habe gelesen, dass damit auch die Lock-Bits gelöscht werden. Das hat leider nichts gebracht. Anschließend habe ich versucht die Lock-Bits mit 0xFF zu beschreiben. Laut Atmel Studio sollte dies auch erfolgreich geklappt haben, aber wennn ich diese erneut auslese steht wieder der selbe Mist wie vorher drin. Was mache ich da falsch? Ist der µC defekt oder hab ich den Programmer geschrottet? Ich hoffe jemand hat für mich einen Rat. Ich bedanke mich schon mal dafür. Gruß Tobias
>- dann habe ich mal die Fuses-Bits ausgelesen. Diese sollten i.O. sein. Der Chip kommuniziert nicht mehr mit dir. Wie kommst du darauf dass dann die Fusebits in Ordnung sind? >Dann aber hab ich die Lock-Bits ausgelesen und musste feststellen, dass >diese auf "disabled" gestellt sind. Gleiches Problem wie oben. Der Chip redet nicht mehr mit dir. Das was du denkst als Lock Bits auszulesen ist einfach nur noch Bullshit. Vermutung: Fuses auf externen Takt gesetzt. Also lege mal einen externen Takt an.
holger schrieb: > Wie kommst du darauf dass dann die Fusebits in Ordnung sind? Weil alle Bits so gesetzt sind wie im Ur-Zustand. Mit dem 1MHz internen Takt,... Aber wenn du sagst, dass er nicht mehr mit mir kommuniziert dann interpretiert das Atmel Studio womöglich irgendwas zusammen. Jetzt bin ich mir natürlich nicht mehr sicher ob die passen. holger schrieb: > Vermutung: Fuses auf externen Takt gesetzt. Wie soll das den passiert sein. Der Reiter "Fuses" und "Memory" kann ich gerade noch unterscheiden. Oder wie könnte das sonstnoch passiert sein? holger schrieb: > Also lege mal einen externen Takt an. Reicht da ein Quarz oder muss es ein Quarzoszillator sein bzw. woher soll ich den Takt nehmen?
>> Wie kommst du darauf dass dann die Fusebits in Ordnung sind? > >Weil alle Bits so gesetzt sind wie im Ur-Zustand. Mit dem 1MHz internen >Takt,... Ok, sagen wir mal der Chip redet noch mit dir. >ich versuche den Flash mit einem Programm-Code zu beschreiben kommt eine >Fehlermeldung. Was für eine Fehlermeldung? >Hier erstmal ein paar Informationen zum Aufbau: >selbst zusammengelötetes Board mit Spannungsversorgung Abblockkondensatoren dicht am uC? Wenn du magst Schaltplan und Foto vom Aufbau posten. Das kann sonstwas sein. Kabelbruch im ISP Kabel, Wackelkontakt im ISP Stecker... Alles schon selbst erlebt.
Solange Du nicht die richtige Signatur lesen kannst, sind alle weiteren ISP-Kommandos Unsinn.
Wie Peter schon schrieb: Signatur auslesen. Wenn die nicht stimmt dann stimmt was mit dem ISP nicht: Spannungsversorgung, kalte Lötstellen,...
Hallo, holger schrieb: > Was für eine Fehlermeldung? An error occured while executing command with ID 0x13. Timed out waiting for a response. Und danach steht im Textfenster vom Atmel Studio: Erasing device... OK Programming Flash...Cancelled holger schrieb: > Abblockkondensatoren dicht am uC? Also ich habe einen 100nF Kerko direkt zwischen VCC und GND. Dieser ist direkt an den Pins auf der Unterseite der Platine. Jetzt habe ich nachträglich noch einen zwischen AVCC und GND gelötet. Peter D. schrieb: > Solange Du nicht die richtige Signatur lesen kannst, sind alle weiteren > ISP-Kommandos Unsinn. Also für die Signatur gibt mir das Atmel Studio folgendes aus: device signature 0x1E9307 Ich habe nun alles Mögliche ausprobiert. Wenn er verfused ist, kann ich sowieso nichts mehr machen. Ich frage mal in meinem Umfeld nach, ob jemand ein STK500 Board hat. Dann könnte man es mal mit HV-Prog probieren. Das Problem auf meinem Board ist dann aber trotzdem noch vorhanden. Könnte es sein, dass ich meinen mySmartUSB light zerstört habe? Außer durch einen Kurzschluss fällt mir Nichts ein was ich auf einem 5V Board hätte falsch machen können.
> device signature 0x1E9307
Ist korrekt.
Kann es sein, dass die Spannungsversorgung instabil ist?
Versuche es doch mal mit dem Tool von myAVR: http://shop.myavr.de/index.php?sp=download.sp.php&suchwort=dl112
Stefan U. schrieb: > Kann es sein, dass die Spannungsversorgung instabil ist? Ich habe es gerade mal nachgemessen. Also mit dem Oszilloskop kann ich keine Einbrüche feststellen. Die Spannung liegt bei 5,03V BlaBla schrieb: > Versuche es doch mal mit dem Tool von myAVR: Das habe ich schon versucht. Hat leider nicht weiter geholfen. Das Programm hat anscheinend den Controller erkannt, aber beim flashen stand als Fehler "irgendwas mit gesendete Daten stimmen nicht mit empfangenen Daten überein". Also entweder kann oder will der µC mir nicht antworten. Ich habe jetzt noch einen Atmega8 da liegen. Ich könnte ja mal den draufstecken, aber wenn es ,wie vermutet am Board liegt, dann mach ich den auch kaputt.
Platine mit der Methode "des scharfen Hinsehens" überprüfen. Kurzschluss, kalte Lötstelle, Verschaltung.....
Du kannst den ATmega auch mal direkt an die Programmen legen. Eine eigene Stromversorgung hat er ja.
Es gibt Neuigkeiten zum Thema. Ich habe nochmal alles, was ich schon gemacht habe und die Tipps von Euch, ausprobiert. Auch ein neuer Atmega 8 hat das Problem nicht gelöst. Aber dann hab ich, wie schon von BlaBla vorgeschlagen, das myAVR ProgTool verwendet. Und plötzlich ließ sich der Flash beschreiben. Hab es gleich mit dem alten µC getestet und es programmierte als wäre nie etwas gewesen. Anschließend wollte ich es mit dem Atmel Studio testen. Und da liegt immernoch der gleiche Fehler vor. Die gleiche Fehlermeldung wie schon beschrieben. Danach wollte auch das ProgTool nicht mehr. Erst nachdem ich den ISP erneut aufsteckte ließ der µC sich mit ProgTool flashen. Woran könnte das den liegen? Ich habe doch die ganze Zeit schon mit dem Atmel Studio den µC beschrieben. Kann es sein, dass die ISP Frequenz die Ursache ist. Mir kommt es so vor als ob sich die Übertragungsfrequenz nicht ändert, wenn ich im Atmel Studio den Regler verschiebe. Er stellt sich nach dem Schließen des Fensters wieder auf 57kHz ein. Ist das normal? Gruß Tobias
Nur eine Vermutung: die USB-Schnittstelle (virtueller COM-Port) blockiert. Dieser Fehler ist bei mir leider auch nach dem Upgrade von Windows 7 auf Windows 10 vorhanden. Teilweise werden USB-Geräte erst nach Neustarts und mehrmaligem Stecken richtig eingebunden. Scheint so, dass das Nachwirkungen des Upgrades sind. Hin und wieder benutze ich einen anderen USB-Hub dann klappt es auch. Das Flashen der MCU mache ich immer über das myAVR-Tool, auch wenn ich mittels Atmel Studio 7.0 programmiere. Man kann den myAVR-Programmer auch extern im Studio einbinden. Es gibt eine Anweisung auf der Webseite von myAVR dafür.
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.