Stabilität und Zuverlässigkeit

Hard- und Softwareaspekte für optimierte Embedded Systeme - Teil 2

Seite: 2/3

Firmen zum Thema

Weshalb sind nun ECC-Speicher so wichtig für die Systemzuverlässigkeit? Ein Single- Bit-Fehler wird im Speicher, wodurch auch immer, verursacht. Mit ECC-Speicher wird eine Meldung ausgegeben und die Daten werden korrigiert zurückgeschrieben, alles gut! Ohne ECC-Speicher sind im besten Fall die Daten nur ein wenig falsch, im schlimmsten Fall ist das im Betriebssystem-Code passiert und ein Sprung geht nicht +100 Byte nach vorne, sondern -100 rückwärts.

NAND (SLC, MLC, TLC) Flashes und deren Sicherung gegen Datenverlust

Richtig gruselig wird es jedoch bei den NAND-Flash-Speichern, die heute in allen gängigen Speicherkarten wie USB-Stick, CF, SD, µSD oder SSDs enthalten sind, vorallem wenn sie in zuverlässigen embedded Systemen zum Einsatz kommen sollen. Normalerweise würde man annehmen: 1 Speicherzelle = 1 Bit. Das stimmt grade mal bei den SLC-Flash-Bausteinen. SLC = Single Level Cells, MLC = Multi Level Cells, TLC = Three Level Cells. Besonders kritisch sind die MLC- und TLC-Technologien. Bei MLC (Schwarze Magie) werden pro Zelle 2 Bit gespeichert, also der Ladungsfüllstand 0, 0.33, 0.66 und 1 in der Zelle. Bei TLC (Alien Technologie) sind es sogar 3 Bit. Die Zelle wird also mit 8 unterschiedlichen Zuständen geladen (kurz beschreiben mit welchen). Man kann sich vorstellen, was innerhalb der Chips für ein Aufwand getrieben werden muss, um diese minimalen Ladungsunterschiede noch voneinander unterscheiden zu können. Bereits das Laden der Zellen entspricht einer Komplexität, als wollte man aus 20m Entfernung in ein Glas exakt 80ml Wasser eingießen.

Um die Daten korrekt zu halten wird der ECC in den OutOfBand (OOB) Daten gespeichert, was ein zusätzlicher Datenbereich zu den eigentlichen Daten ist (16Byte OOB / 512Byte Nutzdaten). Bei SLC werden typischerweise 3 Byte pro 512 Byte für den ECC genutzt, bei MLC und TLC wird fast der gesamte 16 Byte Bereich hierzu verwendet (auch Sinn). Die meisten NAND-Flash-Controller auf den SoCs benutzen die 3 Byte, um eine 1 Bit Error Correction per Hardware zu erzeugen. Werden mehr ECC-Bits benötigt, dann muss das in der Treiber-Software des Betriebssystems (von was) gelöst werden. Da die Zellen nur eine gewisse Anzahl an Schreib-Lösch-Zyklen vertragen (SLC ~100.000, MLC ~10.000, TLC ~ 3 - 5.000), müssen die Daten mit dem Wear-Leveling-Verfahren (kurze Erklärung) gleichmäßig auf die NAND Blöcke verteilt werden. Diese Arbeit wird bei SD, µSD, CF, USB-Stick und SSDs in dem eingebauten Flash-Controller geleistet. Bei eingelöteten NAND-Flashes organisiert das ein entsprechendes Filesystem wie UBIFS, JFFS2 oder YAFFS2.

Bereits vor einigen Jahren haben die NAND-Flashes eine Speicherdichte pro mm² erreicht, bei denen nach einigen Monaten einzelne Bits von selbst kippen (Zustandsänderung von 0 auf 1 oder umgekehrt) und das sogar in Sektoren die täglich nur 1-2-mal beim Booten gelesen werden oder gar nicht mit Strom versorgt werden (Gerät im Lager). Nach intensivem Nachfragen bei den Herstellern bekommt man irgendwann mal die Auskunft, dass das im Erwartungsbereich liegt. Und das für den Einsatz im industriellen Umfeld! In Datenblättern ist so etwas nirgends zu finden. In unserer täglichen Entwicklungspraxis ist uns das dadurch aufgefallen, dass ein NAND-Flash nach 12 Monaten plötzlich ein gespeichertes Linux nicht mehr lesen konnte, da in einem 512 Byte Sektor 2 Bits umgekippt waren, die dann nicht mehr mit dem 1-Bit-ECC korrigiert werden konnten. Abhilfe kann hier schaffen, regelmäßig (alle 1-2 Monate) einmal das gesamte NAND-Flash zu lesen und dabei den Fehler-Status vom NAND-Flash-Controller zu überprüfen. Meldet der Controller, dass er ein Bit korrigiert hat, kann man diesen Sektor einfach überschreiben und neu überprüfen. Wenn man diese Information vom Controller nicht bekommen kann, dann hilft nur ein regelmäßiges Scrubbing, bei dem die Sektoren gelesen und wieder überschrieben werden. Das sollten die externen Flash-Speicher-Medien idealerweise selbstständig machen. Nur, wie macht das z.B. eine SD-Karte, die als Backup bereits seit 3 Jahren im Schrank liegt?

Eine befreundete Firma hat in diesem Zusammenhang herausgefunden, dass z.B.: neuere SanDisk CF Karten (>= 2GB) scheinbar aus Geschwindigkeitsgründen das Wear-Leveling nicht mehr über den gesamten Bereich, sondern nur über den für den FAT32 benötigten Bereich durchführt, wie er typischerweise in SD-Cards für Kameras benutzt wird. Somit sind andere Filesysteme wie EXT2/3/4, OS-9, QNX u.a.(?), die nicht in dem Wear-Leveling Bereich der CF Karte angelegt sind, tödlich für den sicheren Betrieb, denn sie verweigern nach ein paar tausend Zugriffen die Funktion. In unseren Marktuntersuchungen fanden sich nur wenige CF-Karten als industrietauglich, die mit SLC-Technologie und Wear-Leveling über den gesamten Bereich arbeiten. Vom Gebrauch von MLC- oder TLC-Technologien wird für den industriellen Einsatz deshalb ganz abgeraten. Wie das aktuell bei SD-Karten aussieht… keine Idee!

(ID:44521237)