Hallo, Beitrag "Re: NAND Flash - Page mittels OR byteweise beschreiben" dazu ist interessant Speziell beim PiPico können nur ganze Sectoren (4094 Byte) gelöscht und ganze Pages (256) geschrieben werden. Wenn nun aber Daten nur 7 Bytes lang sind wird der Rest der Page wohl mehr oder weniger zufällig gefüllt. Wenn dieser Rest aber mit FFFFFFF geschrieben wird, bleibt dann dieser Bereich der Page im gelöscht-Status? Kann ich nun in diesen noch ungenutzten/gelöschten Bereich weitere 7 Bytes schreiben, wenn alle anderen Bytes, auch die vorherigen, FF sind? So kann doch der Nachteil mit den 0(L) Bits, wie im obigen Beitrag beschrieben, vermieden werden Da der Flash-Sector dazwischen nicht gelöscht wurde, müssten dann beide Datensätze auslesbar sein. Idealer Weise könnte so fortgefahren werden bis die Page voll ist. Erst danach müsste der Sector gelöscht werden. Ich werde es vermutlich ausprobieren, aber eure Meinung interessiert mich schon vorher. Gruß Rudi
Ja, natürlich, du kannst immer Bits von 1 nach 0 schreiben. Wenn du
versuchst, 1-Bits zu schreiben, passiert einfach nichts, d.h. die
vorherigen Daten bleiben dort erhalten.
Mit ein paar rotierenden Puffern am Ende des Flashs haben wir auf diese
Weise schon vor geraumer Zeit eine EEPROM-Emulation gebaut. "Gelöschte"
Bereiche bekommen dabei im ersten Byte eine 0 ("nicht mehr in
Verwendung"), erst wenn kein freier Bereich mehr verfügbar ist, wird
wieder ein Sektor gelöscht und benutzt.
Danke für die schnelle Antwort. Ich mach mir einfach Sorgen, dass mir nicht sowas passiert: https://hackaday.com/2021/02/11/tesla-recalls-cars-with-emmc-failures-calls-part-a-wear-item/ Ich hoffe, es gibt keine weiteren Fallstricke.
Rudi schrieb: > Ich mach mir einfach Sorgen, dass mir nicht sowas passiert… Winbond: Mindestens 100.000 Erase-cycles. Min. 20 Jahre data retention bei max. 55°C Wenn du darüber hinaus gehst, kann es dir passieren. Wenn du weit darüber hinaus gehst, wird es dir passieren. Oftmals muss man nicht ein jedes Byte sofort (im Sinne von unmittelbar) ins Silizium brennen. Erst eine Page sammeln und dann … Zündung … reicht auch.
Norbert schrieb: > Winbond: Mindestens 100.000 Erase-cycles. > Min. 20 Jahre data retention bei max. 55°C Und danach noch 1.000.000 Erase cycles mit 2 Jahren Data retention, und dann 10.000.000 mit 2 Monaten, und dann 100.000.000 mit 6 Tagen. Wenn der Chip nicht vorher an was anderem stirbt. Aber so ist der typische Verlauf.
Soul E. schrieb: > Und danach noch 1.000.000 Erase cycles mit 2 Jahren Data retention, und > dann 10.000.000 mit 2 Monaten, und dann 100.000.000 mit 6 Tagen. Interessant. Um viele Größenordnungen mehr also. Das die Hersteller das so nicht schreiben … schon komisch. Aber es scheint ja - deiner Eingabe nach - in Studien und Feldversuchen unzweifelhaft getestet worden zu sein. Hättest du da eventuell belastbare Quellen, papers, etc?
Norbert schrieb: > Das die Hersteller das so nicht schreiben … schon komisch. Sie schreiben, was sie auch garantieren können und durch Tests verifizieren. Die Tests laufen übrigens bei erheblich höheren Temperaturen, die damit eine X Jahre lange Alterung simulieren sollen. Die entsprechend benutzten Testboards sehen nach dem (einige Wochen andauernden) Tests, ähm, sehr interessant aus.
Norbert schrieb: > Interessant. Um viele Größenordnungen mehr also. Wie man es nimmt. Data retention time und Zyklenzahl hängen halt zusammen, und man hat sich bei Mikrocontrollern auf den Wert für 20 Jahre und bei SSDs auf den für 1 Jahr geeinigt. So bleibt es vergleichbar. > Das die Hersteller das so nicht schreiben … schon komisch. Viele Hersteller geben zwei Stützstellen an (z.B. die Anzahl der Zyklen für 20 Jahre und für 5 Jahre Datenerhalt), daraus kannst Du den Exponenten abschätzen. Auf Anfrage rücken die Hersteller auch weitergehende Informationen raus. Die sind dann allerdings oft "typisch" und nicht garantiert. Beliebig weit extrapolieren klappt halt nicht, da dann auch andere Ausfallmechanismen dazukommen.
@Norbert ja, da hab ich bei meinem Projekt ein Problem. Ich muß meine kleinen Datenschnipsel erheblich öfter Updaten. Geschätzt evtl. alle 10 Minuten, insgesamt 20-50 mal pro Tag. Und dann auch mal Tagelang nicht. Die Schwierigkeit dabei ist, dass das Ding zwischendurch Stromlos wird. Dabei sollte das Ding schon die 10Jahre schaffen. Ich hoffe, dass wirklich nur die Erasecyles zählen und meine geplanten ReWrites micht.
Rudi schrieb: > Die Schwierigkeit dabei ist, dass das Ding zwischendurch Stromlos wird. > Dabei sollte das Ding schon die 10Jahre schaffen. Pufferkondensator + Netzausfallerkennung
Kein Platz, kein Netz und die Batterie für den PiPico soll >6 Monate reichen.
FRAM ! ? Das übersteht einen Stromausfall und hat mehr Lesezyklen als so manch einer Lebenszeit. ;-) Auch... 23LCV1024 da sind 1/2 Jahr kein Problem mit einer Knopfzelle Lebensdauer quasi unendlich.
Unter der Bezeichnung 48lm01 gibts bzw. gabs das Ding auch mit 128 kByte Kapazität - leider hat Microchip das Teil ersatzlos abgekündigt. Ein Äquivalent gibt es von Infineon, das aber ist schmerzerregend teuer. https://www.microchip.com/en-us/product/48lm01 https://www.infineon.com/cms/en/product/memories/f-ram-ferroelectric-ram/excelon-f-ram/cy15b201qn-50sxe/ Die F-RAMs von Infineon gibt es aber auch mit bis zu 16 MBit Kapazität, wenn man mit dem ekligen Gehäuse zurechtkommt, könnte man damit das Flash-ROM für den RP2040 komplett ersetzen: https://www.infineon.com/cms/en/product/memories/f-ram-ferroelectric-ram/excelon-f-ram/cy15b116qsn-108bkxqt/
Jörg W. schrieb: > Ja, natürlich, du kannst immer Bits von 1 nach 0 schreiben Das ist nicht grundsätzlich der Fall. Hier der Auszug aus einem Datenblatt eines SLC-Nand-Flashes von Samsung. Ein Flashbaustein mit 4Gx8Bit.
1 | The device is programmed basically on a page basis, but it does allow multiple partial page programming of a word or consecutive bytes up to 4,224, in a single page program cycle. The number of consecutive partial page programming operation within the same page without an intervening erase operation must not exceed 4 times for a single page. The addressing should be done in sequential order in a block. |
Hier darf das teilweise Beschreiben einer Page nur 4x erfolgen. Dann sollte die Page wieder gelöscht werden.
:
Bearbeitet durch User
Nachtrag: Die größte Ausführung im noch verarbeitbaren Gehäuse ist 8 MBit groß: https://www.infineon.com/cms/en/product/memories/f-ram-ferroelectric-ram/excelon-f-ram/cy15b108qn-40sxit/ Aber bereits die 128-kByte-Version ist ... empfindlich teuer: https://www.mouser.de/c/?q=CY15B201QN Und die 1-MByte-Version erst recht: https://www.mouser.de/c/?q=CY15B108QN-40SXIT
900ss D. schrieb: > Hier darf das teilweise Beschreiben einer Page nur 4x erfolgen. Dann > sollte die Page wieder gelöscht werden. Nachtrag: Natürlich gilt die Regel, immer nur von 1 nach 0 Schreiben trotzdem. Aber eine Page sagen wir byteweise zu beschreiben geht nicht. In 1KB-Teilen dann schon. Es sind 4224 Byte/Page wovon aber nur 4096 Bytess Nutzdaten sind. Der Rest sind spare data für ECC und FML Verwaltungsdaten.
@Christian M Die Betriebsspannung kann bis 1,8V abfallen. @Christian M Vcc ist OK, 24-ball BGA pinout kann ich nicht löten @900ss D Aha! Das würde den Anfangs zitierten Beitrag entsprechen, wenn man eine einzelne Bitposition mehrmals auf Null zieht - hab ich aber nicht vor. Mit dem PiPico c-SDK mit dem internen Flash muß ich mich nicht um Verwaltungsdaten kümmern. Ich seh' schon, ich muß einen Pico opfern falls es nicht funktioniert (sind auch nur 5€). @Harald K Der 128k Chip wäre ok, muß halt nur >3 Monate Warten. Preis (14€) für Einzelanferigung ok.
Der Winbond Flash Chip wird in 256Byte pages beschrieben. Bei 2MiB wären das 8192 pages. 50 mal pro Tag eine page schreiben, über einen Zeitraum von 10 Jahren, ergibt 182.500 pages insgesamt. Somit muss man auf die ganze Zeit weniger als 23 Mal komplett löschen. Heißt: Das Ding ist nach 10 Jahren noch fast wie neu.
Jörg W. schrieb: > Aber wird sowas auch in MCUs integriert? Der RP2040 enthält kein Flash-ROM, das muss in Form eines SPI-Flash-Bausteins extern angeschlossen werden. Auf den etwas ungeschickt mit "Raspberry Pi Pico" benannten Platinen ist so etwas verbaut.
Jörg W. schrieb: > Aber wird sowas auch in MCUs integriert? Dass weiß ich nicht. Ich wollte auch nur darauf hinweisen, dass das teilweise Beschreiben eine Page nicht immer unbegrenzt möglich ist. Also man muss das Datenblatt lesen.
Harald K. schrieb: > könnte man damit das Flash-ROM für den RP2040 komplett ersetzen: Ich glaube kaum. Flashspeicher "hört" auf Kommandos zum Löschen/Schreiben und manchmal auch zum Lesen. Die Kommandos würden ein FRAM wohl ziemlich "durcheinander" bringen. Dein Wissen zu Flashspeicher scheint Lücken schon bei den Basics zu haben.
:
Bearbeitet durch User
Harald K. schrieb: > Die F-RAMs von Infineon gibt es aber auch mit bis zu 16 MBit Kapazität, > wenn man mit dem ekligen Gehäuse zurechtkommt, könnte man damit das > Flash-ROM für den RP2040 komplett ersetzen Na hoffentlich beherrschen die auch Quad-SPI (als absolute Minimalanforderung) Und 16MBit können dann auch schon gerne ein wenig eng um die Schultern sein, ich habe auf meinen zB. 128MBit Bausteine. Im Übrigen sehe ich die generelle Notwendigkeit aber auch nicht.
Norbert schrieb: > Na hoffentlich beherrschen die auch Quad-SPI (als absolute > Minimalanforderung) Noch ein Punkt der zeigt, dass er Wissen aufholen muss. Nachtrag: Und mal sehen was das FRAM zu 133MHz SPI-Datentakt sagt :) Allerdings weiß ich gerade nicht, ob der Pico solch einen schnellen Takt verwendet. Aber es gibt solch schnelle SPI Flashspeicher.
:
Bearbeitet durch User
@Norbert Ist leider eine Milchmädchen-Rechnung. Schließlich ist im Pico-Flash auch der Programmcode. Außerdem static Daten, bleiben für meine speziellen Daten nur 2 Sectoren (2*4096 Byte). Da wird es schon etwas knapp.
Rudi schrieb: > Außerdem static Daten, bleiben für meine > speziellen Daten nur 2 Sectoren (2*4096 Byte). Tipp: Solche Information unbedingt erst noch einige Wochen geheim halten. … Leute gibt's … Und noch etwas: Wenn man anstelle von ca. 8000 pages nur 8 pages zur Verfügung hat, dann muss man die halt 1000 mal so oft beschreiben und löschen. Also anstelle von 23 Löschvorgängen, dann halt 23.000 Löschvorgänge. Über die Spezifikationen hatten wir ja schon gesprochen.
:
Bearbeitet durch User
> Na hoffentlich beherrschen die auch Quad-SPI (als absolute > Minimalanforderung) Das reicht IMHO nicht. Die QSPI Flash unterscheiden sich von Hersteller zu Hersteller immer noch leicht in den unterstuetzten Kommandos oder der Bedeutung bestimmter Bits in den Configregistern. Auch das Timing kann sich hier und da unterscheiden. Damit kann man VIEL Freude haben. .-) Vanye
Rudi schrieb: > @Christian M > Die Betriebsspannung kann bis 1,8V abfallen. Wir reden doch vom originalen Raspberry Pi Pico mit diesem Winbond Speicher? Laut Datenblatt braucht der W25Q16JV 3.3V ±10% zum Schreiben; Lesen geht auch noch mit 2.7V. Aber man kann ihn auch in 7-Byte Häppchen beschreiben:
1 | 9.2.13 Page Program (02h) |
2 | The Page Program instruction allows from one byte to 256 bytes |
3 | (a page) of data to be programmed at previously erased (FFh) memory |
4 | locations. (...) In some cases, less than 256 bytes (a partial page) |
5 | can be programmed without having any effect on other bytes within |
6 | the same page. One condition to perform a partial page program is that the number of clocks cannot exceed the remaining page length. |
Die einzige Einschränkung: Ein 7-Byte Datensatz muss vollständig in eine Page passen. Es passen also nur 36 mal 7 Byte rein, 4 Byte bleiben ungenutzt. Der Link und die Bemerkungen zu NAND-Flash sind sehr interessant, aber hier nicht zutreffend. Rudi schrieb: > bleiben für meine speziellen Daten nur 2 Sectoren (2*4096 Byte). Warum? Ist das Programm wirklich genau 2MByte - 8192 Byte groß?
Bauform B. schrieb: > Wir reden doch vom originalen Raspberry Pi Pico mit diesem Winbond > Speicher? Laut Datenblatt braucht der W25Q16JV 3.3V ±10% zum Schreiben; > Lesen geht auch noch mit 2.7V. Auf dem Pi Pico ist ein RT6150A/B verbaut, der arbeitet von 1.8V an aufwärts und erzeugt die 3.3V für das System.
Rudi schrieb: > Ich mach mir einfach Sorgen, dass mir nicht sowas passiert: > > https://hackaday.com/2021/02/11/tesla-recalls-cars-with-emmc-failures-calls-part-a-wear-item/ Man muß sich erstmal überlegen, welche Datenmengen wie oft geschrieben werden sollen. Für kleine Datenmengen kann man gut FRAM verwenden. Für große Datenmengen nimmt man Wechselmedien (SD-Card). Fest eingelötetes Flash nimmt man nur für selten zu ändernde Daten, z.B. Firmwareupdates. Wer das nicht beachtet, ist ein Idiot. Sowas hätte ich von Tesla nicht erwartet. Wenn der Kunde gutes Geld ausgibt, sollte man schon etwas gründlicher über die Anforderungen nachdenken. Man erlebt das leider oft, daß Geräte entwickelt werden, ohne eine intelligente Schreibstrategie. Es wird unnötig viel zu oft geschrieben, so daß der Flash schnell verschleißt. Man kann z.B. Daten erstmal nur in SDRAM ablegen und erst bei einem Stromausfall über eine kleine Stützbatterie im Flash sichern. Bis etwa 16MB gibt es auch Flash im SOIC-8, der sich recht einfach auslöten läßt. Das ist aber trotzdem nicht kundenfreundlich.
:
Bearbeitet durch User
> Für kleine Datenmengen kann man gut FRAM verwenden. Für große Man muesste natuerlich definieren was klein/gross so ist, aber auf der Embedded wollte mir der Hersteller schon FRAMs andrehen die ich als gross angesehen haette. Ich meine (so aus dem Gedaechtnis) das da schon 8Mbit zu haben waren. Also jedenfalls deutlich mehr wie die ueblichen 2,8,16 kbit die wir alle so kennen/nutzen. > Datenmengen nimmt man Wechselmedien (SD-Card). Eher eMMC wegen integriertem Wearleveling. Aber natuerlich kann man sich das auch selber programmieren, man muss es dann aber auch machen. Vanye
Peter D. schrieb: > Sowas hätte ich von Tesla nicht erwartet. Das ist ein Massenprodukt zum wegwerfen, wie jedes Smartphone. https://www.heute.at/s/tesla-fahrer-findet-holzkeile-und-tixo-unter-der-haube-100102891
Vanye R. schrieb: > Eher eMMC wegen integriertem Wearleveling. Auch SD-Karten machen selbstverständlich wear leveling. Du verwechselst das mit den obsoleten SmartMedia- oder xD-Karten. Die waren nackte Flash-Bausteine in Kartenverpackung.
Harald K. schrieb: > Der RP2040 enthält kein Flash-ROM, das muss in Form eines > SPI-Flash-Bausteins extern angeschlossen werden. Ah OK, MCUs kann halt jeder herstellen, Flash nicht. ;-)
Jörg W. schrieb: > Ah OK, MCUs kann halt jeder herstellen, Flash nicht. ;-) Genau. Man muss halt clever sein. Wer so clever ist, der bietet dann 1K,2K,4K,8K,16K,… (µC)Versionen nebeneinander an. ;-)
:
Bearbeitet durch User
Rudi schrieb: > Ich muß meine kleinen > Datenschnipsel erheblich öfter Updaten. Ich verstehe die ganze Diskussion nicht. Da ist doch FRAM die erste Wahl. Norbert schrieb: >> Flash-ROM für den RP2040 komplett ersetzen > > Na hoffentlich beherrschen die auch Quad-SPI (als absolute > Minimalanforderung Bezüglich "Minimalforderung": Bei eevblog hat der Nutzer ataradov das mal untersucht und festgestellt, daß das QUAD nicht so zündend ist, wenn zusätzlich noch ein Cache vorhanden ist. Das nur nebenbei.
Mi N. schrieb: > Rudi schrieb: >> Ich muß meine kleinen >> Datenschnipsel erheblich öfter Updaten. > > Ich verstehe die ganze Diskussion nicht. Da ist doch FRAM die erste > Wahl. "erheblich öfter" = 20 bis 50 mal pro Tag 7 Byte. Es dauert also 11 Tage, bis ein 4K-Sektor voll ist. Angenommen, man hätte nur einen Sektor, dann muss man ihn 33 mal im Jahr löschen. Nach 30 Jahren hat man 1% der versprochenen Löschzyklen verbraucht... Ein zweiter Sektor verdoppelt die Lebensdauer nochmal. Da ist doch das serienmäßige Flash die erste Wahl.
> Ah OK, MCUs kann halt jeder herstellen, Flash nicht. ;-) Laester nicht. Externes QSPI-Flash kommt in letzter Zeit in Mode und das nicht nur bei billigkram wie den ESP8266. Es gibt auch sackteure HF-Sachen oder FPGAs wo das genauso ist. Passt wohl nicht immer in den Prozess. > Ich verstehe die ganze Diskussion nicht. Da ist doch FRAM die > erste Wahl. Es gibt auch noch MRAM. > Da ist doch das serienmäßige Flash die erste Wahl. Ja, braucht aber etwas expertise bei Design und Programmierung. :-) Vanye
@ Bauform B Das war nicht meine erste Frage! Es geht darum: das PiPico C-SDK bietet nur eine Schreibfunktion an, die nur ganze 128Bits an 128er Grenzen schreiben lässt. Bisher ist diese Diskussion nicht eindeutig, ob mein anfängliches Konzept funktioniert. Alles andere ist hier nicht die Frage. Norbert schrieb: > … Leute gibt's … Und da gibt es auch nichts zu meckern, weils vom Prinzip her unwichtig ist.
Vanye R. schrieb: > Externes QSPI-Flash kommt in letzter Zeit in Mode Bei MCUs aber eher von den Firmen, die halt kein Flash können. HF oder FPGA mag was anderes sein, wenngleich es durchaus Firmen gibt, die HF und Flash unter einen Hut bekommen. ;-)
Hallo, Nun hab ein Testprogramm fertig. Es beschreibt eine Page 16 mal an verschiedenen Positionen. Dann wird sie gelöscht und geprüft ob Bits "hängen" geblieben sind. Innerhalb einer 3/4 Stunde wurden 20000 Löschungen durchgeführt und 320000 einzeln Writes. Für meine Anwendung wären das dann ~17 Jahre.
1 | Flash has 2097152 Bytes = 0x00200000 |
2 | XIP has 268435456 Bytes = 0x10000000 |
3 | Page used: 10000000 : 158 times |
4 | Page free: 10009E00 : 2 times |
5 | Page used: 1000A000 : 11 times |
6 | Page free: 1000AB00 : 5 times |
7 | Page used: 1000B000 : 78 times |
8 | Page free: 1000FE00 : 770 times |
9 | Page used: 10040000 : 1 times |
10 | Page free: 10040100 : 7167 times |
11 | Scan successful! |
12 | |
13 | 19999 |
14 | ReWrite Test successful |
15 | after 20000 Erases and 320000 Writes |
16 | on the same Page |
Wenn schon, musst du den Test bei 150 °C durchführen. Da bekommst du eher ein Gefühl dafür, wann da was aussteigt. Allerdings bekommst du natürlich noch kein Gefühl dafür, wie lange die einmal geschriebenen Daten danach noch erhalten bleiben.
In diesem Beitrag "NAND Flash - Page mittels OR byteweise beschreiben" ist eher davon die Rede, dass dann die Nullen nicht mehr zurückgesetzt werden können. Die Daten selbst brauchen für mich nur Tage zu überleben bis sie ersetzt werden.
Rudi schrieb: > ist eher davon die Rede, dass dann die Nullen nicht mehr zurückgesetzt > werden können Würde ich jetzt nicht so erwarten, kann aber auch passieren. Prinzip eines EPROMs ist ja, dass du eine Ladung in die Isolationsschicht vor dem Gate eines FET einbringst, bis die Gate-Schwellspannung überschritten wird. Beim Löschen extrahierst du dann die Ladung wieder von da. Die Wahrscheinlichkeit, dass er sich nicht mehr löschen lässt, hielte ich jetzt persönlich für kleiner als die, dass eine einmal eingebrachte Ladung sich unbeabsichtigt so weit abbaut, dass das Bit zurück kippt – aber ich habe das jetzt nicht recherchiert.
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.