[ATMEGA32]Programmieren erfolgreich, aber keine Funktion mehr

[Anselm 6. (anselm68)]

Hallo,

ich stehe ein wenig auf dem Schlauch was mein Problem betrifft.
Ich programmiere mit einem Dragon oder ST500-Klon meine ATMEGA32A µC 
seit Jahren erfolgreich.
Jetzt, also seit heute, habe ich das Problem dass er Flasht, dann prüft 
und alles okay findet. Fuses sind natürlich vorher gesetzt worden.
Danach ist der Chip aber nichtmehr ansprechbar.... Lesecode bei der 
Signatur 0x00 0x01 0x02 - also keine Kommunikation.
Nach unterbrechen der VCC und wiedereinschalten geht es genau 1 mal 
anzusprechen.
das aufgespielte Programm bleibt beim Bootscreen auf dem angeschlossenen 
LCD stehen.

In der Boardserie ist überall der gleiche µC mit dem selben 
Produktionscode verbaut, dass ich also ein Fake habe ist sehr 
unwarscheinlich, denn die anderen Boards haben bisher immer tadellos 
funktioniert.
Mache ich ein Chiperase direkt nach einschalten der VCC kann ich ihn so 
lange ansprechen, solange ich ihn nicht programmiert habe.

Wo könnte denn der Fehler liegen?

Gruß
Anselm

[Rainer U. (r-u)]

Du hast nur einen Chip getestet? Oder mehrere? Einer geht auch mal 
kaputt, auch teilweise, so dass man meint, er lebt noch.. :-)

[Felix A. (madifaxle)]

Nutzt du einen Quarz für den Takt? Eventuell hier falsche Kondensatoren 
erwischt oder einen Quarz mit Macke?

[Anselm 6. (anselm68)]

Wie es so ist, nachdem ich 20Minuten die Frage hier getippt hatte und 
noch am suchen war, 5Minuten nach dem Absenden habe ich den Fehler 
selbst gefunden.
Schuld war der 2te µC der fälschlicherweise den WDT enabled hatte, 
dadurch hat er den Main mit Resettet.. so kann der natürlich nix machen 
;)

Merke: machst du es richtg, funktioniert es sogar!

Gruß
Anselm

und Danke für Eure Anteilnahme ;)

[c-hater (Gast)]

Anselm 6. schrieb:

> Nach unterbrechen der VCC und wiedereinschalten geht es genau 1 mal
> anzusprechen.

In diesem Nebensatz hast du höchstwahrscheinlich genau das Problem 
definiert.

Es ist bei so einem Fehlerbild hochwahrscheinlich, dass der Code 
(natürlich ungewollt) einen illegalen Hardwarezustand herbeiführt. Da 
normaler Code das natürlich nicht absichtlich macht, ist es wiederum 
hochwahrscheinlich, dass abstürzender Code das tut.

Also muss man verhindern, dass der Code bei Verlust der Betriebsspannung 
überhaupt die Chance bekommt, abzustürzen. Das tut man, indem man den 
genau für diesen Zweck vorhandenen "brown out detector" sinnvoll 
benutzt.

Also indem man ihn aktiviert und mit einem bezüglich der Umgebung der 
konkreten Anwendung sinnvollen Schwellwert ausstattet. Beides tut man 
über die zielführende Programmierung der entsprechenden Fuses.

Und (fast) alles Wissenswerte darüber steht (wie immer) im Datenblatt...