dangerous NAND_BBT_SCANBYTE1AND6

[Ricard Wanderlof]

On Wed, 25 May 2011, Ivan Djelic wrote:

> Here is a relevant excerpt from a 2004 STM application note (AN1819):
>
>  RECOGNIZING BAD BLOCKS
>  The devices are supplied with all the locations inside valid blocks
>  erased (FFh). The Bad Block Information is written prior to shipping.
>  For 528 Byte/256 Word Page (NANDxxx-A) devices, any block where the
>  6th Byte/ 1st Word in the spare area of the 1st page does not contain
>  FFh is a Bad Block.  For 2112 Byte/1056 Word Page devices, any block,
>  where the 1st and 6th Bytes, or 1st Word, in the spare area of the 1st
>  page, does not contain FFh, is a Bad Block.
> ...
> <digression>
> The above note is probably not applicable to recent devices. Because bitflips
> are much more likely to appear, saying that a specific byte marks a bad block
> if it "does not contain FFh" it not realistic. ONFI 2.2 clarifies the issue and
> states that a marker is 0x00, not just a byte that "does not contain FFh".
> And recent Micron devices do not store markers in flash; they just return 0x00
> for any byte read in a bad block (instead of the real data), using an internal
> bad block table.
> </digression>

I'm probably wrong here, but I just want to throw this thought into the 
pot: I always thought that the reason for the 'not contain FFh' phrasing 
was that there could be something physically wrong in a bad block so that 
some bits could not be programmed to 0. Saying 'not contain FFh' would be 
a way of saying 'we try to set all bytes to 0 but if for some reason some 
bits are stuck at 1 still treat a non-FFh word as a bad block marker'.

This of course does not harmonize with ONFI 2.2. It's just me trying to 
read between the lines of the specs.

/Ricard
--
Ricard Wolf Wanderlöf                           ricardw(at)axis.com
Axis Communications AB, Lund, Sweden            www.axis.com
Phone +46 46 272 2016                           Fax +46 46 13 61 30