MLC NAND: all 0xff after erase?

[Calvin Johnson]

Hello Ivan,

>
> >>Due to the nature of NAND bitflips, I cannot see how a NAND datasheet
> >> could guarantee such a thing (what would be the duration of a "0xff
> >> guarantee" anyway ?). In practice, bitflips do appear already on 34nm SLC
> >> devices, on blocks that have just been erased; hence I am not surprised
> >> by your own findings on MLC devices.
>

Are these bit flips occurring due to power fluctuations while
performing program/erase as mentioned in
http://www.linux-mtd.infradead.org/doc/ubifs.html#L_unstable_bits ?

If that is the case, I am observing a different problem with a MLC NAND flash.

I wrote 4K bytes of data and read back the same 4K several times. The
page size is 4K. I am NOT performing multiple erase/programs. Please
note that I am reading back the same data which sometimes matches
exactly what was written and sometimes does not, showing bit flips at
random locations.  I am not using any ECC to correct the bit errors,
which of course will be done later as I'm trying to understand this
problem.

Is this behavior expected in MLC NANDs? Is there any reference
document/links which discuss more about this?

I have read about  read disturb errors but as I understand it is a
permanent error.(http://www.klabs.org/richcontent/MemoryContent/nvmt_symp/nvmts_2002/docs/12/12_dan_p.pdf
)
----------------------------------------------------------------------------------------------
Read Disturb Errors
The read disturb effect causes a page read operation to induce a
permanent, bit value change in one of the read bits. In BLC flash
technology based on a 0.16μ manufacturing
3 process, the typical read disturb error rate is on the order of 1
bit error per 106 repetitive reads of the page containing the bit.
Although MLC cells are more prone to such errors, the effect in actual
measurements is less severe than in program disturb errors. The
measured rate is on the order of 1 bit error per approximately 105
repetitive reads of the page.
----------------------------------------------------------------------------------------------

Thanks,
Calvin