* NOR "bad blocks"
@ 2005-10-27 8:04 Bernhard Priewasser
2005-10-27 8:21 ` Jörn Engel
0 siblings, 1 reply; 5+ messages in thread
From: Bernhard Priewasser @ 2005-10-27 8:04 UTC (permalink / raw)
To: MTD mailing list
Hi all,
just a thought...
Same as NAND, NOR flashes mostly have an endurance of guaranted 100K
program/erase cycles.
If a block reaches this (theoretical) value, it should be recognized as
bad block if erase fails; e.g. not conaining only 0xFF after erase on
NAND. (I don't know if the "100K" erase cycle boundary is mostly
responsible for this)
But obviously a block can wear out on NOR too after the max. number of
erase cycles. (How) can this be recognized, handled?
--
Bernhard
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: NOR "bad blocks"
2005-10-27 8:04 NOR "bad blocks" Bernhard Priewasser
@ 2005-10-27 8:21 ` Jörn Engel
2005-10-27 8:31 ` Bernhard Priewasser
0 siblings, 1 reply; 5+ messages in thread
From: Jörn Engel @ 2005-10-27 8:21 UTC (permalink / raw)
To: Bernhard Priewasser; +Cc: MTD mailing list
On Thu, 27 October 2005 10:04:03 +0200, Bernhard Priewasser wrote:
>
> just a thought...
> Same as NAND, NOR flashes mostly have an endurance of guaranted 100K
> program/erase cycles.
> If a block reaches this (theoretical) value, it should be recognized as
> bad block if erase fails; e.g. not conaining only 0xFF after erase on
> NAND. (I don't know if the "100K" erase cycle boundary is mostly
> responsible for this)
> But obviously a block can wear out on NOR too after the max. number of
> erase cycles. (How) can this be recognized, handled?
Not easily. I haven't done the experiments myself, but wear-out
effects were described to me. Basically, you can write to a block and
read it back out in a tight loop and things will never fail. Not
after 100k, not after 1M erases. But if you write to the block and
wait long enough, bits will flip.
Bit-flipping will always happen from 0 to 1, similar to erases.
Problem should be that the insulation around a flash cell has eroded
and the charge will leak out over time - this cell is self-erasing
now.
And if you want to check whether all this is actually true, you can
try a testrun like this:
for (int i=1; ; i++) {
for (int j=0; j<1000; j++)
erase(block);
write(block);
sleep(10);
read(block);
if (read doesn't match write) {
printf("block died at %d000 erases\n", i);
break;
}
}
Jörn
--
Geld macht nicht glücklich.
Glück macht nicht satt.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: NOR "bad blocks"
2005-10-27 8:21 ` Jörn Engel
@ 2005-10-27 8:31 ` Bernhard Priewasser
2005-10-27 8:49 ` Jörn Engel
0 siblings, 1 reply; 5+ messages in thread
From: Bernhard Priewasser @ 2005-10-27 8:31 UTC (permalink / raw)
To: Jörn Engel; +Cc: MTD mailing list
> Not easily. I haven't done the experiments myself, but wear-out
> effects were described to me. Basically, you can write to a block and
> read it back out in a tight loop and things will never fail. Not
> after 100k, not after 1M erases. But if you write to the block and
> wait long enough, bits will flip.
>
> Bit-flipping will always happen from 0 to 1, similar to erases.
> Problem should be that the insulation around a flash cell has eroded
> and the charge will leak out over time - this cell is self-erasing
> now.
So this means that you have to hope that no block will wear out. And
count on JFFS2's wear levelling.
What are the reasons that cause NAND blocks to die before they would
"officially" wear out?
Dou you have a hint for good literature on this stuff (OK, let's better
say NAND and NOR flash memory in general)?
--
Bernhard
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: NOR "bad blocks"
2005-10-27 8:31 ` Bernhard Priewasser
@ 2005-10-27 8:49 ` Jörn Engel
2005-10-27 9:09 ` Bernhard Priewasser
0 siblings, 1 reply; 5+ messages in thread
From: Jörn Engel @ 2005-10-27 8:49 UTC (permalink / raw)
To: Bernhard Priewasser; +Cc: MTD mailing list
On Thu, 27 October 2005 10:31:34 +0200, Bernhard Priewasser wrote:
>
> So this means that you have to hope that no block will wear out. And
> count on JFFS2's wear levelling.
>From an engineering point of view: yes. With decent wear levelling,
all blocks will roughly wear out at the same time, which you can
calculate beforehand. You need to know your average write rate and
pick a device large enough to support that rate for your target
lifetime.
JFFS2 also has checksums, so when the bitflipping happens, it will get
noticed. But that doesn't mean that it is interpreted as bitflipping.
Most checksum errors are caused by unfinished writes during power
failure.
> What are the reasons that cause NAND blocks to die before they would
> "officially" wear out?
Dunno, not my area of expertise.
> Dou you have a hint for good literature on this stuff (OK, let's better
> say NAND and NOR flash memory in general)?
I'd doubt that there is even decent literature. Stuff is
big-business, but not sexy for research papers. Try finding an
unbiased explanation is such an environment. ;)
Jörn
--
Those who come seeking peace without a treaty are plotting.
-- Sun Tzu
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: NOR "bad blocks"
2005-10-27 8:49 ` Jörn Engel
@ 2005-10-27 9:09 ` Bernhard Priewasser
0 siblings, 0 replies; 5+ messages in thread
From: Bernhard Priewasser @ 2005-10-27 9:09 UTC (permalink / raw)
To: Jörn Engel; +Cc: MTD mailing list
> I'd doubt that there is even decent literature. Stuff is
> big-business, but not sexy for research papers. Try finding an
> unbiased explanation is such an environment. ;)
Hehe, you may be right...
But - no doubt - there should be some decent _book_ about basic
principles of flash memory. OK, let's serach...
--
Bernhard
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2005-10-27 9:09 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-10-27 8:04 NOR "bad blocks" Bernhard Priewasser
2005-10-27 8:21 ` Jörn Engel
2005-10-27 8:31 ` Bernhard Priewasser
2005-10-27 8:49 ` Jörn Engel
2005-10-27 9:09 ` Bernhard Priewasser
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox