www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik ATTiny26-EEPROM: Zuverlässigkeit!


Autor: Andi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!

Habe in meinem Prog Routinen eingebaut, wo nach jeder
Parameteränderung, also nach Auswahl des Wertes eines Parameters und
dann nach setzen per Knopfdruck, ein Block mit 12 Bytes vom SRAM in das
EEPROM gespeichert wird.
Bei einem Stromausfall oder Reset stehen somit die zuletzt gemachten
Einstellungen wieder zur Verfügung.
Wie zuverlässig ist das EEPRO?
Hat schon mal jemand Probs mit dem EEPROM gehabt?
Kann man in den schon einige 100 male was schreiben, ohne das es Fehler
gibt?
Habe beim schreiben ein Verify eingebaut und bei Abweichung wird bis zu
10 mal das Schreiben wiederholt.

Gruß
Andi

Autor: Fritz Ganter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Datenblatt Seite 1?

Ich schreib 48mal pro Tag ins EEPROM bisher ohne Fehler.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Habe beim schreiben ein Verify eingebaut und bei Abweichung wird bis
zu 10 mal das Schreiben wiederholt."


Das dürfte nichts bringen.
Daß beim Schreiben was schiefgeht, habe ich noch nie gehört.
Man muß natürlich dafür sorgen, daß kein Interrupt dazwischenhaut
zwischen die beiden Schreibbefehle.

Fehler treten immer nur beim Aus- und Einschalten auf.
Brown-Out setzen ist daher Pflicht.

Wenn man absolut sicher gehen will empfehle ich 2 oder 3 Datensätze mit
Prüfbyte (CRC).


Peter

Autor: OldBug (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und wenn dann noch ein Fehler auftaucht beim Schreiben, dann sollte man
davon ausgehen, daß die max. Schreibzyklen erreicht wurden und das
eeprom austauschen. Bei internem wirds schwierig, da muss man dann den
ganzen Controller tauschen...

Autor: Andi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das mit den IRQ´s habe ich berücksichtigt.
Also vor dem setzen von EEMWE und EEWE ein CLI und danach ein SEI.

Das mit dem CRC muß ich mir noch mal überlegen.
Habe nur noch 22 Words im Flash frei. Wird knapp.

@Fritz: Das reicht ja dann für über 5 Jahre.
Wollte hier auch nur Fragen, ob schon jemand früher, nach ein paar 100
Writes, bereits ein Problem hatte.

Gruß
Andi

Autor: Claus Thaler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Irgendwo bei Atmel oder Microchip gibts ne Application Note, die sich
mit diesem Thema befasst. Man kann über einen Zyklischen Ringpuffer die
Datensätze über das ganze EEProm verteilen und so den Verschleiss
einzelner Bytes verringern, das sollte für die meisten Fälle
ausreichen.

Autor: Andi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Verteilen wird nur schwierig, wenn man das EEPROM so gut wie voll
macht weil man neben den im EEPROM befindlichen Default-Werten an Adr.
00h und der Sicherung der Parameter an Adr. 10h noch 6 Benutzerplätze
ab Adr. 20h per Save-Funktion zur Verfügung stellt.
Na ja, egal.
Atmel gibt mindestens 100.000 Schreibvorgänge an und sollte dann für
Jahrzehnte reichen.

Gruß
Andi

Autor: Gunter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Andi,

nimm NICHT die Speicherzelle 00h !
Angeblich ist die besonders oft bei Fehlern betroffen.

Ich weiß allerdings nicht, ob das auch für die ATTiny gilt.

Gunter

Autor: Heinz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

ist die Zelle 00 nicht nur deshalb besonders betroffen, weil EEAR meist
(da unbenutzt) den Wert 00 enthält?

Irgendwo habe ich aber gehört, dass das Problem hauptsächlich bei den
AT90ern ("Classic-AVR") auftrat, mangels BOD. Tinys und Megas kann
man wohl per BOD davor schützen.

MfG, Heinz

Autor: Gunter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Hein,

>Tinys und Megas kann man wohl per BOD davor schützen.
ich bin mir sicher, daß schon berichtet wurde, daß es
trotz BOD bei Megas Probleme gab.

Deshalb laß ich die Zelle 00h lieber aus.

Gruß
Gunter

Autor: Andi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie jetzt, soll das etwa heißen, das wenn im Adressregister 00h drin
steht, alle 8 Bit low also auf GND geschaltet, dass das mehr Strom
braucht beim Schreiben?
Ist das auch beim Lesen der Fall?
Bei Adresse 00h bis 0Fh wird nur bei Programmstart und bei manueller
Ausführung gelesen aber nie geschrieben.
Ist auch nur für Defaultwerte gedacht welche nur von Pony-Prog mittels
EPP-Datei vom Compiler geschrieben werden und dann nie wieder.
Nur von 10h bis 7fh wird geschrieben und gelesen.
Wie macht man das eigentlich mit dem BOD?
Ich weiß nur, das dieses ab einer Spannungsgrenze nach unten einen
Reset durchführt.
Muß man den nur aktivieren und das wars dann?

Gruß
Andi

Autor: Malte Marwedel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mit dem Stromverbrauch hat das nix zu tun. Es ist blos bekannt, dass
nach einem nicht ganz sauberen AVR Start (ziemlich egal was das
Programm nun macht) gerne mal die Erste EEProm Speicherzelle mit 0x00
beschrieben wird, also die urspränglichen Daten verloren gehen.
Insbesondere von der AT90S Serie ist dieses Verhalten bekannt. Ich
hatte es aber auch schon mal, dass andere Zellen bei einem fehlerhaften
Prog Start müt Müll überschrieben wurden (AT90S8535).

Autor: Marco (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
was ist "Brown-Out"?
und reicht ein kleiner kondensator/gold cap als pufferung aus, um bei
spannungsverlust noch daten ins eeprom schreiben zu können? zb die
letzte uhrzeit beim stromausschalten?

Autor: Malte Marwedel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>was ist "Brown-Out"?
http://www.mikrocontroller.net/wiki/Brownout

Es kommt ganz auf den Stromverbrauch des Controllers und der Kapazität
des Kondensators an, ob die Zeit ausreicht um Daten zu sichern. Zu
beachten ist hier, dass der Controller mitgeteilt werden muss, dass der
Strom demnächst abfallen wird.

Autor: Andi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wegen dem BOD:
Es gibt ja ein Flag in MCUSR für einen Brown-Out welches man testen
kann.
Wenn man dieses Bit regelmäßig prüft, was macht man dann in disem
Fall?
Brown-Out-Reset heißt doch eigentlich, das es einen Reset nach einem
Brown-Out gegeben hat, oder?
Wie kann man in ASM verhindern, das die CPU bei einem Brown-Out
"verrückt" spielt und irgendwas an den Pin´s schaltet?

Gruß
Andi

Autor: Marcus M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Andi,

wenn diese Flag gesetzt ist, dann ists ja schon zu spät!
Der Brown out Zustand ist erreicht worden.

Was nun Brown Out ist?
Ganz kurz erklärt, es kann der Zustand eintreten, das die
Spannungsquelle sehr viel Strom liefern muß - viele Verbraucher an -
und der µC mehr Strom ziehen möchte, als die Quelle zur Verfügung
stellen kann.
Die Quelle versucht diesem "Strommangel" auszuweichen und leider
sinkt dann die Spannung leicht ab. Nun gibts beim TTL aber eine
Schwelle, ab der der Signalzustand indifferent ist. IMHO irgendwas von
2,7V bei einem 5V (VCC) Baustein.
Sollte jetzt im µC aufgrund der gesunkenen Ausgangsspannung dieser
Zustand eintreten, dann wird anstatt einem Befehl aus dem Flash
irgendwas übertragen und somit auch irgendwas gemacht. Aber nicht mehr
das, was Du Dir gewünscht hast. Somit bleibt nur der sichere Reset in
einem solchen Zustand um dem dann entstehenden Choas vorzubeugen. Die
Daten, die in diesem Zustand ins Eeprom geschrieben werden sind
ebenfalls undefiniert!

Du kannst aner einige Statuswerte über den Brown-Out Reset retten.

Gruß Marcus

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Power-On-Reset des AVR wird schon bei etwas über 1V inaktiv. Das
reicht dann aber noch lange nicht, damit alle Transistoren ordentlich
arbeiten, d.h. die CPU spielt verrückt und zerstört z.B. den
EEPROM-Inhalt.

Der Bron-Out-Reset ist eine Art Spannungskomparator, der die CPU
solange in Reset hält, bis die Spannung wirklich hoch genug ist zum
sauberen Arbeiten und zusätzlich auch beim Spannungseinbruch
zuschlägt.


Peter

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]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [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.