Forum: Mikrocontroller und Digitale Elektronik Atmega 1284p verliert Programm


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Klaus (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo
Für ein Projekt nutze ich einen Atmega 1284p. Wenn ich ein Programm 
drauf speichere und es von der Stromversorgung trenne kann ich es nach 
ca. 10 min nicht mehr ausführen. Habe das gleich mit einem zweiten Teil 
gleicher Bauart gemacht und das Teil behält die Speicherung. Ansonsten 
hat das Teil keinerlei Einschränkung oder Fehlfunktionen.
Bleibt natürlich die Version eines neuen Prozessors. Warum passiert das?

LG Klaus

von Curby23523 N. (Gast)


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

von Cyblord -. (cyblord)


Bewertung
0 lesenswert
nicht lesenswert
Machst du nach dem Flashen eine Verfication des Flash Inhalts?
Ist die direkt nach dem flashen noch ok? Was sagt sie nach 10 Minuten?

von Test (Gast)


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

von Adam P. (adamap)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Klaus,

bist du dir wirklich sicher, dass das Programm aus dem Flash 
"verschwindet"?

Hast du mal nach dem angeblichen Verlust, den Flash in eine HEX Datei 
oder ähnliches ausgelesen und mal den Inhalt mit deinem Programm-File 
vergliechen?

Ich vermute eher, dass da was beim Boot passiert - kann mir nicht 
vorstellen, dass der Flash den Inhalt verliert.

: Bearbeitet durch User
von Johnny Easylife (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Klaus schrieb:
> Atmega 1284p verliert Programm

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

von Michael R. (fisa)


Bewertung
-1 lesenswert
nicht lesenswert
fehlender Pullup am Reset-Pin?

von Curby23523 N. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Michael R. schrieb:
> fehlender Pullup am Reset-Pin?

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

von Arduino Fanboy D. (ufuf)


Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von Cheffe (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Ist heute nicht Freitag?

von Johnny Easylife (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
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.

von Bär Luskoni (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Klaus (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Curby23523 N. (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
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?

von Reinhard R. (reirawb)


Bewertung
0 lesenswert
nicht lesenswert

von Werner S. (wernertrp)


Bewertung
1 lesenswert
nicht lesenswert
Direkt nach dem Programmieren startest Du das Programm mit einen Reset.
Es geht.
Jetzt wartest du 1 Minute.
Dann Reset.
Das Programm geht.
Das widerholst Du 10 mal.
Dann nach 10 Minuten startet es nicht mehr ?

Jetzt mußt Du das Hex file aus dem Prozessor auslesen
und mit dem Original vergleichen.

Was kommt raus ?
verify ok.

Besonders schlimm wäre es wenn alles nach einer Stunde Wartezeit 
plötzlich wieder gehen würde.

Mach das Programm ganz ganz.  Einfache nur Code für eine Led blinken 
lassen reinprogrammieren.
Dann das ganze wiederholen.

von Werner S. (wernertrp)


Bewertung
0 lesenswert
nicht lesenswert
Werner S. schrieb:
> Direkt nach dem Programmieren startest Du das Programm mit einen Reset.
> Es geht.
> Jetzt wartest du 1 Minute.
> Dann Reset.
> Das Programm geht.
> Das widerholst Du 10 mal.
> Dann nach 10 Minuten startet es nicht mehr ?
>
> Jetzt mußt Du das Hex file aus dem Prozessor auslesen
> und mit dem Original vergleichen.
>
> Was kommt raus ?
> verify ok.
>
> Besonders schlimm wäre es wenn alles nach einer Stunde Wartezeit
> plötzlich wieder gehen würde.
>
> Mach das Programm ganz ganz.  Einfache nur Code für eine Led blinken
> lassen reinprogrammieren.
> Dann das ganze wiederholen.

... schreibe mal lauter nops rein bis zum LED blink so das der ganze 
Speicher mit nops voll ist.

Dann alles wiederholen.

von Peter D. (peda)


Bewertung
1 lesenswert
nicht lesenswert
Klaus schrieb:
> Wenn das Programm scheinbar weg ist, startet es
> nicht mehr.

Dann schließe den Programmer wieder an und mache ein "Verify". Darfst 
natürlich nicht die Lockbits gesetzt haben.

Du solltest auch immer das Brownout-Reset einschalten (siehe Fuse-Bits).

von Gerhard O. (gerhard_)


Bewertung
0 lesenswert
nicht lesenswert
Ein Kollege von mir hatte letzte Woche auch eine mysteriöse Gegebenheit 
mit einem 328. Er war gerade beim Testen seines Programs wo er mit einem 
Draht gegen Masse Schalter simulierte. Da schließ er versehentlich Vcc 
kurz. Beim nächsten Upload stellte sich dann heraus, daß der Bootloader 
nicht mehr funktionierte obwohl sein Programm noch funktionierte. 
AVRdude konnte ums Verrecken nicht mehr damit klar kommen. Der Fehler 
war "Kann nicht synchronisieen". Da nahm ich seine Bord heim und las den 
Bootloader mit AVR-ISP heraus was keine Schwierigkeiten machte und auch 
die Fuse Einstellungen stimmten noch. Beim Vergleich des Bootloader 
Codes mit einer funktionierenden Bord mit gleichen Bootloader stellte 
sich heraus, daß sich ein Byte geändert hatte. Nach Flashen eines neuen 
guten Bootloaders ging dann die Bord wieder.

Ist das schon einmal bei Euch vorgekommen?

von Soul E. (souleye) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von Stefan ⛄ F. (stefanus)


Bewertung
-2 lesenswert
nicht lesenswert
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.

von Gerhard O. (gerhard_)


Bewertung
1 lesenswert
nicht lesenswert
soul e. schrieb:
> Öfters, wenn auch bei anderen Controllerfamilien...

Danke für Deinen aufschlußreichen Bericht. Das ist nützlich zu wissen. 
Ich werde ihm raten unbedingt den B.O. detektor zu aktivieren wenn er 
das nicht schon gemacht hat.

Persönlich machte ich mit FLASH Problemen noch keine diesbezüglichen 
Erfahrungen mit meinen AVRs bis jetzt.


Schönes Wochenende noch,
Gerhard

P.S. Die Flash data retention time sinkt mit der Anzahl der 
Löschzyklen...

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

: Bearbeitet durch User
von Soul E. (souleye) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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

: Bearbeitet durch User
von Peter D. (peda)


Bewertung
0 lesenswert
nicht lesenswert
soul e. schrieb:
> 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

Wo hast Du diese Zahlen her?

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

von Welt Reisender (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Peter D. schrieb:
> Wo hast Du diese Zahlen her?

Hat er im Internet gelesen.

Und alles was im Internet geschrieben steht ist wahr!

von Soul E. (souleye) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Harald (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
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.

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
soul e. schrieb:
> 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.

hmm ist kaum zu glauben, jedenfalls bei meinem den ich schon etliche 
100x in der Entwicklung programmiert habe, der läuft nun seit 3 Jahren.

Nach dieser Theorie dürfte er in 2 Jahren Daten verlieren, mal sehen, 
ich glaube nicht daran.
Wackler und unsaubere VCC als Ursache glaube ich schon.

von Soul E. (souleye) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.