I got some feedback from our software team. Apparently we're writing twenty 4KB blocks per second. I have a 4GB eMMC. The eMMC has a max number of P/E cycle of 3000.

I'm making the assumption that all 4GB will be available for writing/erasing.

I developed a spreadsheet to help me calculate endurance but it's coming up with a time longer than I would have expected.

  • eMMC Size: 4GB
  • Number of days used: 365
  • Hours per day: 8
  • Max P/E cycles: 3000
  • Number of blocks per cycle: 20
  • Size of block: 4KB
  • Number of writes per second: 1

I calculated 14.9 years endurance by taking the total number of bytes written per year and dividing it by (eMMC size x Max P/E cycles).

I calculate endurance at the end of the file. Am I doing it right or wrong?

  • \$\begingroup\$ Could you put the calculated time into your question and include the formulas? There's plenty of folks who won't download an Excel file. Some won't because its too much hassle to download and open, and others won't because they don't like downloading files from unknown sources. \$\endgroup\$
    – JRE
    Feb 23, 2016 at 15:26
  • \$\begingroup\$ Sure thing... will do. \$\endgroup\$
    – Samee87
    Feb 23, 2016 at 15:27
  • 1
    \$\begingroup\$ I come up with 4.75 years: 3000*(4GB/(20*4kB))/(60*60*24*365) \$\endgroup\$
    – JRE
    Feb 23, 2016 at 15:33
  • \$\begingroup\$ Is your expectation that you would start seeing fails after more than 3000 P/E cycles ? I guess the number 3000 comes from the datasheet ? If coming from the datasheet I assume it is a manufacturer expected minimum which they are prepared to guarantee. The average number of cycles after which an average sample would start to fail could be much higher. A factor 2 or more would not surprise me at all. The memory cells wear out, this is quite unpredictable. It might be worse at high temperatures, you are probably testing at room temperature. \$\endgroup\$ Feb 23, 2016 at 15:33
  • 2
    \$\begingroup\$ That is, however, a naive estimate that ignores what happens when the blocks don't fit the block size of the underlying flash. \$\endgroup\$
    – JRE
    Feb 23, 2016 at 15:34

3 Answers 3


The optimistic estimation would be based on the assumption that your system accumulates data until it can fill one complete erase block, then writes all the data in one go. In that case, your eMMC will live

4'000'000 * 3'000 / (4*20) = 150'000'000 seconds

That's about 4.75 years.

However, if for example your system writes each 4K block separately, the time your eMMC will last will depend on the size of a single erase block. You'll have to check the spec for the actual value, but to give you an example, if your eMMC has 4M erase blocks, you'll have to divide the time by 1024 (meaning it will last just about a day or two).

The real value will be between these two numbers, depending on how you group write operations and how big erase blocks really are.

  • 3
    \$\begingroup\$ That's not how NAND flash works. You can erase one block (consisting of multiple sectors), and then write sector by sector. Unless the eMMC controller is really weird, it will not waste an erase cycle of a whole block to write a single sector. \$\endgroup\$
    – Sven
    Feb 25, 2020 at 23:45

Aside from estimating it, you can also ask the eMMC itself to tell you how far it has degraded so far (assuming it supports EMMC 5.1 or above).

The JEDEC standard (JESD84-B51) specifies that in the ext_csd field (offset 268-269) bytes indicate the level of type A/B wear. (value 0x1-0xA reflects 10%-100%, 0x0B means lifetime exceeded)

For example, on a typical linux distro, you could run the following script in bash to tell you:

RES=`cat /sys/kernel/debug/mmc1/mmc1:0001/ext_csd`
typea="${RES:536:2}" ;
typeb="${RES:538:2}" ;
typead=`echo "ibase=16; $typea"|bc`
typebd=`echo "ibase=16; $typeb"|bc`
echo "Type A percent: $((typead * 10)) %"
echo "Type B percent: $((typebd * 10)) %"
  • 1
    \$\begingroup\$ Note that this is also shown in mmc extcsd read /dev/block/mmcblk0 (replace with the device you want to check). The command is part of the mmc-utils package available e.g. in Debian. Or if you want to use this script but don't see anything in sys/kernel/debug then you need to mount debugfs: mount -t debugfs nodev /sys/kernel/debug \$\endgroup\$
    – Luc
    Mar 24, 2021 at 23:50
  • \$\begingroup\$ The mmc command gives me: eMMC Life Time Estimation A [EXT_CSD_DEVICE_LIFE_TIME_EST_TYP_A]: 0x02, eMMC Life Time Estimation B [EXT_CSD_DEVICE_LIFE_TIME_EST_TYP_B]: 0x01. I don't know if that's the same format, but I presume that's 20% and 10%? \$\endgroup\$
    – mwfearnley
    Jul 27, 2022 at 16:13

You will overwrite the total 4GB in (4*1024*1024*1024)/(20*4*1024) = 52,428.8 writes. Failures occur after ~3000 cycles, or 3000*52428.8 = 157,286,400 writes. If you operates 8 hours/day, in one year you have 8*365*3600=10,512,000 writes/year. That comes to (157,286,400 writes)/(10,512,000 writes/year) = 14.96 years. This ONLY works if you completely fill the eMMC before erasing any old files - if you erase as you go, then you can wind up overwriting the same 20*4k block in 3000 seconds. Careful sizing of the storage to match the physical block size will help keep you from fragmenting, which would reduce the total life some. Consider file system overhead when determining the eMMC blocks needed to hold your file.
Make sense?


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.