Atmega 1284p verliert Programm

Zu wenig Hintergrundinfos. Aber es ist unwahrscheinlich, dass das 
Programm flöten geht.

Vermutlich ein Reset Problem. Bist du sicher, dass dein AVR "leer" ist ?

Klaus schrieb:
> Atmega 1284p verliert Programm

Wie hast du das festgestellt?
Die Aussage ist höchstwahrscheinlich falsch.

Michael R. schrieb:
> fehlender Pullup am Reset-Pin?

Deswegen: Schaltplan, Software, Programmierer, Versorgung, Vorgehen etc. 
- das ist alles notwendig zu wissen.

Ich stimme meinen Vorrednern unumwunden zu.

Das Fehlerbild, bzw. ähnliche Fehlbilder, habe ich schon öfter gesehen.
Aber es war nie ein zerstörter/verlorener Flashinhalt.

Meine Glaskugel behauptet steif und fest:
Wenn sich 2 AVR eines Typs, aber mit gleichem Programm, unterschiedlich 
verhalten, dann liegt es an der Beschaltung, oder an den Fuses.

--
Wobei man natürlich nicht den seltenen/unwahrscheinlichen Fall, eines 
defekten µC, aus der Ferne, vollkommen ausschließen kann.

Ist heute nicht Freitag?

Curby23523 N. schrieb:
> Deswegen: Schaltplan, Software, Programmierer, Versorgung, Vorgehen etc.
> - das ist alles notwendig zu wissen.

Nicht wenn es ein Troll ist, was am heutigen Tag nicht ganz
auszuschliessen ist.

Insbesondere dann wenn sich der TO nicht gleich wieder meldet
obwohl er so ein dringendes, drängendes Problem hat.

Es soll Leute geben, die nicht die Zeit haben, den ganzen Tag in einem 
Forum herumzugammeln. Dann gibt es noch die Sorte Mensch, die eine 
Mittagspause hat und diese auch nutzt.

Dann gibt es wiederum Leute, die frei erfundene Sachverhalte als 
Tatsachen posten, so wie er hier:

Johnny Easylife schrieb:
> Insbesondere dann wenn sich der TO nicht gleich wieder meldet
> obwohl er so ein dringendes, drängendes Problem hat.

Der TO hat kein dringendes Problem. Nirgendwo hat er sich so geäußert. 
Im Gegenteil:

Klaus schrieb:
> Habe das gleich mit einem zweiten Teil
> gleicher Bauart gemacht und das Teil behält die Speicherung.

Also funktioniert sein Aufbau.

Fazit: Der erste Kontroller ist fehlerhaft. Das ist mir WIMRE mit Atmega 
8 auch schon einmal passiert. 4 Stück aus der gleichen Serie. 3 
tadellos, einer vergesslich.

Curby23523 N. schrieb:
> Zu wenig Hintergrundinfos. Aber es ist unwahrscheinlich, dass das
> Programm flöten geht.

Was soll ich dazu schreiben. Das Programm starte beim Anlegen der 
Spannung "ganz normal". Damit meine ich es so, das Programm startet und 
führt sein Ablauf aus. Wenn das Programm scheinbar weg ist, startet es 
nicht mehr. Habe es mit verschiedenen Programmen getestet. Beim anderen 
Teil passiert das nicht. Da die Hardware gleich ist dürfte es doch nicht 
passieren. Ausgelesen habe ich den Speicher nicht und kontrolliert. Habe 
noch ein 3 Teil mit gleicher Bauart. werde es heute Abend mal testen.

LG Klaus

Klaus schrieb:
> Curby23523 N. schrieb:
>> Zu wenig Hintergrundinfos. Aber es ist unwahrscheinlich, dass das
>> Programm flöten geht.
>
> Was soll ich dazu schreiben. Das Programm starte beim Anlegen der
> Spannung "ganz normal". Damit meine ich es so, das Programm startet und
> führt sein Ablauf aus. Wenn das Programm scheinbar weg ist, startet es
> nicht mehr. Habe es mit verschiedenen Programmen getestet. Beim anderen
> Teil passiert das nicht. Da die Hardware gleich ist dürfte es doch nicht
> passieren. Ausgelesen habe ich den Speicher nicht und kontrolliert. Habe
> noch ein 3 Teil mit gleicher Bauart. werde es heute Abend mal testen.
>
> LG Klaus

Was bedeutet "es startet nicht"? Wie überprüfst du das? Wie sieht dein 
Schaltplan aus, dein Programm usw.? Hast du dir mal die zahlreichen 
Antworten durchgelesen?

Gerhard O. schrieb:

> Ist das schon einmal bei Euch vorgekommen?

Öfters, wenn auch bei anderen Controllerfamilien.

Eine Brücke in der VDD zum Messen der Stromaufnahme, diese rutscht im 
Betrieb runter so dass der Controller nur noch parasitär über die I/Os 
versorgt wird. Anschließend gab's Bitkipper im Flash. Nach Löschen und 
neuprogrammieren war wieder alles gut. Das ist kein zulässiger 
Betriebszustand, aber kommt beim Experimentieren schonmal vor.

ESD-Entladung durch die Massefläche führt zu Latchup im Controller. Der 
stellt dann von rechnen auf heizen um. Spannung aus und wieder ein und 
Neuprogrammieren hilft. Chromteile so anbinden dass die Entladung 
aussenrum zum Stecker abfliesst hilft auch.

Atmel und Flash-Datenverluste bei Brownout war früher ein größeres 
Thema. Google sollte dazu noch was finden.


Die Flash data retention time sinkt mit der Anzahl der Löschzyklen. Die 
ersten 100 Zyklen halten die Daten 20 Jahre, die folgenden 1000 Zyklen 5 
Jahre, die folgenden 10.000 Zyklen 1 Jahr, usw. Du machst nicht 100x 
Firmware-Update, aber der zum Debuggen benutzte Controller sieht schon 
einige Zyklen. Den sollte man irgendwann entsorgen und nicht für das 
finale Produkt nehmen.

Bei instabiler Spannungsversorgung gehen manchmal Daten im EEPROM 
verloren. Wenn das Programm das EEPROM liest, könnte es auf unerwartete 
Daten unerwartet reagieren, was dann wie "startet nicht " aussehen 
könnte.

Dagegen hilft der bereits genannte Brown-Out Detektor und manchmal ist 
es auch hilfreich, ganz am Anfang des Programmes erstmal eine Sekunde zu 
warten, bevor es anfängt zu arbeiten.

Gerhard O. schrieb:

> Gibt es da einen bestimmten Bericht darüber auf den Du Dich beziehst
> oder sind das Deine eigenenen Erfahrungen durch Versuche belegt?

Das ist Physik. Ein bis zwei Stützstellen dieser Kurve geben die 
Hersteller üblicherweise in ihren Datenblättern an. Den restlichen 
Kurvenverlauf musst Du extrapolieren.

Offiziell gilt jegliches Verhalten jenseits der im Datenblatt genannten 
Löschzyklen als unspezifiziert. D.h. der Controller dürfte für 100 
Programmiervorgänge seine Daten 20 Jahre halten und beim 101. nach zehn 
Sekunden vergessen - das wäre kein Gewährleistungsfall.


Es gibt durchaus Paper zu dem Thema, z.B. 
https://www.micron.com/~/media/documents/products/technical-note/nor-flash/tn1230_nor_flash_cycling_endurance_data_retention.pdf

Peter D. schrieb:
> Wo hast Du diese Zahlen her?

Hat er im Internet gelesen.

Und alles was im Internet geschrieben steht ist wahr!

Peter D. schrieb:

> Wo hast Du diese Zahlen her?

Typische Werte zur Verdeutlichung des Zusammenhanges. Nicht auf einen 
speziellen Controllertyp bezogen.


> Im Datenblatt steht:
> Write/Erase Cycles: 10,000 Flash/100,000 EEPROM
> Data Retention: 100 Years at 25°C

Zu welchem Controller? In Deinem Fall dann 10 Jahre für die nächsten 
100.000 Zyklen, 1 Jahr für 1 Mio, 0,1 Jahr für 10 Mio, etc. Und die 
Temperatur geht auch noch ein. Das Prinzip sollte klar sein.

soul e. schrieb:

> Typische Werte zur Verdeutlichung des Zusammenhanges. Nicht auf einen
> speziellen Controllertyp bezogen.

Märchenonkel, der unhaltbaren Unsinn & Quatsch in die Welt setzt und 
dann mit einer billigen Ausrede versucht - seinen geistlosen Unfug zu 
relativieren.

Joachim B. schrieb:

> Nach dieser Theorie dürfte er in 2 Jahren Daten verlieren, mal sehen,
> ich glaube nicht daran.

Das ist schlicht und einfach Festkörperphysik.

Die absoluten Werte hängen von Deinem Controllertyp ab und können von 
meinem Beispiel abweichen. Der Zusammenhang "zehn mal so viele Zyklen 
gibt 1/4 bis 1/10 der retention time" gilt immer.

So wie Du beim Elko mit der Faustregel "zehn Grad weniger hält doppelt 
so lange" immer hinreichend genau ins Ziel kommst. Auch wenn der exakte 
Wert der Aktivierungsenergie exemplarabhängig ist.