MLC NAND: all 0xff after erase?

[Calvin Johnson]

On Wed, Aug 8, 2012 at 1:30 AM, Ivan Djelic <ivan.djelic at parrot.com> wrote:
> On Tue, Aug 07, 2012 at 11:08:04AM +0100, Calvin Johnson wrote:
>> 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 ?
>
> Hello Calvin,
>
> No, the bitflips I was referring to are not caused by an interrupted erase or program operation.
> They just appear when reading back an erased block. They sometimes exhibit a specific pattern: the same bit column is flipped on multiple
> pages in the same block.
>

Thanks a lot Ivan. From some experts, I got some more info about the
reason behind this behaviour. I'm sharing them below.

-------------------------------------------------------------------------------------------------------------------------------------------------------------
The memory array is composed of strings of cells and numerous rows of
parallel selection lines.  When the array is being read these lines
are energized.  Granted, it is a low voltage.  But, as you know, any
electrical potential difference introduces the possibility of electron
migration.  At the current geometry technology, we’re only storing
about 100 electrons on a gate (That’s not a spec’ed count).  If you
multiply even a small possibility times 16,000,000,000 bits and a
large number of reads, it’s not unreasonable to expect an occasional
bit shift.
-------------------------------------------------------------------------------------------------------------------------------------------------------------
it is due to the fact that some bits are not well inside the
distribution of the programmed cells.
Some bits are not "substituted" because can be corrected by the ECC,
but when programmed they are in the edges of the distribution and can
be read differently.
Obviously this “not screened” bits can be managed and corrected using
the specified ECC .
-------------------------------------------------------------------------------------------------------------------------------------------------------------

best regards,
Calvin