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