I have not come across that with these parts, however it is most likely there.
The question would be if it is accessible from the standard interface. Perhaps
if the card is in jtag mode it would show up. The development group at SanDisk
must have a way to look at failed cards to understand why they failed short of
etching the plastic off of the silicon. I will dig around and see if I can
find it.
Bobby
----- Original Message -----
From: Jim Donelson
To: uClinux development list
Sent: Thursday, March 26, 2009 9:27 AM
Subject: Re: [uClinux-dev] SD card corruption upon reboot and de-power
Read: ProdManualSDCardv1.9.pdf
I never saw any such commands or status,
2009/3/26 Bobby Clark <[email protected]>
There were a number of patents issued to SanDisk starting in the early 90's
for flash wear leveling. One of the more recent ones is 6,985,992. The
methods disclosed are simple counts of usage and block or byte moves. Most of
it centers around pointers. I suspect that the wear leveling happens in a few
machine cycles after the write command is given. It is highly unlikely that
the wear leveling mechanism could be causing data corruption unless the power
is cut right after the command is given to write the data. Even then it would
need to happen very quickly to effect the write. Again one way to prove it
would be to run a series of test. Knowing the patent contents we could most
likely determine what method they were using. There is also most likely a
debug interface in to the system. One can probably get access to the written
block data and replacement cells available counts.
Bobby
----- Original Message -----
From: Bobby Clark
To: uClinux development list
Sent: Thursday, March 26, 2009 9:26 AM
Subject: Re: [uClinux-dev] SD card corruption upon reboot and de-power
Based on a 4MB zone and a 3 % reserve block there would be 120k bytes of
reserve bytes per 4MB zone. According to the doc the pool is a random
assortment per zone. It all comes down to how fast 120k bytes wear out.
Modern hard drives have a reserve pool and replace sectors or tracks that are
predicted to fail or have failed automatically. The SanDisk method seems to be
a good compromise to extend life for a simple system like the flash cell. I
suspect that the implementation is fairly simple. A search of the patent
office might reveal the raw details.
Bobby
----- Original Message -----
From: Michael Schnell
To: uClinux development list
Sent: Thursday, March 26, 2009 7:05 AM
Subject: Re: [uClinux-dev] SD card corruption upon reboot and de-power
If this is true for a current card the OS would have a direct
influence on life
Right !
FAT is abysmal.
-Michael
------------------------------------------------------------------------
_______________________________________________
uClinux-dev mailing list
[email protected]
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by [email protected]
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
--------------------------------------------------------------------------
_______________________________________________
uClinux-dev mailing list
[email protected]
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by [email protected]
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
_______________________________________________
uClinux-dev mailing list
[email protected]
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by [email protected]
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
------------------------------------------------------------------------------
_______________________________________________
uClinux-dev mailing list
[email protected]
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by [email protected]
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev_______________________________________________
uClinux-dev mailing list
[email protected]
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by [email protected]
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
