Olympus-OM
[Top] [All Lists]

Re: [OM] SD Stuff

Subject: Re: [OM] SD Stuff
From: Chuck Norcutt <chucknorcutt@xxxxxxxxxxxxxxxx>
Date: Sun, 24 Mar 2013 06:26:07 -0400
I bow to your vastly greater knowledge on SD cards (and their many 
variations).  I went off to the SD association's web site and was 
frustrated by reading the standards docs that said absolutely nothing 
useful... even about the the actual transfer speed indicated by, for 
example, a "class 10" device.

My only experience with SD cards is with SDHC cards of 16GB (2 years 
old) and 8GB (2 months old) capacities.  So I have missed all the 
incompatibilities which ensued from the closed and isolated development 
environment that characterized the smaller cards.

It appears that we really aren't allowed to know if our cards employ 
wear leveling or bad block management or how effective these really are. 
  But, since I'm forced to use SD cards, I think I'll stick with SDHC 
cards of 4 to 16GB capacity (avoiding 32GB where one might encounter 
SDXC as well as SDHC and more incompatibility).

As to reliability I guess we can only count on improving reliability of 
all NAND flash technology.  It seems that at least 100,000 erase cycles 
is now fairly standard and AMD/Fujitsu was promising 1,000,000 erase 
cycles as early as 2003.  Even 100,000 is much more than I need for any 
single flash card.

ps:  I've never had a flash card failure

Chuck Norcutt (who still prefers CF cards because they're bigger :-))



On 3/23/2013 1:56 PM, Ian Manners wrote:
> Hi Chuck,
>
> You will have to forgive me, I'm trying to keep it simple,
> and thats not always easy to do while keeping a reply short
> especially when I'm tired.
>
> Current SDD Drives do remap all faulty memory
> address's irrespective of there location, including faulty
> memory in the block allocation tables so that the device
> its connect to has no idea.
>
> As far as I'm aware the SD Card standard doesnt do this
> yet but I could be wrong on that, I havent kept up to
> date with it so if you say it does do it now I'll take
> your word on it.
>
> Bad block management is a relatively new feature in
> NOR chips
>
>> Dunno where you heard this.  Sounds like web lore to me.
>>   From the Wiki article on flash memory
>> <http://en.wikipedia.org/wiki/Flash_memory>
>
> Thought we were talking about SD cards, yes its all
> NAND <http://en.wikipedia.org/wiki/NAND_flash>
> but much depends on the controller and which parts
> of the SD standards are implemented.
>
> Up until SDHD/XC/IO the onboard controller was very
> basic, as far as I'm aware it only included the Serial
> Peripheral Interface (SPI), the SD Bus modes, and DRM
> functions (which was why it was called Secure Digital).
> The rest was left to the device that it was connecting to.
>
> <http://en.wikipedia.org/wiki/Secure_Digital>
>
> SD Cards site between the xD card (no controller onboard),
> and CF Cards (full controller on board).
>
> The early SD card controllers didn't do wear leveling,
> then they did wear leveling only for the data areas and
> storing the required mapping at the start of the card
> memory area.
>
> Also keep in mind that the area were the Bad Block Map
> is stored is the weak link. If a bad bit resides in this area
> many controllers (on the device using the card) couldn't
> remap the Bad Block Map, this area also includes the
> file allocation table.
>
> If you use a card with a problem in the FAT/Map area,
> this is why you can often read it and fix it on a computer,
> it's also part of the reason you can often read and view the
> files on a good camera but have corruption issues on another
> camera or non computer device (like a printer with an SD slot)
> much depends on the controller.
>
> Ignoring the fact the some of the cheaper cameras from
> China were using unlicensed SD forms which did not
> have all the correct implementions of the 'standard'.
>
>> NAND devices also require bad block management by the device driver
>> software, or by a separate controller chip. SD cards, for example,
>> include controller circuitry to perform bad block management and wear
>> leveling. When a logical block is accessed by high-level software, it is
>> mapped to a physical block by the device driver or controller. A number
>> of blocks on the flash chip may be set aside for storing mapping tables
>> to deal with bad blocks, or the system may simply check each block at
>> power-up to create a bad block map in RAM. The overall memory capacity
>> gradually shrinks as more blocks are marked as bad.
>
> What you say above is correct for the current SDHD cards
> as far as I'm aware, with the new smarts in SDXC and SDIO,
> prior to that they relied on a bad block map as part of the file
> structure. This is one of the reason's so many problems were
> occuring and I can only assume this, that Olympus and others
> didnt use SD cards (on top of the royalties they have to pay
> to use this format).
>
>> NAND relies on ECC to compensate for bits that may spontaneously fail
>> during normal device operation. A typical ECC will correct a one-bit
>> error in each 2048 bits (256 bytes) using 22 bits of ECC code, or a
>> one-bit error in each 4096 bits (512 bytes) using 24 bits of ECC
>> code.[22] If the ECC cannot correct the error during read, it may still
>> detect the error. When doing erase or program operations, the device can
>> detect blocks that fail to program or erase and mark them bad. The data
>> is then written to a different, good block, and the bad block map is
>> updated.
>
> The quality (differing) of what is in a SD card is well known,
> just as the differing quality of USB sticks.
>
>> Dr. (wear leveled and bad block managed) Flash
>
> Even the early SDD Drives didnt do wear leveling at
> all, it was left to people to write that into device drivers
> after the fact, now its all transparent on the controller.
>
> I'm sure that wasnt that many years ago, was it ?
>
> This caused absolute havok with operating systems that
> couldnt run the SDD providers manual wear leveling
> utilities back in the day. Like OS/2 and Linux.
>
> Cheers
> Ian Manners
> Of nowhere in particular.
>
-- 
_________________________________________________________________
Options: http://lists.thomasclausen.net/mailman/listinfo/olympus
Archives: http://lists.thomasclausen.net/mailman/private/olympus/
Themed Olympus Photo Exhibition: http://www.tope.nl/

<Prev in Thread] Current Thread [Next in Thread>
Sponsored by Tako
Impressum | Datenschutz