Atmega 8 Flash nicht mehr beschreibbar

>- 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.

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.

den Programmer .... sollte das heißen.

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.