wie oft kann man NOR Flash lesen?

[Frank Buss]

FĂźr NAND Flash gibt es den read disturb Effekt:

https://en.wikipedia.org/wiki/Flash_memory#Read_disturb

Wenn man eine Zelle immer wieder liest, dann zerstĂśrt das mit der Zeit
den Wert von benachbarten Zellen. Gilt das auch fĂźr NOR Flash, speziell
fĂźr diese SPI-Flash ICs wie SST25VF? Jemand bei Stackexchange meint ja,
aber er zitiert auch nur den Wikipedia-Eintrag Ăźber NAND Flash:

https://electronics.stackexchange.com/questions/162415/will-reading-serial-flash-memory-wear-it-out

Was eigentlich dagegen spricht ist, daß mir so ein Effekt bei Flash bei
Microcontrollern nicht bekannt ist, da kann man problemlos jahrelang
immer wieder dieselbe Zelle lesen.

--
Frank Buss, http://www.frank-buss.de
electronics and more: http://www.youtube.com/user/frankbuss

 

[Christian Zietz]

Frank Buss schrieb:

FĂźr NAND Flash gibt es den read disturb Effekt:

https://en.wikipedia.org/wiki/Flash_memory#Read_disturb

Wenn man eine Zelle immer wieder liest, dann zerstĂśrt das mit der Zeit
den Wert von benachbarten Zellen. Gilt das auch fĂźr NOR Flash

Ein Blick in die prinzipielle Schaltung (auch in dem oben verlinkten
Wikipedia-Artikel) zeigt schon, warum der Effekt nur bei NAND-Flash
auftritt: hier mĂźssen zum Auslesen eines einzelnen Bits auch die
benachbarten Transistoren durchgeschaltet werden, was sie auf Dauer
umprogrammieren kann. Bei NOR-Flash ist das nicht der Fall.

Grüße
Christian
--
Christian Zietz - CHZ-Soft - czietz (at) gmx.net
WWW: http://www.chzsoft.de/
PGP/GnuPG-Key-ID: 0x52CB97F66DA025CA / 0x6DA025CA

 

[Stefan Reuther]

Am 30.03.2019 um 11:23 schrieb Christian Zietz:

Frank Buss schrieb:
Wenn man eine Zelle immer wieder liest, dann zerstĂśrt das mit der Zeit
den Wert von benachbarten Zellen. Gilt das auch fĂźr NOR Flash

Ein Blick in die prinzipielle Schaltung (auch in dem oben verlinkten
Wikipedia-Artikel) zeigt schon, warum der Effekt nur bei NAND-Flash
auftritt: hier mĂźssen zum Auslesen eines einzelnen Bits auch die
benachbarten Transistoren durchgeschaltet werden, was sie auf Dauer
umprogrammieren kann. Bei NOR-Flash ist das nicht der Fall.

Allerdings werden auch bei NOR-Flashes die Zellen immer kleiner, dass es
da zu ungeplanten Effekten kommen kann. Ich hatte schon einen Typen in
den Fingern, wo der Hersteller hinterher damit rausgerĂźckt ist, dass sie
intern bereits einen Hamming-Code generieren, sofern die Schreibmuster
das zulassen.

Insofern wĂźrde ich, wenn es mĂśglich ist, einen CRC/ECC einbauen. Wenn
nicht wĂźrde ich allerdings nicht viel schlechter schlafen, das treibt
dann vermutlich die Ausfälle ein paar ppm hoch.


Stefan

 

[Frank Buss]

On 03/30/2019 12:18 PM, Stefan Reuther wrote:

Allerdings werden auch bei NOR-Flashes die Zellen immer kleiner, dass es
da zu ungeplanten Effekten kommen kann. Ich hatte schon einen Typen in
den Fingern, wo der Hersteller hinterher damit rausgerĂźckt ist, dass sie
intern bereits einen Hamming-Code generieren, sofern die Schreibmuster
das zulassen.

Welcher Chip war das? Wäre natßrlich auch eine gute Idee, mal die
Hersteller anzufragen. Aber vermute ist schwer bei sowas eine definitive
Aussage zu bekommen.

Insofern wĂźrde ich, wenn es mĂśglich ist, einen CRC/ECC einbauen. Wenn
nicht wĂźrde ich allerdings nicht viel schlechter schlafen, das treibt
dann vermutlich die Ausfälle ein paar ppm hoch.

Ja, ECC ist eine gute Idee. Irgendein Bitfehler oder ein kauputtes Bit
kann ja immer mal passieren. Verwenden das Microcontroller mit dem
internen NOR Flash auch?

--
Frank Buss, http://www.frank-buss.de
electronics and more: http://www.youtube.com/user/frankbuss

 

[Christian Zietz]

Frank Buss schrieb:

Ja, ECC ist eine gute Idee. Irgendein Bitfehler oder ein kauputtes Bit
kann ja immer mal passieren. Verwenden das Microcontroller mit dem
internen NOR Flash auch?

Eine Mikrocontrollerfamilie, mit der ich beruflich viel zu tun habe,
nutzt in der Tat ECC fĂźrs interne Flash. Aber mit Sicherheit nicht wegen
"read disturbs", was ja Deine ursprĂźngliche Frage war und was dort nicht
auftritt, sondern um anderweitige Bitfehler zu erkennen bzw. zu korrigieren.

Grüße
Christian
--
Christian Zietz - CHZ-Soft - czietz (at) gmx.net
WWW: http://www.chzsoft.de/
PGP/GnuPG-Key-ID: 0x52CB97F66DA025CA / 0x6DA025CA

 

[Matthias Weingart]

Christian Zietz <newsgroup.1001@chz.xyz>:

Frank Buss schrieb:

Ja, ECC ist eine gute Idee. Irgendein Bitfehler oder ein kauputtes Bit
kann ja immer mal passieren. Verwenden das Microcontroller mit dem
internen NOR Flash auch?

Eine Mikrocontrollerfamilie, mit der ich beruflich viel zu tun habe,
nutzt in der Tat ECC fĂźrs interne Flash. Aber mit Sicherheit nicht
wegen "read disturbs", was ja Deine ursprĂźngliche Frage war und was
dort nicht auftritt, sondern um anderweitige Bitfehler zu erkennen bzw.
zu korrigieren.

Flash-Gates verlieren ja mit der Zeit an Ladung, und je höher die Temperatur
ist - umso schneller. NOR-Flash für Automotive ( ...125°C) ist eigentlich
schon fast nicht mehr möglich - ausser die Hersteller bauen ein paar Tricks
ein (autom. neu Flashen).
Ich glaube, dieser Effekt dominiert bei NOR. Zumindest ist in den
einschlägigen App-Notes eher davon zu lesen und nichts von anderen Effekten.

M.
--

 

[Stefan Reuther]

Am 01.04.2019 um 01:55 schrieb Frank Buss:

On 03/30/2019 12:18 PM, Stefan Reuther wrote:
Allerdings werden auch bei NOR-Flashes die Zellen immer kleiner, dass es
da zu ungeplanten Effekten kommen kann. Ich hatte schon einen Typen in
den Fingern, wo der Hersteller hinterher damit rausgerĂźckt ist, dass sie
intern bereits einen Hamming-Code generieren, sofern die Schreibmuster
das zulassen.

Welcher Chip war das?

Ich fßrchte das fällt noch unter NDA.

Wäre natßrlich auch eine gute Idee, mal die
Hersteller anzufragen. Aber vermute ist schwer bei sowas eine definitive
Aussage zu bekommen.

Wie gesagt, war schwierig, fand sich dann aber indirekt Ăźber eine
Application Note, die dringendst empfahl, nicht byteweise zu schreiben
(wie man das ja bei NOR-Flash normalerweise kann), sondern blockweise.

In meinem Fall hab ich die meisten Daten schon aus PerformancegrĂźnden
blockweise geschrieben, aber dann ganz zum Schluss noch mal einzeln das
Gßltigkeitsbit gesetzt. Das musste dann halt geändert werden.

Insofern wĂźrde ich, wenn es mĂśglich ist, einen CRC/ECC einbauen. Wenn
nicht wĂźrde ich allerdings nicht viel schlechter schlafen, das treibt
dann vermutlich die Ausfälle ein paar ppm hoch.

Ja, ECC ist eine gute Idee. Irgendein Bitfehler oder ein kauputtes Bit
kann ja immer mal passieren. Verwenden das Microcontroller mit dem
internen NOR Flash auch?

Das wĂźrde ich fĂźr insofern unwahrscheinlich halten, als dass die
Microcontroller ja meistens in-place-AusfĂźhrung (XIP) machen und das
beißt sich ein wenig mit einem vorgeschalteten ECC. Beziehungsweise, das
bräuchte einen *sehr* intelligenten Cachecontroller.


Stefan

 

[Frank Buss]

On 04/01/2019 06:21 PM, Stefan Reuther wrote:

Am 01.04.2019 um 01:55 schrieb Frank Buss:
On 03/30/2019 12:18 PM, Stefan Reuther wrote:
Allerdings werden auch bei NOR-Flashes die Zellen immer kleiner, dass es
da zu ungeplanten Effekten kommen kann. Ich hatte schon einen Typen in
den Fingern, wo der Hersteller hinterher damit rausgerĂźckt ist, dass sie
intern bereits einen Hamming-Code generieren, sofern die Schreibmuster
das zulassen.

Welcher Chip war das?

Ich fßrchte das fällt noch unter NDA.

Wäre natßrlich auch eine gute Idee, mal die
Hersteller anzufragen. Aber vermute ist schwer bei sowas eine definitive
Aussage zu bekommen.

Wie gesagt, war schwierig, fand sich dann aber indirekt Ăźber eine
Application Note, die dringendst empfahl, nicht byteweise zu schreiben
(wie man das ja bei NOR-Flash normalerweise kann), sondern blockweise.

Ich habe mal ein paar Tests gemacht:

https://hackaday.io/page/6060-spi-flash-test

Lesen scheint man unbegrenzt zu kĂśnnen. Zumindest gab es erst nach 118
Millionen mal die ersten paar Pages (1 page = 256 Bytes) lesen, einmal
einen Fehler, und das wird wohl wegen meinem Breadboardaufbau gewesen
sein. Nach Neustart, ohne neu Schreiben, lief es wieder problemlos
millionenfach.

Ich habe dann auch einen Schreibtest gemacht, immer auf die erste Page
und gelĂśscht, und da hielt es 8 Millionen Zyklen (Datenblatt sagt
mindestens 100.000). Nach Neustart dann 5 Millionen Zyklen. Nicht
schlecht fĂźr ein 10 Cent IC.

--
Frank Buss, http://www.frank-buss.de
electronics and more: http://www.youtube.com/user/frankbuss