mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Bitfehler im EEPROM


Autor: Mathias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

wie wahrscheinlich ist es, dass irgendwelche Bits im EEPROM umfallen?

Konkret handelt es sich um einen PIC16F688 mit internem EEPROM. (EEPROM
wurde sicher nicht öfter als 10x beschrieben .. ) Ich hatte diesen
Effekt jedoch auch schon vor Jahren bei einem AT90S8515.

Lustigerweise tritt der Effekt nur im "gestörten" Gelände (also nicht
im Büro) auf!

Nur ist das Speichern von Daten im EEPROM wohl eine gängige Technik,
die auch in wesentlich "gestörterem" Umfeld funktioniert( AUTO,
Maschinen ...).

Werden eigentlich sensible Daten eher in einem externen EEPROM
gespeichert als im uC - internen??

Mfg, Mathias

Autor: Daniel M. (sierra)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das mit den "umgefallen" Bits in PICs hatte ich bei meinem alten
Arbeitgeber öfters und die Geräte in denen der verbaut wurde arbeiten
in Industrieumgebung.

Autor: Mathias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hmm, habt ihr dann ein externes EEPROM verwendet?

Autor: crazy horse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
jo, I2C-Eeprom.
Ausserdem kann man ne Menge per Software erledigen (mehrfach speichern,
Majoritätsentscheidung).

Autor: Mathias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Spricht ja nicht gerade für die Pic uC's! Oder ist das ein allgemeines
Problem, das uC's mit integriertem EEPROM haben?

Ich werde dann das I2C EEPROM von ATMEL(AT24C01A) verwenden und hoffen
dass das Umfallen von Bits dann der Vergangenheit angehört!

Bieten eigentlich EEPROMS für den Automative - Bereich eine höhere
"Datensicherheit" als die für den industriellen Bereich?

Mfg, Mathias

Autor: TravelRec. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kann ich nicht nachvollziehen, nix "umgefallen" bisher bei meinen
AVRs, auch nicht beim 8515 - ich würde eher sagen, daß die Problematik
beim Speichern auftritt, wenn der Prozessortakt zu hoch, instabil oder
die Versorgungsspannung ungenügend bzw. nicht ausreichend gesiebt ist.

Autor: Martin G. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!

Kennt ihr noch das Problem vom 2313? Ohne Brownout? Schreib' gerade
dann, wenn die Versorgung zusammenbricht, und dein Byte an Adr, 0 wird
zerstört. Manchal ist auch in einer Brownoutphase normaler Code
irgendwie falsch ausgeführt worden, das konnte dann auch mehrere Zellen
betreffen. Wenn ich das EEPROM nur für Kalibrierwerte verwendet habe,
ohne eine Schreibroutine im Programm zu haben, hatte ich (bei meinen
privaten Prjekten) keine Probleme.

Soviel ich weiß, kippen Bits von selbst vorwiegend in warmer Umgebung
(so 115°C aufwärts)

servus,
Martin

Autor: crazy horse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
bei den classic-avr war der interne EEPROM ohne Korrekturmassnahmen
überhaupt nicht zu gebrauchen, dass ging durch die ganze Reihe. Selbst
mit ext. watchdog/brownoutdetector hatte ich massive Probleme,
namentlich
AT90S1200
AT90S2313
AT90S8515
bei den anderen weiss ich es nicht aus eigener Erfahrung, wird aber
auch nicht anders sein.
Lustig ist eines meiner ganz alten Projekte, darin werkelt ein 1200er
als Anzeigentreiber. Mangels LPM wurde die Siebensegment-Tabelle im
EEPROM abgelegt, die kamen im Lauf der Zeit fast alle zurück. z.T.
recht interessante Displayinhalte...
Temperatur als Auslöser kann ich ausschliessen. Kann gut sein, dass das
das Problem verstärkt, es ist aber keinesfalls der einzige Grund.
Bei den Tinys/Megas sieht das alles viel besser aus, so ganz richtiges
Vertrauen habe ich aber nicht mehr.
By the way: wer Probleme mit Schreibzyklenzahl/Schreibzeit hat:
FRAM von Ramtron, setze ich inzwischen nur noch ein. Kosten nicht viel
mehr als normale EEPROMs, aus Gründen der Lagervereinfachung nehme ich
nur noch die. Bis jetzt 100% Erfolg :-)

Autor: Mathias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ crazy horse: setzt du dein Fram auch im industriellen Umfeld ein?

Autor: Mathias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
" Kosten nicht vielmehr als normale EEPROMs... "

wieviel kostet denn ungefähr ein FM24CL04 (4kbit, I2C) bei 1000 Stück?

der Stückpreis eines I2C EEPROMS von ATMEL (1kB) liegt ja bei etwa
30Cent ( bei einer Abnahme von 1000 Stück )

Autor: Manfred Schäfer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Mathias

wie hast du das umkippen der Bits festgestellt?
Hast du nach dem Schreiben einen Lesevorgang durchgeführt?
Kannst du andere Einflüsse, wie z. B. Störung durch Interrupt,
ausschließen?

Gruß

Manfred

Autor: Marcus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ crazy horse:

kannst du mir evtl tips geben für die sicherungsmechanismen für ein I2C
EEPROM?!
bin auch gerade an einem projekt, bei dem daten "sicher" über lange
zeit in ein EEPROM über I2C bus geschrieben werden müssen.
programmieren tu ich in C und nutze einen M16C6N4 bzw. einen M32C85 von
Renesas. leider gibt es nur für den M16 ein I2C beispiel, aber dieses
auch nur ohne sicherungsmechanismen.
wie und welche implementiert man da am besten?
da ich nicht sehr fit bin beim programmieren, sollte es auch recht
einfach zu realisieren sein...
habe auch schon über reduntante speicherverfahren nachgedacht, aber da
bei µC eine integrierte CRC berechnung haben, wäre dies ja evtl auch
angebracht, oder?!

mfg

Autor: Rolf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
CRC bringt nix - da kann der Mikrocontroller bestenfalls den Dienst
verweigern wenn er Fehler findet, aber nix reparieren. Deshalb ist CRC
auch bei der Datenübertragung wenig sinnvoll.
Als Sicherungsmassnahme braucht man Fehlerkorrektur, also ECC.
Das einfachste ist die 2-von-3-Funktion, also a v b ^ b v c ^ a v c.
Damit werden alle ein-Bit-Fehler autmatisch korrigiert und auch
detektiert (ausser man ignoriert die Fehler), aber man benötigt den
dreifachen Platz. Dafür darf hierbei auch etwas fehlen; d. h. wenn c
fehlt und in a und b kein Fehler ist, tritt kein Fehler auf. Das ist
hilfreich, wenn bei der Datenübertragung einzelne Bytes verloren gehen.

Autor: Marcus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo Rolf,
danke erstmal. hast recht. aber ich werd wohl evtl verschiedene
mechanismen für unterschiedliche datentypen verwenden (müssen).
wichtige sicherheitsrelevante daten werden dann denke ich mit dem
redundanten 2von3 verfahren gemacht.
aber gibt es denn nicht auch fehlerkorrigierende CRC verfahren?
hat jemand schon mal etwas von dem Reed-Solomon verfahren gehört oder
einem ähnlichen, welches auf block-codes beruht und auch korrigieren
kann?!
da wird denke ich dann aber die programmieren ungleich
schwerer/aufwendiger werden, oder?!

mfg

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
CRC ist nicht sinnlos, sondern in Verbindung mit anderen Verfahren
ungemein hilfreich. Mankannst beispielsweise auch das RAID-5 Verfahren
verwenden. Beispiel: EEPROM in N Blöcke aufteilen, CRC-16 oder CRC-32
in jeden Block rein, XOR der Blöcke 1..(N-1) als Block N speichern.

Autor: Rolf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja, auf CDs/DVDs und Festplatten sowie in ECC-RAM wird nie CRC
verwendet und das Partitätsbit ist da auch längst ausgestorben, weil
damit bestenfalls abgeschaltet werden kann - mit dem ECC werden aber
alle 1-Bit-Fehler korrigiert und meist sind 2-Bit-Fehler zumindest
erkennbar.
Deshalb verwende ich im PC ECC-RAM, denn bevor das wirklich ausfällt,
wird man schon durch entsprechende Logfile-Einträge gewarnt.

Autor: Rolf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nachtrag zur 2-von-3-Funktion als C-Makro:

// 2-of-3-function
#   define mc_2of3(a, b, c) ( ((a)&(b)) | ((a)&(c)) | ((b)&(c)) )

In Hardware gegossen nennt heisst sowas Triple Modular Redundancy.

Autor: Marcus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
cool, danke...

hat noch jemand irgendwelche c programmtechnischen anleitungen für
sicherungsmechanismen verschiedenster art?

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.