mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Schreibzyklus EEprom


Autor: Fabian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

bei einem ATMega64 wurde jede Minute in zwei EEprom Speicherstellen 
geschrieben. Normalerweise hält das circa 70 Tage für 100000 
Schreibzyklen.
Allerdings war es viel länger über 200000 Schreibzyklen also über 140 
Tage.

Was passiert wenn ein EEprom defekt geht? Kann der uC abstürzen, weil er 
z.B. die Speicherstelle nicht mehr lesen kann? Kann das schreiben und 
lesen des eeprom ab und zu noch funktionieren? Wird der uC langsam und 
hängt irgendwo fest?

Programmieren lässt sich das Gerät noch normal. Es tritt ein 
sporadischer Fehler auf, denn ich bis jetzt nicht nachvollziehen kann. 
Es scheint als steht der UART, die SPI und die I2C. Erst nach einem 
Spannungsreset läuft das Gerät wieder. Der Watchdog ist eingeschalten.

Fabian

Autor: nils (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Meistens äusser sich das in Wirrwar, welches nach dem Schreiben im 
EEProm steht, bzw ob das da so steht lässt sich schwer herausfinden, das 
Wirrwar kommt beim Lesen zurück.

Schreib doch ein kleines Programm, welches dir immer ein bestimmtes 
Bitmuster schreibt von Vorn bis Hinten und wieder ausliest, sobald das 
nicht übereinstimmt, lass eine LED leuchten o.Ä.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Fabian (Gast)

>bei einem ATMega64 wurde jede Minute in zwei EEprom Speicherstellen
>geschrieben. Normalerweise hält das circa 70 Tage für 100000
>Schreibzyklen.

Naja, nicht so dolle. Macht man meist eher anders.

http://www.mikrocontroller.net/articles/Speicher#E...

>Was passiert wenn ein EEprom defekt geht? Kann der uC abstürzen, weil er
>z.B. die Speicherstelle nicht mehr lesen kann?

Nein. Du liest dann nur falsche Daten. Wenn aber dein Programm durch 
diese aus dem Tritt kommt, weil keine Fehler/Bereichsprüfung gemacht 
wird, dann kann dein uC abstürzen.

> Kann das schreiben und lesen des eeprom ab und zu noch funktionieren?

"Funktionieren" wird es immer, aber die Daten werden verändert. Am Ende 
liest du immer nur noch 0xFF, wenn alle Bits kaputt sind.

> Wird der uC langsam und hängt irgendwo fest?

Nein. Siehe oben. Das Programm ist ausserdem im Flash, nicht im EEPROM. 
Das sind getrennte Speicher im AVR.

>Programmieren lässt sich das Gerät noch normal. Es tritt ein
>sporadischer Fehler auf, denn ich bis jetzt nicht nachvollziehen kann.
>Es scheint als steht der UART, die SPI und die I2C. Erst nach einem
>Spannungsreset läuft das Gerät wieder. Der Watchdog ist eingeschalten.

Klingt nach dem oben genannten Fehler. Dein Programm verschluckt sich an 
unsinnigen Daten.

MfG
Falk

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

>bei einem ATMega64 wurde jede Minute in zwei EEprom Speicherstellen
>geschrieben. Normalerweise hält das circa 70 Tage für 100000
>Schreibzyklen.

Falscher Ansatz. Führe dir mal die AppNote 'AVR101: High Endurance 
EEPROM Storage' zu Gemüte.

>Allerdings war es viel länger über 200000 Schreibzyklen also über 140
>Tage.

Ist ja auch nur die Mindesthaltbarkeitsdauer.

MfG Spess

Autor: Fabian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn der Atmel aus dem Tritt kommt, müsste das dann immer sein und somit 
nachvollziehbar sein oder?

Fabian

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Fabian (Gast)

>Wenn der Atmel aus dem Tritt kommt, müsste das dann immer sein und somit
>nachvollziehbar sein oder?

Ja. Schreib mal testhalber falsche Daten rein und prüfe. Das kann aber 
knifflig werden, denn du weisst ja nicht auf welche falschen Daten er 
giftig reagiert.

MfG
Falk

Autor: Thilo M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Prüfen auf defekte Zellen ist recht einfach:
- Beschreiben aller Zellen mit 0x00
- EEPROM löschen (AVR-Studio)

Die defekten Zellen kommen dann beim Leertest automatisch ans Licht.
Wenn schon Zellen beschrieben wurden, dann einfach löschen (ohne 
vorheriges Beschreiben).

Autor: Fabian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thilo M. schrieb:
> Die defekten Zellen kommen dann beim Leertest automatisch ans Licht.
> Wenn schon Zellen beschrieben wurden, dann einfach löschen (ohne
> vorheriges Beschreiben).

Dann müsste das AVR-Studio auch einen Fehler bei Programmieren bringen, 
dass z.B. das der eeprom - Vergleich beim Programmieren Fehlgeschlagen 
ist, oder?

Die eeprom Stellen sind Konfigurationsparameter, wenn beim Auslesen an 
dieser Stelle noch das richtige drin steht, sollte noch alles ok sein, 
oder? Was anderes kann nicht defekt gehen?

Fabian

Autor: Thilo M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Dann müsste das AVR-Studio auch einen Fehler bei Programmieren bringen,
> dass z.B. das der eeprom - Vergleich beim Programmieren Fehlgeschlagen
> ist, oder?

So ist es.

> Die eeprom Stellen sind Konfigurationsparameter, wenn beim Auslesen an
> dieser Stelle noch das richtige drin steht, sollte noch alles ok sein,
> oder? Was anderes kann nicht defekt gehen?

In der Regel bleibt der zuletzt geschriebene Wert im EEPROM, wenn's 
defekt ist. Bin aber nicht ganz sicher ob Bits, die noch intakt sind, 
noch beschrieben werden können.

Autor: Fabian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Beim Schreiben einer defekten eeprom - Stelle kann dann nur passieren, 
das nicht das richtige an dieser Stelle drin steht?
Also es kann nichts weiter schlimmes passieren, wenn man versucht diese 
Stelle zu schreiben oder zu lesen? Wie z.B. Atmel stürzt ab weil eeprom 
nicht beschrieben werden kann.

Bzgl. Programmieren und eeprom Vergleich mit AVR-Studio - wenn man den 
gleichen Wert ins eeprom reinschreibt welcher schon drin steht und das 
eeprom an dieser Stelle ist, sollte das Programmieren trotzdem klappen, 
oder?

Fabian

Autor: Thilo M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Programmieren (außer bei defekten Speicherzellen) klappt immer, nur 
der Vergleich bringt dann Fehler, also kann der intakte Teil des EEPROMs 
ruhig weiterverwendet werden. Dass der AVR abstürzt oder sonst was 
passiert wird nicht passieren, er liest einfach falsche Werte aus den 
defekten Zellen.

Autor: Ben ___ (burning_silicon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
wenn du auf dem atmega noch speicherzellen im eeprom frei hast änder die 
adressen die das programm benutzt. dann machts der µC nochmal solange. 
und beim nächsten programm implementierst du eine 
wear-leveling-funktion!

eigentlich sterben die speicherzellen dadurch, daß die aus ihren 
spezifikationen hinauslaufen. idR brauchen sie einfach mehr zeit um 
beschrieben zu werden. wenn sie die nicht bekommen (weil die logik davon 
ausgeht die gewährte zeit reicht) gibts halt fehler beim schreiben. die 
daten-haltezeit dürfte ebenfalls unter der anzahl schreibvorgänge 
leiden.

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.