Charles Manning wrote:
> The best guide I have read is the Toshiba NAND flash applications design
> guide, available at various locations including
> http://www.edn.com/contents/images/ToshibaNANDFlash1.pdf
Thank you! that was _exactly_ what I needed. It answered all my
questions and even some I had not though of yet.
> I don't believe that there is any "read disturb". Once written, AFAIK
> only other writes are likely to mess things up.
Nope. See page 22 of the doc you pointed me to.
Read Disturb — In this failure mode, a read operation can disturb the
memory contents causing a “1” to change to
a “0.” The bit error occurs on another page in the block, not the page
being read.
Its non-permanent though an erase will fix it and _really_ unlikely.
The ROM section of the document discussed that in their testing it was
3ppm over 10 years. So 3 blocks out of every million blocks will have a
1 bit error in 10 years.
As you said the program-disturb is more common. Although still pretty
rare. 1E-10 or 1 bit per 10 billion
> YAFFS2 does no rewrites (ie only one write per page and no deletion
> markers.
Is YAFFS2 ready for production? I've been looking through the code and
I see a lot of FIXMEs and TODOs.
The no deletion markers is a bit confusing. I've not yet groked how
YAFFS2 does this. Care to enlighten me?
> NAND flash seems to be getting more reliable all the time. I did some
> accelerated lifetime testing where I wrote and verified over 100Gbytes
> of data without a single bit being damaged.
Good news. I'll bet the 1e-10 error rate is at the max rated operating
temp of the part. So in the normal temp range the error rate is
probably far lower.
> YAFFS direct is vanilla C and should compile fine for just about
> anything.
Excellent. Has anyone actually done it though?
Hopefully, with no weird niosII compiler bugs or linker problems.
> need about 1k of RAM per 1MB of NAND. Plus expenses :-).
> Hope that helps
>
Yes. Very helpful. Thanks again.
--
Richard A. Smith
Bitworks, Inc
(text/plain)