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
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.
jo, I2C-Eeprom. Ausserdem kann man ne Menge per Software erledigen (mehrfach speichern, Majoritätsentscheidung).
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
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.
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
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 :-)
" 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 )
@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
@ 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
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.
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
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.
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.
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.
cool, danke... hat noch jemand irgendwelche c programmtechnischen anleitungen für sicherungsmechanismen verschiedenster art?
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.