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
Zu wenig Hintergrundinfos. Aber es ist unwahrscheinlich, dass das Programm flöten geht.
Machst du nach dem Flashen eine Verfication des Flash Inhalts? Ist die direkt nach dem flashen noch ok? Was sagt sie nach 10 Minuten?
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
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.
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?
Zum Thema, eine Möglichkeit: Beitrag "Re: Kann ein AVR zufällig seine Programmierung verlieren?" Reinhard
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.
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.
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).
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?
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.
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
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
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
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.
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.
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.