Electrical Engineering Stack Exchange is a question and answer site for electronics and electrical engineering professionals, students, and enthusiasts. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I can't find any reliable information about this. I don't have the full specification of the SD/MMC Card hardware.

Is it true? My high-level application doesn't need to be concerned with wear leveling when working with these cards?


Could someone confirm that wear leveling is guaranteed by the SD specification? I want to be sure, because it looks like most vendors do it, but it is not required by the specification.

share|improve this question
Not all flash media manufacturers invest in wear leveling algorithms. Wear leveling is more prevalent in SSDs where the manufacturers lead the market because of algorithms. – Chetan Bhargava Feb 14 '13 at 5:15
up vote 25 down vote accepted

I work for a company that used to be a member of the SD association, we are familiar with the 2.0 (SDHC) spec. The SD card spec has NO entry for wear leveling. That is completely dependent on the SD manufacturer to handle that if they so choose. We have seen that some likely do, while others very much do not (beware the super cheap knock-off SD cards). SDXC may have changed that to include wear leveling, but I am unsure of that. Unfortunately the only way to really show that is to get your hands on the official spec. You can find it online most likely, but the SD association really wants you to pay for it.

As a side note, taking a 2GB card and writing it beginning to end over and over again averages about 10TB before the card is dead and no longer is writable. Also, SD cards will not let you know when data is bad, i.e. wont return an I/O error like a PC harddrive will. This might not be an issue for embedded designs as 10TB is a LOT of data, but it could be a factor for someone.

share|improve this answer
I assume that even though it isn't in the spec, companies still want to do it to keep their reputation good. While super cheap knock-offs don't care about reputation, they sell to people who look to go cheap on everything. Does this sound reasonable? – Kellenjb Mar 5 '12 at 22:25
@Kellenjb It is a very reasonable assumption, and I personally would agree with you. However, because it is not in the spec, and it's very unlikely to gain access to any particular manufacturer's SD controller designs, it can't really be proven. We have done a lot of testing over the years, some major brands do perform much better than others. It could be differences in internal algorithms or complete lack of them. – Kris Bahnsen Mar 5 '12 at 22:36
Cheap knockoffs aren't going to care even if it IS in the spec. It's not immediately visible to the customer, it COULD be missing. We're talking about people who sell lead plugs as ICs. I haven't heard of a name-brand card that didn't do wear leveling, but I suppose it's possible. – darron Mar 5 '12 at 22:40
Thanks for this complete answer. – haole Mar 5 '12 at 22:55
@fredbasset, way to zombie the thread ;) Its been a while since I did any SD card work. However, IIRC SD cards themselves will physically return whatever they feel like. Some of the newer ones combined with decent drivers may be able to detect an IO error. However may of the older SD cards will just return bad data that was stored in NAND and call it good. Though, if a write is not able to complete, that will return an IO error. – Kris Bahnsen Jun 13 '14 at 5:50

It's true! MicroSD cards contain a NAND flash chip bonded to an (ARM) microcontroller encapsulated in some black plastic. http://www.bunniestudios.com/blog/?p=898 explains.

At the end of the follow-up post http://www.bunniestudios.com/blog/?p=918 Bunnie posits integrating the controller probably costs less than testing the flash ahead of time.

Quoting the SD card product manual: "1.9 Wear Leveling. Wear leveling is an intrinsic part of the erase pooling functionality of the SD Card, using NAND memory." You can read the whole thing on digikey as the datasheet for a SanDisk brand full-size SD card: http://media.digikey.com/pdf/Data%20Sheets/M-Systems%20Inc%20PDFs/SD%20Card%20Prod%20Family%20OEM%20Manual.pdf

share|improve this answer
Bunnie Huang is definitely credible enough for me! – vicatcu Mar 5 '12 at 18:09
That's good to know, but I'll wait for someone that can enlighten this question based on the formal specification of this technology. – haole Mar 5 '12 at 19:07
Digikey showed me this useless SanDisk brochure when I tried to look up a datasheet. The Wintec and Swissbit datasheets were better, and both mentioned wear leveling. Can you link to that Digikey-hosted datasheet? – Kevin Vermeer Mar 6 '12 at 18:36
Those are way better than the old SanDisk one. – joeforker Mar 6 '12 at 19:12
The Wintec wasn't great, but the new SanDisk one is the best of the bunch! Thanks for the edit. – Kevin Vermeer Mar 6 '12 at 20:09

Yes, SD/MMC cards have controllers that do wear leveling. If they didn't, you could destroy one in a matter of minutes with the wrong write patterns.

That's actually a problem for some embedded projects. There's absolutely no way (apparently) to know what sectors might be wear leveled at any time, so a power cycle at the wrong time can destroy data anywhere on the card, no matter where you THINK you're writing. (don't ask how I know :) )

SD cards must be used with a system that guarantees a clean system shutdown (or at least that writes are allowed to complete), or data loss will (eventually) result.


The problem is that the wear leveling process is entirely hidden. ANY sector on the disk could be moved at any time (swapped with the page written), and if power was to fail in the middle of that process that random sector could get corrupted.

While there ARE reasonably safe ways to implement this move, it's not in any spec so you can't trust that the card will do it. You could test one card, have it work, then the manufacturer could change the implementation without changing the part number and you're screwed.

From testing, my SD cards' controller does NOT do this in a safe manner at all.

I may look into a "high reliability" SD card I saw advertised specifically for power failure tolerance... but then you have to trust the manufacturer to do that correctly, and I don't. I really want direct control over page erases. I'm still trying to figure this one out.

share|improve this answer
See my posted answer. Since wear leveling algorithms are up to the manufacturer, they might not be up to snuff. A good wear leveling algorithm will move the data first, then mark that data good, then garbage collect the original data. This might be an issue on some cards, maybe not others. SD is a very ugly design when you get to the bottom of it. – Kris Bahnsen Mar 5 '12 at 22:16
Yeah, it's a crap standard as far as I'm concerned. It's very annoying that such a ubiquitous memory storage standard would be so inherently unreliable. – darron Mar 5 '12 at 22:43
@darron, do you have some more information about this issue? This is a severe thing but I don't think it is widely known. – jpc Mar 6 '12 at 11:47
@jpc: Maybe I'll do a blog entry then. I'm getting the impression it's not considered often. I didn't realize the implications myself until it was too late. I fought with this, talked with my SD card manufacturer, etc. No solution other than to minimize write time. I now write to NAND flash, and copy to SD once a day as quickly as I can. There ARE SD cards designed to be "resistant" to random power failures, but I'm not sure even these are completely trustworthy. – darron Mar 6 '12 at 15:38
@freq basset I'm using UBI & UBIFS. It seems to work well... I've had a lot of systems running for years now with no problems. – darron May 24 '14 at 16:32

Any type of SD card using any type of conventional NAND flash memory is going to have to use some type of sector virtualization, since no conventional NAND flash device can support erasure of individual 512-byte sectors, and no conventional NAND flash device of significant size would be able to yield performance that was within an order of magnitude of being even marginally acceptable if every attempt to write a sector required the device to copy all the sectors in that sector's erase block (even to RAM), then erase the block and write all the sectors back. Most sector-virtualization techniques are inherently somewhat wear-leveling. I would expect the biggest issue of variance between quality devices and knock-offs will be the extent to which a device actively tries to even out the leveling between blocks, versus simply using pseudo-random block allocation and hoping that will yield acceptably close-to-uniform results. In practice, I would expect that even random/hope-for-the-best allocation would be adequate in most cases.

share|improve this answer
It very well might be that the "wear leveling" some manufacturers implement is caused by the NAND interface itself and block to sector/sector to block virtualizations. – Kris Bahnsen Mar 6 '12 at 0:09
@KrisBahnsen: I would expect that manufacturers which claim wear leveling will actively monitor the relative wear of different blocks and age of the data therein, and if blocks with long-lived data are found to be in blocks with much less wear than average, the data from those blocks will be moved into blocks that had more wear (so as to, most likely, minimize future wear on those blocks). This could improve by a factor of 10 the useful life of a device that's 95% filled with data that never changes, while the remaining 5% of space is churned frequently. – supercat Mar 6 '12 at 21:25
I agree, if they are advertising it I imagine they would do some kind of real wear-leveling. I am a bit negative on the whole subject which I do apologize for; I've been bitten a few times by the quirks of SD. – Kris Bahnsen Mar 6 '12 at 22:02
@KrisBahnsen: The biggest problem I think is a virtualization model which assumes a linear bunch of consecutively-numbered 512-byte sectors. It may have been convenient to interface with DOS, but it doesn't really fit well with the hardware that exists, nor with what the host software really wants. Open up block numbers to 64 bits and allow them to be arbitrarily non-consecutive, and then arrange to have files always stored in logically-consecutive blocks. To delete a file, delete its range of blocks. – supercat Mar 6 '12 at 22:56
This is possibly the best answer. I suspect this is how all of them do it. If you think about it, there is no way to do deterministic wear leveling with any kind of truly sophisticated algorithm because the wear history itself would have to be stored somewhere on the same card and that part would fail first. Randomized leveling is the only practical possibility. I am not convinced SSD's are any smarter. They may simply have more replacement buffers, though it is certainly within possibility that they store very coarse (and hence infrequently updated) wear information. – Nimrod Jan 2 at 9:08

Sandisk have a white paper that explains the wear levelling logic in their cards, and goes on to give estimates of the card's life under a number of scenarios. Executive summary: unless you are hammering the card non-stop, it will last decades.

share|improve this answer
Link is dead and the content seems to have been expunged -- because it revealed too much, perhaps? – Cuadue Aug 12 '14 at 16:04
@Cuadue The link is accessible. Just in case it breaks, the page is archived now at web.archive.org/web/20150326122100/http://ugweb.cs.ualberta.ca/… – Lekensteyn Mar 26 '15 at 12:21

Its interesting to note that despite this a lot of devices do corrupt SD and microSD cards especially high density ones if the battery is low or the phone crashes/shuts down/etc. I suspect that the problem is inadequate regulation of the voltage supply as this is well known on some cards (cough Adt /cough) to result in the phenomenon of an unreadable card on certain external readers but works fine on the micro variety supplied by some computer shops.

I am in the process of recovering a card at the moment with this fault, strangely enough most of the data is recoverable but some sectors are not though this changes on each attempt. Could the wear leveling itself be at fault? (yes tried multiple readers, same fault!)

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.