Hallo allerseits ich möchte mit dem FSMC des STM32F407 einen NAND-Flash vom Typ S34ML04G100TFI000 ansteuern. Die Kommunikation mit dem Flash ansich funktioniert, denn ID auslesen etc. ist möglich. Ich bin aber nicht sicher, wie das jetzt mit dem Wear Leveling etc. funktionieren soll. Zuerst habe ich gedacht dass das der NAND Controller des STM macht. Das ist aber natürlich nicht so, offensichtlich muss man das von Hand machen (was bietet dann der NAND-Controller für einen Vorteil?). Was ich auch nicht verstehe: wenn ich eine einzelne Page löschen möchte (Was ich ja muss, wenn da neue Daten rein sollen) dann muss ich bei dem betreffenden Flash-Chip offenbar den ganzen Block à 132 KB löschen. Was mache ich mit den Daten, die ich nicht löschen will? ich kann ja dann unmöglich 132 KB Daten im RAM sichern, den Block löschen und dann alles, was ich nicht löschen wollte, wieder zurück schreiben. Das ist mal meine erste Frage. Wie das gehen soll. Dann das zweite interessante Problem: man muss ja ein Wear Leveling implementieren. Wenn ich beim Schrreiben von Daten einen Bitfehler feststelle, dann mus man ja den betreffenden Block als defekt markieren und soll diesen nicht mehr benutzen und die Daten dann woanders speichern. Nur, wie soll man sich merken, dass die Daten jetzt woanders liegen? mit der Zeit wird ja das alles total über den ganzen Memory-Bereich verstreut.
Tobias P. schrieb: > Hallo allerseits > > ich möchte mit dem FSMC des STM32F407 einen NAND-Flash vom Typ > S34ML04G100TFI000 ansteuern. > > Die Kommunikation mit dem Flash ansich funktioniert, denn ID auslesen > etc. ist möglich. Ich bin aber nicht sicher, wie das jetzt mit dem Wear > Leveling etc. funktionieren soll. Zuerst habe ich gedacht dass das der > NAND Controller des STM macht. Das ist aber natürlich nicht so, > offensichtlich muss man das von Hand machen (was bietet dann der > NAND-Controller für einen Vorteil?). Der NAND-Controller nimmt dir das Pinwackeln ab. Du gibst die Zieladresse und die Daten an, den Rest erledigt der Controller. > > Was ich auch nicht verstehe: wenn ich eine einzelne Page löschen möchte > (Was ich ja muss, wenn da neue Daten rein sollen) dann muss ich bei dem > betreffenden Flash-Chip offenbar den ganzen Block à 132 KB löschen. Was > mache ich mit den Daten, die ich nicht löschen will? ich kann ja dann > unmöglich 132 KB Daten im RAM sichern, den Block löschen und dann alles, > was ich nicht löschen wollte, wieder zurück schreiben. Das ist mal meine > erste Frage. Wie das gehen soll. Hier hilft dir Wear Leveling. Den Block in einen anderen Block kopieren, ohne die gelöschten Daten. Danach den ersten Block als gelöscht markieren. > > Dann das zweite interessante Problem: man muss ja ein Wear Leveling > implementieren. Wenn ich beim Schrreiben von Daten einen Bitfehler > feststelle, dann mus man ja den betreffenden Block als defekt markieren > und soll diesen nicht mehr benutzen und die Daten dann woanders > speichern. Nur, wie soll man sich merken, dass die Daten jetzt woanders > liegen? mit der Zeit wird ja das alles total über den ganzen > Memory-Bereich verstreut. Du brauchst eine Zuordnungstabelle, in der deine logischen Blöcke (die gedachte Reihenfolge der Daten) mit den tatsächlichen Blöcken des NAND assoziiert werden. In dieser Zuordnungstabelle hinterlegst du auch Informationen wie Blockdefekte oder gelöschte Blöcke. Dazu benötigst du eben je nach Anzahl der Blöcke ein Array. Der Index n des Arrays stellt deinen logischen Block dar, im zugehörigen Datenfeld Array[n] steht die tatsächliche Adresse des Blockes im Flash. Zusätzlich bspw. -1 für einen defekten Block, -2 für einen gelöschten, 0 entsprechend für unbenutzte Blöcke.
Hi Frank, kann ich das Wear Leveling genau "so einfach" implementieren, wie du das beschrieben hast, oder muss man da noch weiteres beachten? Die Zuordnungstabelle der Blöcke und tatsächlichen Daten, darf diese fix im nullten Block stehen? weil diese überschreibt man ja auch immer wieder, weil sich die Zuordnung ja laufend ändert, während man Daten aus dem Flash löscht bzw. neu schreibt. Damit ändert dann auch die Zuordnungstabelle laufend, oder?
Die Zuordnungstabelle solltest du sinnvollerweise in einem anderen nicht-flüchtigen Speicher ablegen. Hier empfiehlt sich ein kleiner FRAM. Da die Tabelle mit jedem Schreibvorgang aktualisiert wird, würdest du ansonsten den Flash sehr schnell zerstören. Was man noch überlegen kann, ist eine Implementation von Static Wear Leveling. Dabei gibt es für jeden Block zusätzlich einen Counter, der zählt, wie oft der Block gelöscht wurde. Diese Counter werden beim Schreiben zusätzlich ausgewertet, Daten werden immer in den Block geschrieben, der die wenigsten Löschzyklen hat. Dazu müssen unter Umständen die Daten in diesem Block in einen anderen Block verschoben werden. Damit verhindert man, dass selten benutzte Blöcke mit 1-2 Löschzyklen funktionsfähig bleiben, im Gegenzug aber andere Blöcke schon defekt sind, weil dort viele Löschzyklen nötig waren. Man erreicht quasi eine gleichmäßige Abnutzung des Flash. Kleiner Hinweis, falls du ein Filesystem mit USB-Massenspeicher implementieren willst: Es empfiehlt sich, die FAT auch in dem FRAM abzulegen, da diese Daten unter Umständen schon beim einfachen Zugriff aktualisiert werden.
@ Tobias Plüss (hubertus) >kann ich das Wear Leveling genau "so einfach" implementieren, wie du das >beschrieben hast, oder muss man da noch weiteres beachten? "so einfach" sind die wenigsten Dinge im leben, auch Wear leveling ;-) >Die Zuordnungstabelle der Blöcke und tatsächlichen Daten, darf diese fix >im nullten Block stehen? weil diese überschreibt man ja auch immer >wieder, weil sich die Zuordnung ja laufend ändert, während man Daten aus >dem Flash löscht bzw. neu schreibt. Damit ändert dann auch die >Zuordnungstabelle laufend, oder? Eben, das ist eines der vielen Probleme beim Wear Leveling. Hinter all den Algorithmen für USB-Sticks, SD Karten und SSDs steckt verdammt viel Know How, das man als Einzelner am sinnvollsten als fertiges Gesamtpaket nutzt und nicht neu erfindet. Für Flash gibt es JFFS & Co, das sollte man nutzen. https://en.wikipedia.org/wiki/Flash_file_system Bei meinem letzten Projekt habe ich auch ein sehr einfaches Wear Leveling für einen seriellen Flash gebraucht. Dort hatte ich aber den Riesenvorteil, dass keine wahlfreien Schreibzugriffe erfolgten, sondern nur sequentielle Blockzugriffe. Die Daten waren Pakete zu je 256 Bytes, davon wurde je 2 in eine Page gepackt. Der Trick war einfach. Ich habe im Flash einen umlaufenden Ringpuffer aufgebaut, d.h. die Daten wurden immer fortlaufend in aufsteigende Pages geschrieben. Der Pagecounter ist beim Maximum auf Null übergelaufen, ähnlich wie ein FIFO. Jeder Datenblock bekam eine fortlaufende 32 Bit Seriennummer. Daran konnnte man nach einem Reset die aktuellen Daten und Adressen wieder rekonstruieren. Auf diese Weise wird der gesamte Flash absolut gleichmäßig beschrieben und hält für die Anwendung praktisch ewig ( 2e9 Schreibzugriffe, verteilt auf 8192 Pages, macht ~244.000 Schreibzugriffe/Page.
Hallo Falk, ja, das mit "so einfach" war nicht ganz ernst gemeint :-) Ich möchte gern versuchen, das selber zu implementieren. Meiner Meinung nach sollte das möglich sein. Ich möchte einen "Flash Translation Layer" bauen, damit ich mit FATFS von Chan einige Files auf dem NAND verwalten kann. Ich habe mir folgendes überlegt. Als erstes muss man beim Start die ganzen Blöcke des NANDs durch gehen und schauen, ob sie kaputt sind. Wenn ja, dann dies in einer Tabelle vermerken. Jetzt möchte ich gerne, dass man den NAND mit 512 Bytes grossen Sektoren ansprechen kann. Das Lesen sollte einfach sein; man rechnet die Sektornummer in eine Block- und Page-Nummer um, liest dann die Page und kopiert den gewünschten Sektor sich heraus. Soweit so gut. Beim Schreiben wird es etwas kniffliger: man müsste zuerst die Page, in die man schreiben will, lesen, dann den gewünschten Teil modifizieren, und die so resultierenden Daten dann in eine neue, bisher unbenutzte Page schreiben. Wenn der Schreibvorgang erfolgreich ist, dann vermerkt man die Adresse, wo die neuen Daten liegen, in der Zuordnungstabelle. Wenn der Schreibvorgang fehlschlug, dann muss man den entsprechenden Block in der Bad Block Tabelle vermerken und sich einen neuen Block suchen und dort die Daten rein schreiben. So weit so richtig? Es ist nicht ganz trivial, aber im Moment sehe ich eher das Problem darin, herauszufinden, welche Daten in die Zuordnungstabelle alle rein müssen.
> ich möchte mit dem FSMC des STM32F407 einen NAND-Flash vom Typ > S34ML04G100TFI000 ansteuern. Bist du Masochist? Der einzige Grund, rohe NANDs einzusetzen, ist Massenfertigung wo es auf jeden Pfennig ankommt. Und selbst dann auch nur, wenn entsprechende Firmware vorhanden ist. Du würdest ja auch keine nackten Festplatten ohne Elektronik kaufen. Selbst im Linux Kernel ist der Support, obwohl sie schon Jahre dran rumbasteln, für SLC-NANDs eher bescheiden und für MLCs noch in der Entwicklung. Nimm entweder eMMC oder [µ]SD-Karten, also NAND mit eingebautem Controller und für das verbaute NAND passender Firmware. Geschwindigkeitsmäßig können die sogar schneller sein (ja, sogar ne µSD-Karte). NANDs sind ne Pest für Open Source Entwickler - zu komplex, jeder Hersteller kocht sein eigenes Süppchen, Infos/Treiber nur unter NDA, etc. Zum Glück scheint das den Geräteentwicklern auch langsam zu umständlich zu werden und sie steigen vermehrt auf eMMC um.
asdfasd schrieb: >> ich möchte mit dem FSMC des STM32F407 einen NAND-Flash vom Typ >> S34ML04G100TFI000 ansteuern. > > Bist du Masochist? Der einzige Grund, rohe NANDs einzusetzen, ist > Massenfertigung wo es auf jeden Pfennig ankommt. Und selbst dann auch > nur, wenn entsprechende Firmware vorhanden ist. Du würdest ja auch > keine nackten Festplatten ohne Elektronik kaufen. Selbst im Linux > Kernel ist der Support, obwohl sie schon Jahre dran rumbasteln, für > SLC-NANDs eher bescheiden und für MLCs noch in der Entwicklung. > > Nimm entweder eMMC oder [µ]SD-Karten, also NAND mit eingebautem > Controller und für das verbaute NAND passender Firmware. > Geschwindigkeitsmäßig können die sogar schneller sein (ja, sogar ne > µSD-Karte). > > NANDs sind ne Pest für Open Source Entwickler - zu komplex, jeder > Hersteller kocht sein eigenes Süppchen, Infos/Treiber nur unter NDA, > etc. Zum Glück scheint das den Geräteentwicklern auch langsam zu > umständlich zu werden und sie steigen vermehrt auf eMMC um. Für eMMC und SD-Karten gibt es ganz klare Grenzen. Der Temperaturbereich von eMMC und SD-Karten ist in der Regel eingeschränkt, NAND-SLC bekommt man durch die Bank weg mit -40..+85°C. Und gegen SD-Karten sprechen Anwendungen, bei denen starke Vibrationen auftreten, denn dabei heben die Kontakte ab. Es gibt Anwendungen, da benutzt man ganz bewusst einen NAND-SLC. eMMC ist kein Allheilmittel, zumal auch recht teuer gegenüber den meisten größeren NAND-SLCs. Noch dazu gibt es eMMC eigentlich ausschliesslich in finepitch-BGA-Bauformen, selbst 0,5mm Pitch ist eher selten, meist 0,4mm und drunter, dementsprechend steigen die Anforderungen an die Leiterplatte, was die Sache wieder teuer macht.
@ Frank Bär (f-baer) >Für eMMC und SD-Karten gibt es ganz klare Grenzen. Die gibt es immer. >Der Temperaturbereich von eMMC und SD-Karten ist in der Regel >eingeschränkt, Worauf? > NAND-SLC bekommt man durch die Bank weg mit -40..+85°C. Auch das ist ganz klar eingeschränkt. Ob die EInschränkung von eMMC für den OP relevant ist? >Und gegen SD-Karten sprechen Anwendungen, bei denen starke Vibrationen >auftreten, denn dabei heben die Kontakte ab. Ob das für den OP relevant ist? Wieviele SD-Karten arbeiten problemlos in Autoradios? > Es gibt Anwendungen, da >benutzt man ganz bewusst einen NAND-SLC. eMMC ist kein Allheilmittel, >zumal auch recht teuer gegenüber den meisten größeren NAND-SLCs. Dafür bekommt man auch mehr.
Falk B. schrieb: > @ Frank Bär (f-baer) >>Der Temperaturbereich von eMMC und SD-Karten ist in der Regel >>eingeschränkt, > > Worauf? Die meisten eMMC sind nur von 0..70°C spezifiziert. die Technologie ist eben für den Einsatz in Consumerprodukten vorgesehen. >> NAND-SLC bekommt man durch die Bank weg mit -40..+85°C. > > Auch das ist ganz klar eingeschränkt. Ob die EInschränkung von eMMC für > den OP relevant ist? Das wissen wir nicht, nichtsdestotrotz kann ich damit klar begründen, dass eMMC eben nicht in jeder Situation das technische Optimum ist. >>Und gegen SD-Karten sprechen Anwendungen, bei denen starke Vibrationen >>auftreten, denn dabei heben die Kontakte ab. > > Ob das für den OP relevant ist? Wieviele SD-Karten arbeiten problemlos > in Autoradios? Lesender Zugriff ist etwas anderes als schreibender Zugriff. Beim Lesen kann ich buffern, das ist beim Schreiben schwierig. Insbesondere der Verweis auf die Zugriffsgeschwindigkeiten wird bei SD-Karten in sog. harsh environments bei schreibendem Zugriff klar relativiert, weil Fehlerkorrekturen und Fehlererkennung die effektive Datenrate in den Keller ziehen. Dabei hilft mir auch dre integrierte Controller nicht wirklich weiter, denn wenn die Versorgungskontakte abheben, ist die interne CRC-Prüfung für die Katz. > >> Es gibt Anwendungen, da >>benutzt man ganz bewusst einen NAND-SLC. eMMC ist kein Allheilmittel, >>zumal auch recht teuer gegenüber den meisten größeren NAND-SLCs. > > Dafür bekommt man auch mehr. Wenn man es braucht, bzw. wenn die Einsatzbedingungen es hergeben. Ist alles richtig, was du schreibst. Aber es ist eben NICHT so, wie es in dem von mir zitierten Beitrag zum Ausdruck kommt, dass eMMC oder SD-Karten prinzipiell die bessere Lösung sind. Vielmehr muss man hier ganz klar abwägen, was man braucht.
Also eMMC und dergleichen kommt nicht in Frage, weil BGA. Wie von dir Frank richtig vermutet, verteuert das nur die Leiterplatte. Ausserdem habe ich bereits eine SD-Karte. Die anfallenden Daten werden darauf geloggt. Ich möchte aber aus Redundanzgründen einen zweiten Speicher verbauen, wo die selben Daten ebenfalls mit aufgezeichnet werden. Zuerst wollte ich ein serielles Dataflash (AT45DB und wie sie alle heissen) einsetzen, diese haben aber einfach viel zu wenig Speicher. Daher der NAND-Flash.
@Tobias Plüss (hubertus) >Ausserdem habe ich bereits eine SD-Karte. Die anfallenden Daten werden >darauf geloggt. Ich möchte aber aus Redundanzgründen einen zweiten >Speicher verbauen, wo die selben Daten ebenfalls mit aufgezeichnet >werden. Warum? Sind die Daten sooo wichtig? Hälst du die SD-Karte für soo anfällig? Nimm eine 2. SD-Karte. > Zuerst wollte ich ein serielles Dataflash (AT45DB und wie sie >alle heissen) einsetzen, diese haben aber einfach viel zu wenig >Speicher. Daher der NAND-Flash. Der dir tonnenweise Arbeit bescheren wird.
Falk B. schrieb: > @Tobias Plüss (hubertus) > >>Ausserdem habe ich bereits eine SD-Karte. Die anfallenden Daten werden >>darauf geloggt. Ich möchte aber aus Redundanzgründen einen zweiten >>Speicher verbauen, wo die selben Daten ebenfalls mit aufgezeichnet >>werden. > > Warum? Sind die Daten sooo wichtig? Hälst du die SD-Karte für soo > anfällig? Nimm eine 2. SD-Karte. Nimm es doch einfach als Kundenvorgabe, dass die Daten auch auf einem integrierten (d.h. nicht entfernbaren) Speichermedium manipulationssicher abgelegt werden sollen. >> Zuerst wollte ich ein serielles Dataflash (AT45DB und wie sie >>alle heissen) einsetzen, diese haben aber einfach viel zu wenig >>Speicher. Daher der NAND-Flash. > > Der dir tonnenweise Arbeit bescheren wird. Das ist seine Sache, auf der anderen Seite steht nämlich auch der Lerneffekt, und der ist bei einer korrekten Implementation eines Flash-Speicher mit Filesystem und Wear Leveling ziemlich ausgeprägt. Aber warum muss hier eigentlich grundsätzlich immer über jedes Detail der Fragestellungen diskutiert werden? Nur weil die Antwort nicht zur Frage passt, heisst das doch nicht, dass die Frage zwangsläufig falsch ist. Die Anforderung, die Tobias hier stellt, ist doch nicht so abwegig. Hier geht es jetzt nur noch darum, dass er bitteschön eure Lösung (eMMC bzw. SD-Karte) nehmen soll, weil eurer Ansicht nach NAND-Flash Schrott ist. Pure Rechthaberei! "Hey, meine Lösung passt zwar nicht zu deinem Problem, aber wie wäre es, wenn du dein Problem einfach änderst? Dann wäre ich wieder im Recht und wir alle wären glücklich."
Frank B. schrieb: > "Hey, meine Lösung passt zwar nicht zu deinem Problem, aber wie wäre es, > wenn du dein Problem einfach änderst? Dann wäre ich wieder im Recht und > wir alle wären glücklich.“ Oft genug tauchen hier aber auch Fragestellungen auf, bei denen sich der TE auf einen Lösungsweg für sein Problem eingeschossen hat, und nun die dabei aufgetretenen Probleme gelöst haben will, obwohl sein Ansatz schon Murks ist und viel simpler oder besser hätte gelöst werden können.
Jan H. schrieb: > Frank B. schrieb: >> "Hey, meine Lösung passt zwar nicht zu deinem Problem, aber wie wäre es, >> wenn du dein Problem einfach änderst? Dann wäre ich wieder im Recht und >> wir alle wären glücklich.“ > > Oft genug tauchen hier aber auch Fragestellungen auf, bei denen sich der > TE auf einen Lösungsweg für sein Problem eingeschossen hat, und nun die > dabei aufgetretenen Probleme gelöst haben will, obwohl sein Ansatz schon > Murks ist und viel simpler oder besser hätte gelöst werden können. Kenne ich, selbst oft genug gelesen und ignoriert. Die Herangehensweise ist aber in dieser Fragestellung unnötig... 1. Der TE fragt, wie Wear Leveling funktioniert. 2. Der TE bekommt eine Antwort 3. Der TE konkretisiert nochmal die Nachfrage 4. Der TE bekommt eine detailliertere Antwort, es folgt etwas Fachsimpelei 5. Ein Nutzer erklärt dem TE, dass er bescheuert sei, wenn er NAND-Flash benutzen möchte 6. Ein anderer Nutzer führt an, dass es sehr wohl Situationen gibt, in denen alles für NAND-Flash spricht 7. Der TE erläutert, dass die Entscheidung aus einer der von dem anderen Nutzer angesprochenen Situationen heraus getroffen wurde. Desweiteren nennt er ein paar Details aus seinem Vorhaben 8. Dem TE wird erklärt, wie bescheuert er sei, wenn er NAND-Flash benutzen möchte, und dass sein Vorhaben völlig unsinnig ist.
Mal ein paar Ideen: Von ST gibt es einen "Advanced NAND Flash Driver for SLC NAND" allerdings afaik nur auf Nachfrage und nicht als direkt zugänglichen Download... http://www.st.com/st-web-ui/static/active/en/resource/technical/document/user_manual/DM00091013.pdf und ein Eval-Board dazu http://www.st.com/web/en/catalog/tools/PF258870 Eine andere Möglichkeit wären serielle/SPI NANDs (SO-8/WSON-8-Gehäuse) und auf derselben Fläche wie das jetzt eingesetze NAND-Flash mehrere entweder zur Redundanz oder zum Speichern der Verwaltungsinformation zu verbauen. Hersteller sind afair u.a. Winbond, Macronix, GigaDevice, Ato Solution oder ESMT (Micron zwar auch, aber afair dort nur im BGA-Gehäuse)
Hallo ich habe jetzt hier ein IEEE paper wo die notwendigen Datenstrukturen etc. beschrieben sind und bin dabei, das zu Implementieren. Lesen von 512 Bytes Sektoren (wie Sd-Karte) geht schon mal, ebenso wie das Bad Block Mgmt. Beim Rest bin ich noch dran. Was mich noch interessieren würde: den Datenbereich darf man insgesamt 4mal partiell beschreiben, d.h. man darf 4 Sektoren zu je 512 Bytes schreiben. Was aus den Datenblatt aber nicht genau hervor geht: darf im Spare auch nur 4mal rein geschrieben werden, oder darf ich da nach belieben.einzelne Bits auf 0 setzen? Beispielsweise wurde in eine Page 4x ein Sektor rein geschrieben. Wenn der dazugehörige Block nun defekt geht, müsste ich das im Spare ja vermerken, aber das wäre ja dann ein 5. Dchreibzugriff, was gemäss DB aber ja nicht erlaubt ist (wenn es nicht erlaubt ist frage ich mich allerdings weshalb man auch beim Schreiben einzelne Bytes addressieren kann). Gruss Tobias
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.