Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.sci.electronics > #255076 > unrolled thread

wie oft kann man NOR Flash lesen?

Back to article view | Back to de.sci.electronics

Contents

  wie oft kann man NOR Flash lesen? Frank Buss <fb@frank-buss.de> - 2019-03-30 10:42 +0100
    Re: wie oft kann man NOR Flash lesen? Christian Zietz <newsgroup.1001@chz.xyz> - 2019-03-30 11:23 +0100
      Re: wie oft kann man NOR Flash lesen? Stefan Reuther <stefan.news@arcor.de> - 2019-03-30 12:18 +0100
        Re: wie oft kann man NOR Flash lesen? Frank Buss <fb@frank-buss.de> - 2019-04-01 01:55 +0200
          Re: wie oft kann man NOR Flash lesen? Christian Zietz <newsgroup.1001@chz.xyz> - 2019-04-01 07:37 +0200
            Re: wie oft kann man NOR Flash lesen? Matthias Weingart <mwnews@pentax.boerde.de> - 2019-04-01 06:34 +0000
          Re: wie oft kann man NOR Flash lesen? Stefan Reuther <stefan.news@arcor.de> - 2019-04-01 18:21 +0200
            Re: wie oft kann man NOR Flash lesen? Frank Buss <fb@frank-buss.de> - 2019-04-09 23:47 +0200

#255076 — wie oft kann man NOR Flash lesen?

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

[toc] | [next] | [standalone]

#255079

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

[toc] | [prev] | [next] | [standalone]

#255080

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

[toc] | [prev] | [next] | [standalone]

#255149

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

[toc] | [prev] | [next] | [standalone]

#255152

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

[toc] | [prev] | [next] | [standalone]

#255154

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.
-- 

[toc] | [prev] | [next] | [standalone]

#255208

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

[toc] | [prev] | [next] | [standalone]

#255628

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

[toc] | [prev] | [standalone]

Back to top | Article view | de.sci.electronics

csiph-web