Fragen zur Fehler-Korrektur für Flash-Chips

Hallo NG,

ich hab mal ein paar Fragen zur Fehlerkorrektur und dem Bad-Sektor-Managment von NAND-Flash-Chips:

Wo wird das eigentlich erledigt? Im NAND-Flash selber oder in einem zusätzlichen Controller?

In den Datenblättern zu den NAND-Flashs von Samsung und Hynix stehen nur ein paar Anmerkungen zur Defekt-Sektor-Erkennung daher war meine bisherige Annahme das die Fehlerkorektur und das Bad-Sektor-Managment in zusätzlichen Controllern steckt.

Jetzt ist mir eine ältere c't (Heft 21 vom 01.10.2007) in die Hände gefallen und dort steht auf Seite 104 (im gelben Kasten "Lebenserwartung von Flash-Speicher") | "Hynix implementiert TrueFFS mittlerweile direkt in den Flash-Chips." Das hat mein Weltbild etwas angeknaxt. Nach etwas Recherche im Netz bin ich eigentlich wieder der Meinung das im Flach-Chip selber nur der Speicher und keine Intelligenz steckt aber ganz sicher bin ich mir da nicht.

Der Grund für meine Fragen ist der das ich vor habe einen solchen NAND-Flash-Chip direkt (über einen FPGA in den Adressraum eingeblendet) an einen Controller anzubinden damit dieser sich vom Flash seine Firmware holen kann. NOR-Flash-Chips sind dafür zu klein und zu teuer, Ein bis Zwei GByte Daten will ich darin nicht unterbringen müssen. Wenn das Bad-Sektor-Managment aber nicht im Flash-Chip steckt dann muss ich Vorkehrungen im FPGA treffen. Daher hatte ich die Idee einfach eine SD-Karte anzubinden aber diese Lösung währe im FPGA bestimmt auch nicht einfach zu lösen und währe zudem (deutlich) langsamer.

Wie könnte den ein Defekt im Flash aussehen? Bleiben dann bestimmte/einzelne Bits immer auf 0 oder 1 (je nach dem was der leere Zustand ist)? Oder lässt erst mal die Speicher-Erhaltungs-Zeit nach? Sind in so einem Flash-Sektor erst mal einzelne Bits oder gleich ganze Gruppen betroffen?

Vor kurzem hat mir ein Kollege gesagt das die Fehlerkorrektur-Mechanismen in modernen USB-Sticks oder SD-Cards nur dann ordentlich greifen wenn diese mit FAT formatiert sind. Stimmt das? Ich habe hier 2 USB-Sticks, den Einen (4 GB) mit NTFS und den Anderen (8 GB) mit EXT2 formatiert. Sind die nun vom vorzeitigem Ableben bedroht?

Grüße Erik

Reply to
Erik
Loading thread data ...

von NAND-Flash-Chips:

Bei den reinen NAND-Flash IC's (also nicht Karten oder seltener IC's mit Controller) extern.

Und zwar _unbedingt_ und zwar bitte als _echte_ Korrektur. Defekte Sektoren ausblenden reicht nicht, bei NAND können auch einzelne Bits kippen, ECC ist Pflicht, am besten eine Mehrbit-Korrektur oder z.B. Reed-Solomon.

Ein Bad-Sektor-Management braucht es zusätzlich.

BTDTNT.

leere Zustand ist)?

Es können komplette Sektoren nicht schreibbar sein, oder einzelne defekt. Möglich ist alles.

Es können definitiv nachträglich einzelne Bits umkippen.

NAND Flash ist ein sehr elegantes, aber leider kein dauerhaft stabiles Speichermedium, die Speicherzellen sind physikalisch so klein, dass man schon fast die Atome zählen kann, und die Abfrage nacheinander durch die in Serie verundeten (eben NAND) MOSFETs mit Speicher-Gate ist nicht ganz unproblematisch. Die Teile sind absolut an der Grenze der physikalischen Machbarkeit.

Deshalb nimmt man für kritischen Bootcode-Speicher etc. lieber NOR-Flash. Leider dauert bei dem der Löschvorgang deutlich länger und es hat insgesamt nicht soviele Zyklen. Aber mit dem Vorteil, dass der Speicherinhalt sehr sicher gehalten wird.

Und aus dem selben Grund rate ich davon ab, wichtige Daten nur in einem NAND Flash Speicher oder nur einmal dort zu halten.

Gruß Oliver

--
Oliver Bartels + Erding, Germany + obartels@bartels.de
http://www.bartels.de + Phone: +49-8122-9729-0 Fax: -10
Reply to
Oliver Bartels

Hallo Oliver Bartels,

Okay, mein Weltbild bleibt also erhalten. ;-)

ACK

sowieso

Darauf möchte ich eigentlich verzichten. Ich wollte die Fehlerkorrektor Vertikal (also über mehrere Sektoren) aufbauen. In einem NAND-Flash kann man doch sowieso immer nur mehrere Sektoren auf ein mal löschen, wenn der FPGA diese Sektoren beim lesen (schreiben geschiet nur per Software mit FPGA im GPIO-Mode) immer so eine Gruppe komplett einließt und dann aus jedem der 16 Sektoren (bei 32kByte Gruppen) das 0-te Byte nimmt und daraus per Reed-Solomon 8 Nutzbytes gewinnt. Die zusätzlichen Spare-Bytes in den Sektoren können eine weitere Sicherheitsebene darstellen. Dass sollte IMHO sogar mehrere Total-Ausfall-Sektoren pro Gruppe verkraften. Die halbierte Nutzkapazität ist bei den aktuellen Preisen IMHO kein so großes Problem. Bei NOR-Chips ist bei

64MByte Schluss (und braucht dafür etwa 4 mal so viele Signale und ist nur unwesentlich schneller) und ich habe mindestens 1400 bis 1700 MByte an Daten (nicht nur Code) unkomprimiert in den CPU-Adressraum einzublenden. Diese Daten sollen zur Laufzeit nicht verändert werden (extra mit WP-Jumper geschützt) daher ist die Schreibgeschwindigkeit nicht relevant. Auch ein Bad-Sektor-Mapping macht da IMHO keinen großen Sinn denn das nutzt doch nur wenn die Daten regelmäßig überschrieben werden und dadurch _neue_ Defekte entstehen. Bei einem System wo die Daten einmal programmiert werden und dann X Jahre halten sollen müßte man entwerder die Daten regelmäßig komplett auslesen und /schwächelnde/ Sektoren in Reserve-Sektoren verlagern oder eben genug Reserve-Bits für die Fehler-Korrektur einplanen damit der Verfall mit ausreichender Warscheinlichkeit (also ausreichend geringer Reklamationsquote) über den angepeilten Zeitraum ausgeglichen werden kann. Ich bevorzuge momentan die zweite Variante, schon um einen physischen Schreibschutz implementieren zu können und den Code zum beschreiben nicht ausliefern zu müssen (der End-User soll die Daten nicht zu leicht manipulieren können). Zusätzlich könnte man ein einfaches statisches Bad-Sektor-Mapping implementieren das nach dem flashen die zu schlechten Sektor-Gruppen verlegt. Das "zu schlecht" darf natürlich erst bei richtig massiven Ausfällen greifen, wo also abzusehen ist das die Fehler-Korrektur nicht die X Jahre übersteht. In den defekten Sektoren könnte man einen Zeiger hinterlegen oder am Flash-Ende eine kleine Tabelle unterbringen, mal sehen was sich einfacher implementieren lässt bzw. zuverlässiger arbeitet. Oder man programmiert den Flash-Chip vor dem auflöten und sortiert die übelsten Kandidaten gleich aus. Die entgültige Entscheidung dazu wird man wohl erst nach den ersten paar tausend Baugruppen treffen können.

Was willst Du mir damit sagen????

Ich hoffe mal das die defekten Bits einigermaßen gleichmäßg über das Silizium verteilt sind und das die bereits bei der Produktion defekten Bits durch die vertikale Fehlerkorektur abgefangen werden können. Ich schätze mal das ich so einen Flash-Chip mal selber so richtig stressen muss um zu sehen wie die Defekte aussehen.

Klingt nach gleichmäßiger Verteilung, sollte IMHO eine gute Fehler-Korrektur abfangen können, vor allem wenn reichlich Redundanz-Bits zur Verfügung stehen.

Die Frage sollte lauten ob meine USB-Sticks aufgrund der gewählten Dateisysteme, besser gesagt aufgrund der nicht ausreichend generischen Implementierung des Bad-Sektor-Mapping im Stick-Controller, nun schneller altern als wenn sie mit FAT32 formatiert währen.

Es werden immerhin Festplatten draus gemacht und die haben sich (insbesondere im industriellen Umfeld) die letzten Jahre (gerade unter den wiedrigsten Umständen) recht gut bewährt.

Backups (auf getrennten Geräten an getrennten Orten) sollte man (von wichtigen Daten) _immer_ haben.

Grüße Erik

Reply to
Erik

im industriellen Umfeld) die letzten Jahre (gerade unter den wiedrigsten Umständen) recht gut bewährt.

Es gibt aber "solche" und "solche". Wir haben das lange evaluiert und sind schließlich bei Sandisk gelandet. Die waren die Einzigen, die die geforderten Eigenschaften (wear leveling, Erkennung von Fehlern und Ausmappen selbiger) damals wirklich schriftlich zusichern konnten und auch bereit waren, ein tool zu liefern, mit dem man die Dinger als "fixed disk" konfigurieren kann. Bisher in vier Jahren noch keine Ausfälle. Wir haben auch eine Überwachungsroutine integriert, die dem Benutzer eine Warnung zukommen läßt, daß der Speicher sich der Verschelißgrenze nähert...

Absolut durchgefallen sind damals übrigens die CF-microdrives. Die taugten keinen Schuß Pulver. Hatten zunächst halt mehr Kapazität zu bieten, aber dafür sowas von fehleranfällig und empfindlich - für Industrie mehr als untauglich.

-ras

--
Ralph A. Schmid

http://www.dk5ras.de/ http://www.db0fue.de/
 Click to see the full signature
Reply to
Ralph A. Schmid, dk5ras

Am 07.07.2008, 15:53 Uhr, schrieb Ralph A. Schmid, dk5ras :

In Digitalkameras können sie anscheinend durchaus langlebig sein... mein Vater hat seit etlichen Jahren in seiner Kamera ein MicroDrive, ohne Probleme bisher.

Ansgar

--
Mails an die angegebene Adresse errichen mich - oder auch nicht. Nützliche  
Adresse gibt's bei Bedarf!
 Click to see the full signature
Reply to
Ansgar Strickerschmidt

Erik schrieb:

Hallo,

BTDT bedeutet Been There, Done That. Fragt sich was NT hier noch bedeutet.

Bye

Reply to
Uwe Hercksen

Hallo Uwe Hercksen,

BTDTNT >>>> Been there, done that, no t-shirt >>>> Kenn ich schon, lohnt nicht.

siehe

Was ich mich frage ist worauf sich das Kürzel bezieht bzw. welche Information Oliver mir damit geben will.

Grüße Erik

Reply to
Erik

Hallo Ralph A. Schmid,

Das Problem gibts immer.

^^^^^ glaub ich sofort

Was denn für ein Produkt? So ein IDE-Flash-Riegel oder CF-Karte?

^^^^^^^^^^^^^^^^^^^^^ ist selten das die Firmen sowas machen, meistens gibts nur "friss oder stirb"

Das lässt mich hoffen.

Wie bekommt die ihre Informationen? Direkt vom Controller-Chip?

Grüße Erik

Reply to
Erik

Oliver mir damit geben will.

Dass wir mit dem NAND Krempel als Native IC einigen Stress hatten.

Gruß Oliver

--
Oliver Bartels + Erding, Germany + obartels@bartels.de
http://www.bartels.de + Phone: +49-8122-9729-0 Fax: -10
Reply to
Oliver Bartels

Hallo Oliver Bartels,

Als Entwickler würde es mich ärgern wenn es "zu glatt" laufen würde. Erzähls bitte nicht meinem Chef. ;-)

Im Ernst, das es nicht ganz so einfach wird ist mir bewusst, aber man wächst ja an seinen Aufgaben.

Grüße Erik

Reply to
Erik

Unsere haben schon bei Tests auf dem Schreibtisch gesponnen...evtl. ja auch einfach nur Mist erwischt, wer weiß?!

-ras

--
Ralph A. Schmid

http://www.dk5ras.de/ http://www.db0fue.de/
 Click to see the full signature
Reply to
Ralph A. Schmid, dk5ras

Normale CF-Karten der Reihen Ultra und Extreme.

Es gab eben Zahlen, schwarz auf weiß, bezüglich Lebensdauer, Erkennung von Problemen usw.

Ich habe damit nicht direkt zu tun, aber meines Wissens wird durch ausfallende Bereiche der Datenträger kleiner (dafür sorgt eben der Controller, wenn alle Reserve-Blöcke weg sind, wird gnadenlos gestrichen :-), und das ist ja schmerzfrei erkennbar.

-ras

--
Ralph A. Schmid

http://www.dk5ras.de/ http://www.db0fue.de/
 Click to see the full signature
Reply to
Ralph A. Schmid, dk5ras

Hallo Ralph A. Schmid,

Aha, interessante Variante. aber wirklich ein unverschämter Controller, einfach so Speicher klauen ;-)

Grüße Erik

Reply to
Erik

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.