Hallo zusammen,
unter diesem Beitrag möchte ich 2 Fragen klären:
1. Ich habe einen externen Flash mit einer Größe von 128 MB. Angesteuert
wird der externe Flash von einem Microcontroller über SPI. Die Read,
Write und Erase Funktionen habe ich nun implementiert. Die Pagegröße
beträgt 2048 + 64 Control bytes.
Dabei ist mir folgendes aufgefallen:
Zunächst habe ich 2kb DWORD weise in die erste page geschrieben (1 -
512). Wenn ich diesen Wert nun byteweise auslese, dann bekomme ich die
gleichen Werte zurück. Wenn ich den ganzen Block lese, dann bekomme ich
manchmal an einer, manchmal an 2 Stellen einen falschen Wert gelesen.
Kann denn sowas auftreten?
2. Würdet ihr hier ein FAT verwenden, direkt auf den Flashspeicher
zugreifen, ein eigenes Dateisystem verwenden oder habt hier noch andere
Ideen :-)
Auf dem Flash soll eine EEPROM Simulation implementiert werden und
verschiedene Daten abgelegt werden.
FLASH: MT29F1G
Vielen Dank für eure Hilfe!
Das angegebene Flash MT29F1G ist ein NAND-Flash. Die erste Page ist
garantiert fehlerfrei, alle anderen Pages können fehlerhaft sein. Du
brauchst unbedingt ein geeignetes Flash File System mit Wear Leveling
und Fehlerkorrektur und Bad Block Management. FAT ist das schlechteste,
was Du hier nehmen kannst, weil das nichts von alledem hat.
Zu den Datenfehlern: ja, da hast Du irgendwelche Timings nicht
eingehalten.
fchk
Hallo Frank,
> Das angegebene Flash MT29F1G ist ein NAND-Flash. Die erste Page ist> garantiert fehlerfrei, alle anderen Pages können fehlerhaft sein.
Gestern habe ich die Statusbits mir nochmal genau angeschaut. Diese
werden bestimmt, wenn die page in den cache kopiert wird. Ich bin mir
100% sicher, dass ich die erste page auslese. Adresse ist halt 0 :-)
Die Statusbits sagen, das in der Page ein Fehler aufgetreten ist, der
nicht korrigiert werden kann.
> Du> brauchst unbedingt ein geeignetes Flash File System mit Wear Leveling> und Fehlerkorrektur und Bad Block Management. FAT ist das schlechteste,> was Du hier nehmen kannst, weil das nichts von alledem hat.
Welche flash filesystems gibt es denn? Warum ist die erste page 100%
fehlerfrei?
> Zu den Datenfehlern: ja, da hast Du irgendwelche Timings nicht> eingehalten.
Das Timing werde ich mir nochmal genau angucken.
Vielen Dank!
Thomas
Thomas schrieb:> Warum ist die erste page 100% fehlerfrei?
Eine Konzession an die armen Programmierer von Filesystemen, möchte ich
annehmen. Irgendwo muss man mit der Verwaltungsstruktur anfangen. Alles
andere kann dann irgendwo liegen, und wo genau steht ebendort.
> Thomas schrieb:>> Warum ist die erste page 100% fehlerfrei?> Eine Konzession an die armen Programmierer von Filesystemen, möchte ich> annehmen. Irgendwo muss man mit der Verwaltungsstruktur anfangen. Alles> andere kann dann irgendwo liegen, und wo genau steht ebendort.
Sollte das dann nicht im Datenblatt stehen? Ich konnte dies in der Spec
nicht finden...
> Thomas schrieb:>> Welche flash filesystems gibt es denn?> http://de.wikipedia.org/wiki/Liste_von_Dateisystem...
Hat jemand schon Erfahrung mit einem von diesen flash filesystems
gesammelt?
Bin für jeden Hinweis dankbar!
Gruß
Thomas
Thomas schrieb:> Sollte das dann nicht im Datenblatt stehen? Ich konnte dies in der Spec> nicht finden...
Gleich auf der Titelseite: "The first block (block address 00h) is
guaranteed to be valid without ECC (up to 1,000 PROGRAM/ERASE cycles)"
Thomas schrieb:> Hat jemand schon Erfahrung mit einem von diesen flash filesystems> gesammelt?
Fang mal bei der Aufgabenstellung an: Wozu wird das konkret benötigt?
Zufälliger/wahlfreier Schreibzugriff, wie etwa bei SSDs? Oder wird da
eher eine Art Protokollspeicher draus, mit charakteristischem
Zugriffsmuster beim Schreiben? Davon hängt ab, welche Strategie und
wieviel Aufwand sinnvoll sind.
A. K. schrieb:> Fang mal bei der Aufgabenstellung an: Wozu wird das konkret benötigt?> Zufälliger/wahlfreier Schreibzugriff, wie etwa bei SSDs? Oder wird da> eher eine Art Protokollspeicher draus, mit charakteristischem> Zugriffsmuster beim Schreiben? Davon hängt ab, welche Strategie und> wieviel Aufwand sinnvoll sind.
Naja ich bin mir hier nicht sicher, was alles möglich ist. Bei einer
erheblich kleineren Flash Variante, schreibe ich direkt in die page
Adressen ohne jegliche Fehlerprüfung. Über 2 pages, die man unabhängig
löschen kann, habe ich eine eeprom Simulation realisiert. In anderen
Bereichen werden beispielsweise Logdaten im Binärformat abgelegt.
A. K. schrieb:> Thomas schrieb:>> Sollte das dann nicht im Datenblatt stehen? Ich konnte dies in der Spec>> nicht finden...>> Gleich auf der Titelseite: "The first block (block address 00h) is> guaranteed to be valid without ECC (up to 1,000 PROGRAM/ERASE cycles)
Du hast recht. Bei der SPI Variante, die ich hier verwende, ist dieser
Text nicht zu finden.
http://www.datasheetarchive.com/indexer.php?file=DSAAQ0021072.pdf&dir=Datasheets-AQ2&keywords=MT29F1G01AAADD&database=user-highscore#
Thomas schrieb:> Naja ich bin mir hier nicht sicher, was alles möglich ist. Bei einer> erheblich kleineren Flash Variante, schreibe ich direkt in die page> Adressen ohne jegliche Fehlerprüfung. Über 2 pages, die man unabhängig> löschen kann, habe ich eine eeprom Simulation realisiert. In anderen> Bereichen werden beispielsweise Logdaten im Binärformat abgelegt.
Das war NOR-Flash, da ging das noch. Bei NOR Flash brauchst Du noch
nicht mit Defekten zu rechnen. Bei NAND geht es nicht ohne
Defektmanagement und ohne Wear Leveling, weil Du sehr viel weniger
Schreibzyklen hast (Zehnerpotenzen weniger).
Du kannst ja mal einen Blick in den Linux-Kernel werfen, was die für
Aufwand bei der Fehlerkorrektur etc treiben und Dir dann überlegen, ob
Du tatsächlich NAND-Flash verwenden willst oder nicht doch auf eMMC
umschwenken möchtest.
http://en.wikipedia.org/wiki/YAFFS
fchk
Frank K. schrieb:> Das war NOR-Flash, da ging das noch. Bei NOR Flash brauchst Du noch> nicht mit Defekten zu rechnen. Bei NAND geht es nicht ohne> Defektmanagement und ohne Wear Leveling, weil Du sehr viel weniger> Schreibzyklen hast (Zehnerpotenzen weniger).
Halb so wild, dieses Teil verwendet SLC Speicherzellen. Die sind mit
ihren üblicherweise 100000 Schreibzyklen in der Region mancher
Controller-interner EEPROMs und folglich nicht ganz so kritisch.
Wenn man da keine SSD mit völlig unkontrolliertem Zugriff draus macht,
sondern charakteristische Schreibmuster hat, dann kann man sich das
Leben wesentlich leichter machen und sich den Umweg über ein komplexes
Filesystem und/oder transparentes Wear Levelling ersparen. ECC
allerdings ist wohl unverzichtbar.
Im oben verlinkte Datasheet steht über die Anzahl Zyklen allerdings
exakt nichts drin. Nur ist es schon etwas angestaubt ("advance
information" von 2010), da sollte beim Hersteller mittlerweile
aktuellere Information zu finden sein.
A. K. schrieb:> Halb so wild, dieses Teil verwendet SLC Speicherzellen. Die sind mit> ihren üblicherweise 100000 Schreibzyklen in der Region mancher> Controller-interner EEPROMs und folglich nicht ganz so kritisch.
Ok ich habe mir jetzt nochmal das neueste Datenblatt vom Hersteller
gezogen. Die Erase Cycles werden mit 100.000 angegeben.
Zur Adresse 0 steht auch hier nichts.
A. K. schrieb:> ECC allerdings ist wohl unverzichtbar.
ECC bringt der flash Baustein schon mit. Also werde ich dies auf
Controller Seite nicht nochmal implementieren.
A. K. schrieb:> Wenn man da keine SSD mit völlig unkontrolliertem Zugriff draus macht,> sondern charakteristische Schreibmuster hat, dann kann man sich das> Leben wesentlich leichter machen und sich den Umweg über ein komplexes> Filesystem und/oder transparentes Wear Levelling ersparen.
Wie könnte den ein "einfaches Filesystem" aussehen? Hast du da einen
Vorschlag?
Gibt es bereits Implementierungen wo ich mir das mal angucken kann?
Ich habe folgende Idee:
eine indirekte Adressierung machen, die wie folgt aussieht:
angesprochene Adresse: Adresse im flash:
0 1023
1 1022
2 1021
3 1019
... ...
flash Adresse 1020 weißt im obigen Beispiel einen Fehler auf.
An die erste fehlerfreie page im flash würde ich diese Informationen
reinschreiben. Bei der Initialisierung muss nun der Controller die erste
fehlerfreie Adresse im flash suchen. Dort steht die obige Tabelle.
Was haltet ihr von der Idee?
Vielen Dank!
Thomas schrieb:> Ich habe folgende Idee:> eine indirekte Adressierung machen, die wie folgt aussieht:>> angesprochene Adresse: Adresse im flash:> 0 1023> 1 1022> 2 1021> 3 1019> ... ...>> flash Adresse 1020 weißt im obigen Beispiel einen Fehler auf.>> An die erste fehlerfreie page im flash würde ich diese Informationen> reinschreiben. Bei der Initialisierung muss nun der Controller die erste> fehlerfreie Adresse im flash suchen. Dort steht die obige Tabelle.>> Was haltet ihr von der Idee?
Und was ist, wenn diese Page im Betrieb defekt wird? Damit musst Du
rechnen, das kann passieren. Du kannst auch nicht einzelne Pages
löschen, sondern nur Blocks, und zu einer Page etwas dazuschreiben
("überbrennen") ist auch nur in engen Grenzen erlaubt.
Wie gesagt, schau Dir die Sachen im Linux-Kernel an.
fchk
Thomas schrieb:> Wie könnte den ein "einfaches Filesystem" aussehen? Hast du da einen> Vorschlag?
Entweder du verwendest ein fertiges Universalfilesysten für Flash, oder
entwickelst ein an den eingeschränkten Anforderungen orientiertes
Verfahren. Letzteres setzt allerdings voraus, dass du dir über die
konkreten Anforderungen im Klaren bist, d.h. wie Zugriffsmuster,
Schreibmenge usw. aussehen. Wenn du keine Ahnung von den Anforderungen
hast, dann ist Pos 1 sinnvoller.
Oder verwendest gleich Linux mit yaffs&co. Oder machst es wie die
meisten Leute unterhalb der Massenfertigung und verwendest eine
SD-Karte.
Jedenfalls kann ich ohne Kenntnis der Anforderungen auch keinen Ideen
entwickeln.
Frank K. schrieb:> Und was ist, wenn diese Page im Betrieb defekt wird? Damit musst Du> rechnen, das kann passieren. Du kannst auch nicht einzelne Pages> löschen, sondern nur Blocks, und zu einer Page etwas dazuschreiben> ("überbrennen") ist auch nur in engen Grenzen erlaubt.>> Wie gesagt, schau Dir die Sachen im Linux-Kernel an.
In welchem Ordner kann ich die Implementierung finden? Der Linux Kernel
ist groß. Den Kernel selber habe ich mir bereits runtergeladen.
Eignet sich denn die Implementierungen im Linux Kernel für embedded
Anwendungen überhaupt?
Vielen Dank!
Thomas schrieb:> Frank K. schrieb:>> Und was ist, wenn diese Page im Betrieb defekt wird? Damit musst Du>> rechnen, das kann passieren. Du kannst auch nicht einzelne Pages>> löschen, sondern nur Blocks, und zu einer Page etwas dazuschreiben>> ("überbrennen") ist auch nur in engen Grenzen erlaubt.>>>> Wie gesagt, schau Dir die Sachen im Linux-Kernel an.>> In welchem Ordner kann ich die Implementierung finden? Der Linux Kernel> ist groß. Den Kernel selber habe ich mir bereits runtergeladen.
Schau mal hier:
http://www.yaffs.net/documents/yaffs-direct-interface
Da wird das ganze erklärt, und von dort lädtst Du Dir das besser auch
direkt runter.
Zu Linux: in ./fs sind die ganzen Filesystemtreiber, hier wäre
vielleicht jffs2 zum Anschauen interessant. Linux verwendet
MemoryTranslationDriver, die in ./drivers/mtd zu finden sind, und die
die Flash-Ansteuerung abstrahieren.
Ich würde eher das yaffs2 von yaffs.net nehmen - das musst Du nicht erst
rausoperieren.
Oder eben eMMC Speicher nehmen, der macht dieses ganze Zeugs selber. Und
ist herstellerunabhängig genormt, d.h. da bekommst Du auch noch in zwei
Jahren kompatible Bausteine.
fchk
Ich habe mir das yaffs mal angeschaut:
55kB Code
4 kB RAM Verbrauch (http://www.yaffs.net/yaffs1-memory-footprint)
Zum yaffs2 konnte ich leider keine solche Details finden.
Vor allem der Codeverbrauch scheint mir für eine embedded Anwendung ein
wenig viel... Man kann diesen zwar verringern, aber ...
A. K. schrieb:> Jedenfalls kann ich ohne Kenntnis der Anforderungen auch keinen Ideen> entwickeln.
eeprom simulation auf externen flash (Größe 1 kB)
Ablage von verschiedenen Logdaten auf dem Flash. Diese werden nach
überschreiten einer Maximalzeit wieder überschrieben (Wochen, Monate,
Jahre).
