Atmega32: Kaputtflashen?

Das Flash soll laut Datenblatt mindestens 10000 Schreibzyklen vertragen. 
Und selbst danach ist es nicht schlagartig hinüber, sondern die Daten 
werden nicht mehr für längere Zeit gehalten, nach ein paar Jahren können 
also Bits kippen. Von daher ist es ziemlich unwahrscheinlich, dass du 
bei allen Controllern das Flash verschlissen hast.

Eine mögliche Erklärung wären aber Störungen durch eine zu lange 
ISP-Leitung. Wie lang ist sie bei dir?

Julian W. schrieb:

> Kennt einer dieses Phänomen und weiß, wie ich dieses Problem lösen kann?

Das ist zu 99,9% irgendein Timing oder Pegelproblem mit den ISP 
Signalen. Mit anderen Worten: Entweder hast du irgendwas an den ISP Pins 
hängen die die Signale blockieren, oder der Programmer ist Mist.

Nunja, ich hatte den Atmega auch schon in einem externen 
"Programmiersockel", wo gerade die ISP-Buchse, ein Quarz und die 
Spannungserzeugung ist.
Da funktioniert der IC auch nicht mehr. Bisher hat der Programmier immer 
zuverlässig funktioniert und auch jetzt programmiert er noch fleißig 
ohne Probleme Atmega8 (habs gerade ausprobiert).

Das Kabel ist höchsten 20cm lang + das, was auf der Platine ist. Sind 
also "höchsten 30cm", dürfte also keine Probleme geben.

Kann es sein, dass die Schaltung auf der Platine das Signal so 
verfälscht, dass er z.B. die Fuses ändert, z.B. die für die Taktquelle?

Julian W. schrieb:

> Kann es sein, dass die Schaltung auf der Platine das Signal so
> verfälscht, dass er z.B. die Fuses ändert, z.B. die für die Taktquelle?

Wenn die Software des Programmers ordentlich geschrieben ist, so dass er 
nur dann was macht wenn ISP funktioniert (also z.B. wenn die ID passt), 
dann sollte sowas nicht passieren.
Wenn man dagegen einfach losprogrammiert obwohl nichtmal das ID Lesen 
funktioniert, dann kann es durchaus passieren, dass die Befehle komplett 
falsch ankommen. Vor allem wenn sehr viele Daten geschrieben werden, 
steigt die Wahrscheinlichkeit dass ein Byte davon zufällig den 
entsprechenden Befehl ergibt.

Also den Programmer, den ich benutze (avrdude + BurnOMat) prüft vorher 
die ID der Atmegas. Von daher dürfte da nichts passsiern.

Ich hatte am ISP-Port noch die ganze Zeit Daten-Leitungen von einem 
KS0108-Controller anliegen (hab ich jetzt mal testweise entfernt, 
funktioniert aber trotzdem nicht).

Kann es sein, dass dadurch der Controller irgendwie Schaden genommen hat 
oder dass diese Leitungen die ganzen Schreibe-Fehler verursacht haben?

Hallo,
hatte so was ähnliches auch mal!
Bei mir lag es am Kabel vom Programmer zum Board, das war zwar nicht zu 
lang, aber es hat sich irgendwann gaaaanz langsam ein Wackelkontakt 
eingeschlichen.
Brauchte ewig, bis ich draufkam....


Gruß

Julian W. schrieb:

> Ich hatte am ISP-Port noch die ganze Zeit Daten-Leitungen von einem
> KS0108-Controller anliegen (hab ich jetzt mal testweise entfernt,
> funktioniert aber trotzdem nicht).
>
> Kann es sein, dass dadurch der Controller irgendwie Schaden genommen hat
> oder dass diese Leitungen die ganzen Schreibe-Fehler verursacht haben?

Ja, kann sein. Wenn die RW Leitung auch am AVR hängt, dann kann diese 
auf high driften, zusammen mit Enable, was das LCD veranlasst die 
Leitungen auf Ausgang zu schalten. Ein Pulldown an Enable sollte das 
Problem aber lösen.
Theoretisch kann der Controller beschädigt werden, aber wahrscheinlich 
ist das eher nicht. Es werden nur die Fusebits komplett verstellt sein. 
Also neuer AVR rein, Pulldown an Enable vom LCD rein und schauen ob das 
Problem immer noch existiert.

So, hab mal das Kabel ausgetauscht. Funktioniert leider immer noch nicht 
:(

Mal morgen weiterprobieren und sehen, ob ich eine Lösung finde...