NAND Flash bad blocks in Windows CE 5.0
paolo patierno
I'm working with Windows CE 5.0 and I have a problema related to bad blocks
in NAND Flash.
My FMD driver implements all the functions for reading/writing on the NAND
Flash.
My question is the following : does the FAL manage the NAND Flash bad blocks ?
If a write operation fails, the FAL will mark the block like bad ?
I'm using FAT File System.
Thanks,
Paolo
Dean Ramsier
--
Dean Ramsier - eMVP
BSQUARE Corporation
"paolo patierno" <paolop...@discussions.microsoft.com> wrote in message
news:4FA6EEC7-5B29-4EAC...@microsoft.com...
paolo patierno
where I can found the source code of FAL ?
R. de Gravelaine
> where I can found the source code of FAL ?
C:\WINCE600\PRIVATE\WINCEOS\DRIVERS\MSFLASH\SRC
paolo patierno
Thanks,
Paolo
R. de Gravelaine
I don't think the source is available in CE 5.0 but if you have the 6.0
sources available, I think it should be very close and easily adaptable
to 5.0.
HTH
Remi
Andrew at Plextek
Hello Paulo,
Can you be a bit clearer about your "Bad Block" problem. NAND is quite
a complex beast and there is more than one failure mode to do with
NAND...
1. When a NAND part is shipped, it will contain a number of blocks
that the manufacturer has marked as bad. This is done by clearing a
byte in the spare area of some of the NAND pages in the device. How
this is done is, unfortunately, down to the manufacturer, although
larger parts are now standardising on the "Open NAND Flash Interface".
These are the most prevalent types of bad blocks that your block
driver needs to be aware of... never erase these blocks, or you lose
the manufacturers bad block marks and then you have a very unreliable
flash filing system.
2. In use, a NAND part can develop a bad block, this is one where when
instructed to erase, or write a block, the NAND part indicates an
error has occurred to the NAND Flash Controller. This is a real bad
block error, and your NAND Flash block driver needs to report this to
the FAL so that the FAL can mark the block as bad.
3. When you perform a write operation to NAND, you can induce a soft
error in the block that is being programmed (which you will only
discover on a later read within that block). There are two mechanisms
that do this: OVER PROGRAMMING will report a successful write for a
bit to 0 on the target page, but will cause that same bit position on
every other page in that block to read back as 0; PROGRAM DISTURB is a
random bit change in any page of the block being programmed. OVER
PROGRAMMING can be eliminated by only writing to a page the
recommended number of times before erasing it (typically 2-4 times).
Soft errors are why ECC is required for NAND. Soft errors occur at a
very low rate (typ 1 bit per 10 billion bits programmed to 0 for SLC
NAND) and with ECC this means that the likelyhood of seeing one of
these is remote - roughly once per 25 devices over the entire lifetime
of the NAND flash parts. Soft errors are not bad blocks, the block can
be completely recovered by a block erase, and you, as a programmer are
unlikely to see them during your testing.
4. There are different NAND parts, and they require different levels
of ECC. Single Level Cell NAND parts (SLC) are the type of NAND that
has been available for some time. Most hardware NFCs support an ECC
scheme in hardware that is suitable for these parts. Multi Level Cell
(MLC) NAND devices are a newer (cheaper) technology which uses fewer
transistors but has a much higher soft error rate. These require a
stronger ECC scheme and a lot of NFC's don't suppor this in hardware,
you either can't use MLC parts or you have to disable the hardware ECC
and implement this in software (slow and difficult).
So, it is important in your block driver to adhere to the following:
- respect and preserve the manufacturers bad block marks, report these
correctly to the FAL
- if your NFC ever fails a write or erase, report this to the FAL as a
bad block
- ensure that ECC is implemented correctly for your NAND part (MLC
NAND needs stronger ECC than SLC NAND so check that your NFC supports
the correct ECC for the NAND part you are using)
- if you ever get a soft error on read, report the read error to the
FAL, but this is NOT a bad block.
Regards,
Andrew.
paolo patierno
Can you give me the source ?
Thanks,
Paolo
R. de Gravelaine
wouldn't be a problem...
You should try another way, for instance by loading an evaluation
version of CE 6.0 and installing it on another machine.
Sorry.
Remi
paolo patierno a �crit :
Andrew at Plextek
sys.fr> wrote:
> I am not sure this would be legal, unless someone here explains why it
> wouldn't be a problem...
> You should try another way, for instance by loading an evaluation
> version of CE 6.0 and installing it on another machine.
> Sorry.
> Remi
>
>
>
>
> > No, I haven't installed Windows CE 6.0.
> > Can you give me the source ?
> > Thanks,
> > Paolo
>
> > "R. de Gravelaine" wrote:
>
> >> > I have Windows CE 5.0....is it the same ?
>
> >> I don't think the source is available in CE 5.0 but if you have the 6.0
> >> sources available, I think it should be very close and easily adaptable
> >> to 5.0.
>
> >> HTH
>
> - Show quoted text -
Paulo,
You really don't need the FAL source code - the FAL is doing what it
should about bad block, it's your FMD driver that will be the problem,
probably because it is handling bad blocks and errors incorrectly.
Basically, for the FAL bad block management to work correctly you need
to do the following:
- implement FMD_ReadSector(), if you get an uncorrectable ECC then
return FALSE (unless you are testing for a very, very, very long time,
you should not see any uncorrectable ECC errors)
- implement FMD_GetBlockStatus(), ensuring that you correctly return
BLOCK_STATUS_BAD for a block marked by the manufacturer as bad.
- implement FMD_SetBlockStatus() so that you can mark blocks as bad
- implement FMD_EraseBlock() ensuring that, before it erases a block,
it checks to see that it *has not* been marked as bad by the
manufacturer. Return FALSE if the NFC reports a failure to erase
- implement FMD_WriteSector ensuring that, this also first checks to
see if the block it is in has been marked by the manufacturer as bad.
Return FALSE if the NFC reports a failure to write.
A common mistake that I have seen in a couple of BSPs is that the test
for the manufacturers bad block mark is done with ECC on. This should
be turned off for this test.
You also say that your write operation is failing - this should be a
very very very infrequent error case in real life testing, unless you
are ignoring the manufacturers bad block marks.
Regards,
Andrew.
Paul G. Tobey [eMVP]
they specifically deny you the right to ship CE6 source code around...
Paul T.
"R. de Gravelaine" <g_r_a_v_e_...@aton-sys.fr> wrote in message
news:%23ONjWLP...@TK2MSFTNGP04.phx.gbl...