ECC byte 4 and 5 not equal to what have just been writen

Charles Manning manningc2 at actrix.gen.nz
Tue Apr 20 04:24:46 EDT 2004


A lot of what happens here will depend on what ECC options you have enabled. 
Likely the mtd is applying ECC and stomping on what you have written.

Also note that NAND flash writes result in the AND of the previous data 
pattern and the newly written pattern. You might like to do a read before the 
write to check that everything is FF first.

-- CHarles

On Tuesday 20 April 2004 19:35, Shen Aaron-r62966 wrote:
> Hi,
>
>   Is there anyone aware of such problem about ECC?
>   When I read back the OOB data after writing to a page, I find the offset
> 06 and 07 are not equal to what have just been writen into the page.
>
>   The part of codes are :
> ==========================================
>   ......
>   // char spare[16] is for oob data in spare area
>   mx2_write_ecc((char*)p, spare, last);		// My function to set the
> spare[16] before write a page printOut("The spare[ ] to write in flash is
> :\n");	// Messege printed out printOut(spare);					// Print out the spare[
> ]
>   if(NAND_Write_OnePage(page, (char*)p, spare))	// Write the page with
> spare[ ] into NAND flash return;
>   NAND_Read_OOB(0, page, spare, 16);		// Read back the oob data into spare[
> ] printOut("The spare[ ] to read back from flash is :\n");
>   printOut(spare);					// Print out the spare[ ]
>   ......
> ===========================================
>
>   While, I got the follow output:
> ===========================================
> ......
> The spare[ ] to write in flash is :
> spare[00] = 56
> spare[01] = 5A
> spare[02] = 6B
> spare[03] = 66
> spare[04] = 00
> spare[05] = FF
> spare[06] = A6
> spare[07] = 9B
> spare[08] = FF
> spare[09] = FF
> spare[0A] = FF
> spare[0B] = FF
> spare[0C] = FF
> spare[0D] = FF
> spare[0E] = FF
> spare[0F] = FF
> The spare[ ] to read back from flash is :
> spare[00] = 56
> spare[01] = 5A
> spare[02] = 6B
> spare[03] = 66
> spare[04] = 00
> spare[05] = FF
> spare[06] = C0
> spare[07] = 33
> spare[08] = C3
> spare[09] = A9
> spare[0A] = 02
> spare[0B] = FF
> spare[0C] = FF
> spare[0D] = FF
> spare[0E] = FF
> spare[0F] = FF
> ......
> ===========================================
>
>   As you may have found out, the spare[0]~spare[5] are the same as writen.
> But spare[6] and spare[7] are different, while spare[8], spare[9] and
> spare[A] are so strange.
>
>   This will cause the failure of ecc correction for the upper 256 bytes of
> data in each page. Can you give me some comments?
>
>   Is this a known problem of NAND_Read_OOB( )?
>
> Thanks.
> Aaron
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/



More information about the linux-mtd mailing list