|
Anzeige
|
Flash löschen - was geht wann kaputt
Gast
#1031675
Hallo.. Simple Frage: Wenn Flash ich lösche - gehen die Bits auch kaputt (bzw treten Abnutzungserscheinungen auf), wenn das bit schon vorher '1' ist? Theoretisch ist dann ja kein Potentialunterschied und die Elektronen haben keinen Grund da rein zu tuneln.. somit belibt der Isolator ja heile... (?) ODER? MFG
Gast
#1031676
– Write/Erase Cycles: 10,000 Flash/100,000 EEPROM
Gast
#1031772
..ich dachte es sei immer andersrum. Was ich mich immernoch frage: Diese Angaben hin oder her. Wenn ich 100k mal eine Page lösche.. ist die dann kaputt? Ich kann verstehen, dass es kaputt geht, wenn ich 100k mal lösche und dann alles mit Nullen beschreibe und dann wieder lösche... aber ungeschriebene Bits... nutzen die sich denn wirklich ab?? Nein ist sie nicht. Flash hält je nach Technologie 10.000 bis 1.000.000 Schreib bzw. Löschzyklen aus. Das Dumme ist halt nur, dass man immer nur eine ganze Page bzw. Block. Das ist eine Mindestangabe vom Hersteller. Wir haben in der Firma einige Flash-Speicher die schon mehr als 100.000 mal beschrieben wurden. Sie werden nur mit der Zeit langsamer und irgendwann dann geben sie den Geist auf. Bei c't hatten die mal einen USB Stick über 16 Millionen mal beschrieben und her hat keinerlei Ausfallerscheinungen gezeigt. Wenn ein Hersteller schon 1 Mio Schreibzyklen GARANTIERT, dann muss er verdammt viel Spielraum übrig lassen, damit diese Garantie auch wirklich eingehalten werden kann. Bei SSD dürfte das etwas anders aussehen, weil die mehr Logik drin haben. Dort wird gespeicher wie oft jede Page gelöscht wurde, und sobald eine gewisse Anzahl erreicht wurde (z.B. 1 Mio) wird sie rausgenommen und z.B. durch eine zusätzliche Reserve-Page ersetzt. Wenn ein Flash-Block gelöscht wird, dann ist er meist auf High (also alle Bits 1 => 0xFF). Wenn 0xFF geschrieben wird passiert auch nichts mit dem Speicher. Wenn du 0xAA reinschreibst sind die hälfte der Bits gesetzt worden, danach kannst du auf die gleiche Zelle OHNE sie zu löschen noch auf 0x88 schreiben, weil du dann einfach nur zwei weitere Bits auf Null gesetzt hast.
Gast
#1031838
Hi >Wenn du 0xAA reinschreibst sind die hälfte der Bits >gesetzt worden, danach kannst du auf die gleiche Zelle OHNE sie zu >löschen noch auf 0x88 schreiben, weil du dann einfach nur zwei weitere >Bits auf Null gesetzt hast. Nö. Da gibt es noch 14 andere möglichkeiten. >Wenn ich 100k mal eine Page lösche.. ist die dann kaputt? Wird dein Yoghurt am Mindesthaltbarkeitsdatum schlagartig schlecht? MfG Spess @ DerAlbi (Gast) >..ich dachte es sei immer andersrum. Denkste, siehe Speicher. >aber ungeschriebene Bits... nutzen die sich denn wirklich ab?? Hmmm, keine Ahnung. Wahrscheinlich nicht. MFG Falk
Gast
#1031863
moin usb speicher stiks setzen zwar auf flash bausteine, nur verhalten die sich nicht so. Da sitzt noch ein kontroller davor der unter anderem Bad sektor detection macht. Sprich kaputte sektoren durch reserve sektoren ersetzt. weiter wird wareleveling betrieben. das geht statisch als auch dynamisch. Aufgabe ist es die dauernden schreibzugriffe auf z.B. die Fat gleichmässig über alle sektoren des flash bausteins zu verteilen. es ist prinzipiell ein mapping von der sektoradressierung so wie sie der PC kennt auf die des Flash bausteins. dummerweise sind immer mehrere pc sektoren (512Byte) in einer flash zelle( z.B. 64KB) Dies kann nicht ohne zusätzliche sektoren funktionieren, da wie bereits erwähnt, eine Zelle immer nur komplett gelöscht werden kann. somit den sektor zu aktualliserenden sektor in eine neue zelle speichern, und den rest copieren. die alte zelle als gelöscht markieren und bei bedarf löschen. Spart ggf sogar zeit. Dynamisch wird so ein system dann, wenn es erkennt, welche zellen wie oft überschrieben wurden, und diese dann ggf gegeneinander austauscht. z.B. wieder die FAT. wird bei jedem schreibvorgang aktuallisiert. Teile des OS werden nur bei einem System Update überschrieben. weiso den flash sektor mit diesen daten nicht mit denen der fat austauschen? einen noch unverbrauchten fur die sich schnell ändernde FAT und einen altersschwachen, für das sich langsam ändernde OS. gruss @ Termite (Gast) >weiter wird wareleveling betrieben. das geht statisch als auch wearleveling, wie Abnutzung. >sektoren (512Byte) in einer flash zelle( z.B. 64KB) Dies kann nicht ohne Das sind keine Zellen, das sind Pages, sprich Seiten. MfG Falk
Gast
#1031998
Leider ist der Thread bissl vom Thema abgekommen: mir geht es nicht darum, wie das die Chips intern regeln und was da für eine Logik dahintersteckt. Das alles ist mir klar bzw oberflächlich bekannt. Mir geht es wirklich nur um die physikalische Abnutzung des Speichers wenn er gelöscht/geschrieben wird. Und deswegen frage ich nocheinmal eindeutig: Werden ungeschriebene Bits (also die, die noch auf 1 sind) bei einem erneuten Löschen auch beschädigt oder geschieht das nur dort, wo tatsächlich Ladungen fließen müssen. Kurz: Kann ich einen Flash beliebig oft löschen, wenn ich ihn nicht beschreibe? Oder anders kurz: kann ich ihn beliebig oft mit 0 beschreiben, wenn ich ihn nicht lösche? Es wäre sehr schön, wenn mir das jemand fundiert beantowrten könnte.. ;-) Das die Bits in Bytes, diese wiederrum in Pages und diese wiederum in Sektoren und diese wiederrum in Protection-Bereiche gehören ist hierbei unwichtig. Falk Brunner war am Thema schon am nächsten dran :-) Timmo H. hat auch nen guten satz dabei.. aber ich frage halt hier allgemein ob es wirklich stimmt: "Wenn 0xFF geschrieben wird passiert auch nichts mit dem Speicher." MFG Albi. Stimmt ja auch so. Wenn du 0xFF schreibst werden die Bits einfach nicht
angefasst.
Das was die Bits kaputt macht sind die Löschvorgänge, also der Wechsel
von 0 nach 1 (oder umgekehrt je nach Implementierung). Da bei Bits, die
noch auf 1 sind, die elekektronen nicht mehr durch die Oxidschicht des
Floating-Gates tunneln müssen, wird die Oxidschicht auch nicht weiter
beschädigt, und die Abnutzung der Oxidschicht gibt ja eben die
Lebensdauer vor.
Das ist zumindest meine Auffassung der von mir angelesenen
Informationen, eine Garantie gebe ich darauf also nicht. Ich habe noch
einige NOR-Flash zu hause. Vielleicht lasse ich die mit meinem uC
einfach mal ein paar Wochen lang nur löschen und messe dabei immer die
Zeit. Mal gucken wielange das Teil durchhält.
@spess53
>Nö. Da gibt es noch 14 andere möglichkeiten.
Das 0x88 war auch nur ein Beispiel. Das da noch 0x8A,0x2A,0x82... sind
ist mir auch klar.
Die Frage lässt sich nicht allgemeingültig beantworten, das hängt ein ganzes Stück vom Design der Flashzellen ab. So kann z.B. "Negativ geladen" als "1" oder "0" betrachtet werden, je nachdem ob normal oder invertiert ausgelesen wird. Beim NOR-Flash, wie es im Mikrocontrollern verwendet wird, sorgt der Flash-Controller dafür, dass gelöschte Zellen nicht nochmals gelöscht werden. Anderenfalls könnte es zm Over-Erase kommen und das führt an allen Bits, die an der gleichen Datenleitung hängen, falsch gelesen werden. >Wenn du 0xAA reinschreibst sind die hälfte der Bits >gesetzt worden, danach kannst du auf die gleiche Zelle OHNE sie zu >löschen noch auf 0x88 schreiben, weil du dann einfach nur zwei weitere >Bits auf Null gesetzt hast. Man sollte generell Flash-Zellen nicht mehrmals nacheinander beschreiben, ohne sie vorher gelöscht zu haben. Das geben auch die meisten Hersteller vor. Denn dabei kann zuviel Ladung auf die floating Gates gelangen, die sich beim nächsten Löschen nicht mehr sicher entfernen lässt. Wenn man es denn unbedingt machem muss (z.B. EEPROM-Simulation) sollte man Bits die schon auf "0" stehen einfach mit einer "1" überprogrammieren. Also im vorliegenden Fall anstelle mit 0x88 mit 0xdd drüber programmieren, das Resultat ist das gleiche schont aber das Bauteil. Gruß Jörg >Also im vorliegenden Fall anstelle mit 0x88 mit 0xdd drüber >programmieren, das Resultat ist das gleiche schont aber das Bautei Bis jetzt habe ich es noch nicht in Datenblättern von NOR-Speichern gesehen, habe bis jetzt aber auch nur Intel und Samsung angeguckt. Klingt auf jeden Fall interessant. Kann gut sein, dass dies in keinem Datasheet drinsteht. Das ergibt sich eher aus dem Verständnis der verwendeten Technik. Und könnte bei Devices mit Eigenintelligenz und impliziter Verifizierung problematisch sein. Bei MLC-Flash geht das sowieso nicht, aber das sind dann NAND-Typen. Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|
