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: > Welche flash filesystems gibt es denn? http://de.wikipedia.org/wiki/Liste_von_Dateisystemen#Dateisysteme_f.C3.BCr_Flash-Datentr.C3.A4ger
> 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).
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.