I'm using a microSD card in an embedded system which use a microcontroller interfacing with the microSD card using SPI. I do raw data write, without a file system. Every time that I want to store data, I write an entire block of 512 bytes. I write for example, one 512 byte packet to the sector each 10 minutes. I would like to know how many times I can write the same sector.

I won't use always the same sector to store data, I'll use around 300 sectors to store the data, writing one entire sector per data packet write, being the sector number incremented sequentially. Let supose I have a sector range from 0 to 299 to store the data, when I write for the first time the sector 0 will be written, then sector 1, 2, 3 and so on until it reaches the write to the sector 299, then the next write will be at sector 0 and the cycle (sector 0~299) starts again. I'll do this way because the only data that matters for me will be on the last sector written, and I'll use a incremental 32 bit (4 byte) number to identify what was the last sector written (which will be stored together in the sector). I'm going to use this technique but anyway I need to know what is the minimum endurance of a sector, that is, I need to know how many times I can write the same sector entirely (at the minimum). I'm understanding that the minimum number of sector writes that I can do with security will be 300 x 'the sector endurance'.

I know there are consumer and industrial cards. Consumer cards use TLC cells, and industrial uses MLC and SLC cells. I plan to use a commercial one due to the cost per product. According the Kingston document below, the number I'm searching is 500, but for me it sounds too small, because on many forums people say that the endurance is 10.000 write cycles at minimum. Somebody know what should be the correct minimum number of times that I can write the same sector number entirely?

---> According to this file from Kingston, on page 3:

For Multi-Level Cell (MLC) Flash, up to 3000 write cycles per physical sector based on current lithography process (19nm and 20nm) at the time of this writing. For Single-Level Cell (SLC) Flash, up to 30,000 write cycles per physical sector. For Triple-level Cell (TLC), up to 500 write cycles per physical sector. Lithography of the Flash. Memory Die plays a key role in cell endurance and decreases as the size of the die gets smaller


---> People saying 10.000, 100.000 write cycles

https://superuser.com/questions/159602/max-read-writes-to-an-sd-card https://www.raspberrypi.org/forums/viewtopic.php?t=21281


I'm using Hex Workshop software to check the content of each sector of the card, in the picture below I stored 1,2,3,4 + 508 bytes with value 0 to the sector 1 (and I'm able to write the same sector again with new values without using any erase operation in my code), BUT I don't know if that's the physical or logical sector that's being shown on the software...

I would like to know how can I store data to the SD card without a file system (writing the way I'm doing with the MCU), in a manner that I can write many many times on the card, for example, around a million times or more. Or the best way to achieve this is by using a file system (supposing I use only one file and always overwriting it)?

Hex Workshop shows this



2 Answers 2


how many times I can write the same sector entirely

You can't.

The memory controller will employ internal wear levelling and you have no way to force it to write to a specific physical sector. If you make sure the card is in fully erased state before deployment the memory controller will have plenty of room for wear levelling and will spread your writes over all of the card, so your 300 block writes will last a long time before the same physical sector actually gets overwritten just once.

In fact, if you limit yourself to a low number of (logical) blocks you ever write to, like those 300, ("over-provisioning") you make it even easier for the controller to do wear levelling: As soon as you overwrite a logical block the controller knows that the previous data in the corresponding physical block is no longer needed and can not only allocate a new physical block for your write but also mark the old physical block as unused and available for wear levelling. Thus you won't even have to issue ERASE commands yourself for blocks you no longer need. If you'd write data to all blocks on the card before starting over, the controller will not know that you actually don't need the data in 99% of the card's memory anymore and will have less room for wear management.

I would like to know how can I store data to the SD card without a file system (writing the way I'm doing with the MCU), in a manner that I can write many many times on the card, for example, around a million times or more.

Easy: First make sure the card is ERASEd, e.g. by sending ERASE commands when setting up the card for the first time. Then restrict yourself to leaving some free, erased, space on the card at all times. This goes by the name of "over-provisioning", i.e. deploying a card which has more memory than will actively be used.

Example: Say you have an 8GB card (16 million blocks), initially fully erased. If you only ever write to, say, the first 300 blocks in the address space (=150kB), you could re-write those 300 blocks 16000000/300 ~ 53000 times before every block of the physical memory is written to even once. So if you have only 500 writes per physical location that would still mean 500x53000=26.5 million writes to each of the 300 blocks you use. (That's of course assuming that a) writes are actually spread over all of the available space and b) that each memory location has the same level of wear levelling. Both assumptions may not be completely true because the memory controller may be more or less clever in spreading wear, e.g. by doing more to reduce wear on blocks which are expected to be written to more often on common filesystems, like the file allocation table.)

  • \$\begingroup\$ Thanks for your answer, I didn't understood your reply so well, I think now I have even more doubts. I've edited the original post with a related doubt, could you help on it? I'll read about wear leveling trying to better understand your reply and return later. Thanks. \$\endgroup\$
    – abomin3v3l
    Feb 4, 2019 at 17:26
  • \$\begingroup\$ @abomin3v3l it's not really permitted to expand a question after it has been answered. Also your expansion seems to miss the key point of this answer - the card won't let you at the actual physical blocks, as what the interface present as physical blocks are actually above the flash translation layer. And while the flash translation layer may seem to make life simple, it also introduces a point of failure which is out of your control - if the FTL built into the card gets confused, you can loose the whole thing, not just the block or partition you thought you were operating on. \$\endgroup\$ Feb 4, 2019 at 17:40
  • 1
    \$\begingroup\$ @abomin3v3l As Chris Stratton says, the memory controller on the card will not let you see the 'real' physical blocks. When you send a write command to e.g. the 'logical' block at address 0 the card's controller will select some physical location in the flash memory to put the data into. When you write to that 'logical' location again, the controller will likely select some other physical location of memory to store the data. You have no way to know or influence where on the chip the data actually resides. The confusion may come from the fact that e.g. an operating system will refer to the \$\endgroup\$
    – JimmyB
    Feb 5, 2019 at 9:07
  • 1
    \$\begingroup\$ card's interface as physical blocks, as opposed to the logical blocks and clusters of partitions and file systems. But internal to the card there is the memory controller which, invisible from outside the card, will re-map what you or the OS sees as 'physical' blocks to varying locations in the actual flash chip. So a 'physical' block as seen from outside the card is not really a (single) physical location on the memory chip. \$\endgroup\$
    – JimmyB
    Feb 5, 2019 at 9:10
  • 1
    \$\begingroup\$ @JimmyB Now I understand what you said in the previous replies. Thanks for your support. From yesterday to today I left the MCU writing continuously to the sector 1 of SD card, it were 1.1 million writes to the sector 1 and I'm still able to write data correctly to sector 1. The card is new (SanDisk) and there many logical sectors that were never writen. As my understanding now, the less number the logical sectors I use, the more space will be available for wear leveling. \$\endgroup\$
    – abomin3v3l
    Feb 5, 2019 at 10:42

SD card and flash drive have some simple wear levelling, that if you write to the same sector, it will be written across some small block of physical sectors, on my pendrive it's 2MB. Also, the basic erase sector size is 4kb and not 512b. So if you write 4 sectors one after another, you are erasing and writing the same virtual 4kb block 4 times. Ideally, you would get bigger drive and make 2MB or 4MB spaces between each 4kb sector so that the drive can do the wear levelling. However it's hard to guess how drive wear levelling works and what blocks it is using (it's possible to measure it out of write timings), so ideally you would perform some sort of simple wear levelling yourself. Simply allocate first 100M to the table you would store where are the current sectors and write there in circular fashion (so on the boot you need to scan entire 100M table so this way you avoid overwriting the same sector there). Delay updates to this 100M array, so for each minimum 20 writes to sectors, make one write to this table. Then, also in circular fashion, write sectors to the drive in linear way, like you write a sector 4kb and then another sector is after it until you write the entire card and then start from the beginning. This way you have practically infinite number of writes of little 4kb sectors.

Overwriting the same sector (or rather, block) is different across various cards and flash drives, some have much better wear levelling, so you can write single sector many more times than on most cheap cards. Even same cards of the same line and marketing information may be different every few months. The bigger the local area card is using for wear levelling the better. and I am thinking that the bigger cards will have bigger those wear levelling areas so therefore should be more resilient to same sector writing, while on the cheap cards this block of wear levelling will be small and therefore it will break much sooner. This block is like 2MB of continuous physical flash and sector numbers you are matched to physical ones, so if you write the same sector, it will be written in different physical sector each time you make a write, but only if they are not used (you write only to one sector in 2MB block).


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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