[Q] eMMC crash - possible reasons and solutions

Search This thread

levantine

New member
May 23, 2010
4
5
Hello everyone.

I've been looking around here for some time, reading all that suff about eMMC chips burning on Desire S. That fact dissapoints me as I was aiming to buy the gadget myself. :( However, I didn't find any general solution or even investigation of the case, so I'm trying to develop some kinda stuff. Let me summarize main points that we have so far.

1) The faulty guy is usually Samsung eMMC-type BGA chip KLM4G2DE (2 Gb NAND flash), however Sundisk chips were also found to burn.
2) The problem is rather hardware than software dependent as it is observed without any corellation to hboot/flash installed.
3) It was noticed that in many cases eMMC fault followed extraction-insertion of battery after phone freeze.
4) HTC doesn't recognize this as defective case and no improvements to hardware are made in new revisions of motherboard (MB) as there have been cases (at least one) when the same phone after warranty repair crashed again after some time.with the same eMMc chip installed
5) Other phones with the same eMMC installed (e.g. Sensation) doesn't experience same problems.

What can I deduce out of all this stuff and my own experience?
As soons as the case seems to be non-software dependent it should be the chip or some other hardware that drives it wrong. As soons as the chip itself seems to be OK (see 5) I beleive that it is poor motherboard design that burns the chip down. eMMC is rather bomb-proof architecture combining the memory itself and the memory controller on the same crystal. Two major ways to drive it wrong are:

1) Supply incorrect clock pulses to clock bus
2) Supply incorrect power (current/voltage/voltage slope) to memory and/or controller

The first assumption seems not very possible as clock usually comes from centralized source controlled by oscillator. If the clock is wrong, the emmc fault wouldn't be the only problem ;)
The second point seems rather reasonable as Samsung eMMC power-up guide (see file attached) directly points out the importance of accurate power supply (especially power-on slope!), otherwise memory faults are inevitable.

That's all I can deduce so far, unfortunately there's no photos/schematics of desire s on the web to analyze the connection of emcc chip to MB. What can I suggest to prove/disprove all the stuff I wrote:

1) Can someone brave disassemble his Desire S and make high resolution photos of both sides of motherboard? This may help in further analysis.

2) Can someone even more brave and being on close terms with oscilloscope try to measure power-up voltage slope on Vсс and VccQ inputs of eMMC chip(see document attached) ? May be we are just having one of the issues described in the document.

UPDATE
I found the datasheet four our chip, find it attached to this post
 

Attachments

  • eMMC_app_note_for_Power_up_rev0.pdf
    150.1 KB · Views: 671
  • KLMxGxxE.zip
    317.6 KB · Views: 394
Last edited:

olyloh6696

Senior Member
Oct 20, 2009
7,674
1,556
27
Manchester
Also, strangely, a common way to trigger the 'dead emmc' is when you hit 'update all' apps in the android market, regardless of what ROM/market version your on..

Surely it must be a combination of a software fault/problem too?
 
  • Like
Reactions: abu busyra

levantine

New member
May 23, 2010
4
5
As far as I got it, some kinda software problem causes phone to hang during market update. Lots of users tend to solve this by removing/re-inserting the battery which leads to burned emmc.
 

olyloh6696

Senior Member
Oct 20, 2009
7,674
1,556
27
Manchester
Yeah.. that would be the case. It kind of sucks knowing you could potentially brick your phone by just updating apps from the market.

And if you're on a custom ROM, you're screwed :(

Sent from my HTC Desire S using xda premium
 

amidabuddha

Senior Member
Jun 26, 2011
2,441
2,458
From my experience the eMMC in the "fried" cases is not actually faulty but simply does not allowing write access. Usually it is accompanied by /cache or /cache + /data corruption. When only /cache is the problem it is fixable, but when /data is affected there is no way to write a bit on the internal memory.

Unfortunately I have no confirmed explanation to this...

Just in theory when updating several apps from the Market (or other activities requiring use of /cache partition) it is possible that the /cache is filled with data and the device stucks at a point when it has no more space available to write. Rebooting to recovery and wiping /cache solves the problem. But if in that moment, when the app is downloading to /cache and another app is written from /cache to the /data partition at the same time, disconnecting the power source (battery pull) can interrupt the process making this partition unavailable (example: if you take out your USB flash drive from the PC while writing data on it there is a great chance to destroy it - tested myself :) ) The ext4 file system provides a protection for such cases by the way it is managing the writing process - reference here.

In my opinion all of the bricked devices (famous "fried eMMC") reported in this forum are easily repairable with JTAG and a skilled technician, but unfortunately there are no such cases reported here. Personally I do not have the knowledge, equipment and intention to do such experiments myself.

This is my logic based on my observations while trying to assist people in this forum to solve this issue. For some of them it was successful, for others - not.

I hope that my post will make a contribution to the general picture.

Regards,
Stefan
 
Last edited:
  • Like
Reactions: sadsac and MS.

MS.

Senior Member
Aug 7, 2011
623
216
www
The ext4 file system provides a protection for such cases by the way it is managing the writing process.
Hi, thanks for sharing your thoughts. So you say those who uses EXT4 should be safe? Here's a screenie from my wifes DS.

1mWi7.png


Also, my SGSII got broken and now i'm thinking to get one of Desire S for myself. How's situation with those fried eMMC's, was there a lot of reports over here? What chances are to get it "fried"? Sorry, i don't have much time to go trough all DS forums.
 

amidabuddha

Senior Member
Jun 26, 2011
2,441
2,458
Isn't Gingerbread ext4?

At the present moment I think that HTC switched to ext4, at least when looking the update_script of the new OTA 2.10.401.8:

Code:
# Script Version: G2.3

mount("ext4", "EMMC", "system", "/system");
mount("ext4", "EMMC", "/dev/block/mmcblk0p28", "/system/lib");
...
mount("ext4", "EMMC", "userdata", "/data");

EDIT: after checking my current file system (Stock 2.10.401.8) it appeared that all partitions (system, data, cache and devlog) are ext4

but when I purchased my device with version 1.28.401.1 and got the guts to S-OFF it (at the end of July) all my partitions were ext3 and I converted them manually using 4EXT Recovery. Maybe flashing a custom ROM converted the partitions from ext4 to ext3 I do not know...

I am not claiming 100 % accuracy in this information, but Revolutionary supports only hboot 0.98.0000 (from version 1.28.401.1) and hboot 0.98.0002 (version 1.47.401.4) so I suppose the most of the fault cases around are users like me that S-OFFed with ext3 but most of them that faced this problem had the ClockworkMod recovery (flashed by the Revolutionary exploit) which was not offering file system conversion at that time (not sure about the latest versions) and never converted as I did.

Cannot say for sure also for the Stock users that prefer to send the device for repair after failure with Market updates instead of making a mess with custom recoveries and RUU flashing. Maybe is this case a /cache wipe will do the trick (BTW the Stock recovery has an option "wipe cache")...or like this guy that fixed it with a hard reset and a new SDcard.

More or less the fact that the new version of the Market is updating the apps one by one and has a button to stop all updates at once is made by a reason...
 
Last edited:

shrome99

Senior Member
May 11, 2011
3,528
1,524
Chandigarh
Just in theory when updating several apps from the Market (or other activities requiring use of /cache partition) it is possible that the /cache is filled with data and the device stucks at a point when it has no more space available to write. Rebooting to recovery and wiping /cache solves the problem. But if in that moment, when the app is downloading to /cache and another app is written from /cache to the /data partition at the same time, disconnecting the power source (battery pull) can interrupt the process making this partition unavailable (example: if you take out your USB flash drive from the PC while writing data on it there is a great chance to destroy it - tested myself :) ) The ext4 file system provides a protection for such cases by the way it is managing the writing process - reference here.

I agree with that. Most plausible theory i read about eMMC fries/corruptions. You've been helping people get out of this crap (i call it crap because it's HTC's fault, cheaping out on us) for a long time now.

What i don't understand is this - when downloading multiple apps from market (i had 2 - Angry birds, ES file explorer), the phone goes to sleep mode, and NEVER wakes up. No ADB, no 3 key combo, NOTHING. This leads to an unavoidable battery pull, which results in corruption like you said above. Why does the phone enter this "Sleep of Death" if you may call it? What the hell is the problem? Also, why not other HTC devices? (for that, i guess the answer is the unique slide out battery, only in 2 other devices - Bliss and Radar, whose battery can't be removed). If we can solve the "Sleep of Death" mystery, we'll get this issue out.
(More info - http://bit.ly/rXhDRR and http://bit.ly/v3lsS6 )

Also, DS (and all new HTC devices) are EXT4 by default. Flashing (not s-off'ing, but flashing a ROM after that) changes back to EXT3. That is probably why my phone survived the battery pull i did as said above. (It was freshly s-offed by XTC Clip, stock ROM).

Finally, i think this only happens to devices with already screwed eMMCs. Mine survived many battery pulls after the first one. The screwy ones are region specific. I never read anyone from India had the issue.
 
  • Like
Reactions: vantt1

amidabuddha

Senior Member
Jun 26, 2011
2,441
2,458
...Also, why not other HTC devices?

I am not quite sure...
...Next I got on the phone with the HTC help center. I got friendly with the lady technician on the call. After some nice chat I started probing for information on the Desire S. After a long conversation She told me that the Desire S, Incredible S, Desire HD all have the problem of frying the eMMC chip if the battery is disconnected while power is on. She said she gets calls every day with people who have fried their eMMC chip...
Also
The Desire S does not have a force shutdown keystroke combo as my old Desire did.
...
And because of a design flaw in the way the battery door closes, and because HTC did not include a force shutdown key combination to shut the phone off properly when locked.

The 3 key combo on Desire S performs a hard reset, 2 key combo boots to bootloader from a shut down state, but no combination for a force shutdown when powered on.

Taken from here

So from all the above is clear that the battery pull is the reason for this fault and I think that the deduction of the OP (post #1) is in the right direction, but unfortunately I do not have the required technical knowledge to comment.

For me the following is a must to avoid this problem:
  • always keep the USB Debbuging" ON in Settings
  • always disable "fastboot" option in Settings to prevent "hibernation" mode, i.e. running processes
  • keep your /cache clean (always wipe before installing anything)
  • stick to ext4 file system
  • if the device hangs anyway never pull out the battery, better wait it to be completely drained
 
Last edited:

shrome99

Senior Member
May 11, 2011
3,528
1,524
Chandigarh
The hard reset sucks. The one on my iPod touch ALWAYS works. You are stuck anywhere, hold home+power for 30 seconds, and there's a hard reset. This one rarely works
 

tcchuin

Senior Member
Dec 25, 2008
1,034
69
the snd time when my phone spoilt is when i accidentally pressed update all in market..
then the phone became sluggish and finally hanged.
as i've had experience and didn't dare to pull the battery,i used the hold buttons to restart method.I had to hold it for loonger time than usual(like 15 seconds ++)
after the phone's screen went oof,the phone never boot up again :(
 

MS.

Senior Member
Aug 7, 2011
623
216
www
the snd time when my phone spoilt is when i accidentally pressed update all in market..
then the phone became sluggish and finally hanged.
as i've had experience and didn't dare to pull the battery,i used the hold buttons to restart method.I had to hold it for loonger time than usual(like 15 seconds ++)
after the phone's screen went oof,the phone never boot up again :(
Wait, so you've "fried eMMC" chip by pressing Vol up+Vol down+Power only?
 

MS.

Senior Member
Aug 7, 2011
623
216
www
OMG :( And i just got Desire S for myself. Now S-Off in progress, can't wait to see what eMMC chip i've got...

EDIT:

b4ftb.png


Feelin' lucky :) Going to format all partitions as EXT4 and flash CM7.
 
Last edited:

iuss

Senior Member
Dec 21, 2010
156
229
Hello everyone.
1) The faulty guy is usually Samsung eMMC-type BGA chip KLM4G2DE (2 Gb NAND flash), however Sundisk chips were also found to burn.
2) The problem is rather hardware than software dependent as it is observed without any corellation to hboot/flash installed.
3) It was noticed that in many cases eMMC fault followed extraction-insertion of battery after phone freeze.

Just leaving this here for Google'ability. I've experienced a similar case on a Samsung device, equipped with a MAG8DD moviNAND (manuf. date ~10/2009). After pulling the battery the moviNAND died.

Code:
mmcblk1: mmc1:0001 MAG8DD 15.3 GiB
mmcblk1: error -110 sending status comand
 
  • Like
Reactions: amidabuddha

RolF2

Senior Member
Sep 25, 2008
232
110
one more theory :

emmc has internal voltage regulator, that requare external decoupling capacitor.
from sandisk inand datsheet:

VDDi Connections
The VDDi (K2) ball must only be connected to an external capacitor that is connected to VSS. This signal may not be left floating. The capacitor’s specifications and its placement instructions are detailed below.
The capacitor is part of an internal voltage regulator that provides power to the controller.
Caution: Failure to follow the guidelines below, or connecting the VDDi ball to any external signal or power supply, may cause the device to malfunction.
The trace requirements for the VDDi (K2) ball to the capacitor are as follows:
• Resistance: <2 ohm
• Inductance: <5 nH
The capacitor requirements are as follows:
• Capacitance: >=0.1 uF
• Voltage Rating: >=6.3 V
• Dielectric: X7R or X5R

maybe there's PCB design problems (inductance), or too small capacitance of decoupling capacitor in DS ?
 
  • Like
Reactions: amidabuddha

Top Liked Posts

  • There are no posts matching your filters.
  • 4
    Hello everyone.

    I've been looking around here for some time, reading all that suff about eMMC chips burning on Desire S. That fact dissapoints me as I was aiming to buy the gadget myself. :( However, I didn't find any general solution or even investigation of the case, so I'm trying to develop some kinda stuff. Let me summarize main points that we have so far.

    1) The faulty guy is usually Samsung eMMC-type BGA chip KLM4G2DE (2 Gb NAND flash), however Sundisk chips were also found to burn.
    2) The problem is rather hardware than software dependent as it is observed without any corellation to hboot/flash installed.
    3) It was noticed that in many cases eMMC fault followed extraction-insertion of battery after phone freeze.
    4) HTC doesn't recognize this as defective case and no improvements to hardware are made in new revisions of motherboard (MB) as there have been cases (at least one) when the same phone after warranty repair crashed again after some time.with the same eMMc chip installed
    5) Other phones with the same eMMC installed (e.g. Sensation) doesn't experience same problems.

    What can I deduce out of all this stuff and my own experience?
    As soons as the case seems to be non-software dependent it should be the chip or some other hardware that drives it wrong. As soons as the chip itself seems to be OK (see 5) I beleive that it is poor motherboard design that burns the chip down. eMMC is rather bomb-proof architecture combining the memory itself and the memory controller on the same crystal. Two major ways to drive it wrong are:

    1) Supply incorrect clock pulses to clock bus
    2) Supply incorrect power (current/voltage/voltage slope) to memory and/or controller

    The first assumption seems not very possible as clock usually comes from centralized source controlled by oscillator. If the clock is wrong, the emmc fault wouldn't be the only problem ;)
    The second point seems rather reasonable as Samsung eMMC power-up guide (see file attached) directly points out the importance of accurate power supply (especially power-on slope!), otherwise memory faults are inevitable.

    That's all I can deduce so far, unfortunately there's no photos/schematics of desire s on the web to analyze the connection of emcc chip to MB. What can I suggest to prove/disprove all the stuff I wrote:

    1) Can someone brave disassemble his Desire S and make high resolution photos of both sides of motherboard? This may help in further analysis.

    2) Can someone even more brave and being on close terms with oscilloscope try to measure power-up voltage slope on Vсс and VccQ inputs of eMMC chip(see document attached) ? May be we are just having one of the issues described in the document.

    UPDATE
    I found the datasheet four our chip, find it attached to this post
    2
    From my experience the eMMC in the "fried" cases is not actually faulty but simply does not allowing write access. Usually it is accompanied by /cache or /cache + /data corruption. When only /cache is the problem it is fixable, but when /data is affected there is no way to write a bit on the internal memory.

    Unfortunately I have no confirmed explanation to this...

    Just in theory when updating several apps from the Market (or other activities requiring use of /cache partition) it is possible that the /cache is filled with data and the device stucks at a point when it has no more space available to write. Rebooting to recovery and wiping /cache solves the problem. But if in that moment, when the app is downloading to /cache and another app is written from /cache to the /data partition at the same time, disconnecting the power source (battery pull) can interrupt the process making this partition unavailable (example: if you take out your USB flash drive from the PC while writing data on it there is a great chance to destroy it - tested myself :) ) The ext4 file system provides a protection for such cases by the way it is managing the writing process - reference here.

    In my opinion all of the bricked devices (famous "fried eMMC") reported in this forum are easily repairable with JTAG and a skilled technician, but unfortunately there are no such cases reported here. Personally I do not have the knowledge, equipment and intention to do such experiments myself.

    This is my logic based on my observations while trying to assist people in this forum to solve this issue. For some of them it was successful, for others - not.

    I hope that my post will make a contribution to the general picture.

    Regards,
    Stefan
    1
    Also, strangely, a common way to trigger the 'dead emmc' is when you hit 'update all' apps in the android market, regardless of what ROM/market version your on..

    Surely it must be a combination of a software fault/problem too?
    1
    Just in theory when updating several apps from the Market (or other activities requiring use of /cache partition) it is possible that the /cache is filled with data and the device stucks at a point when it has no more space available to write. Rebooting to recovery and wiping /cache solves the problem. But if in that moment, when the app is downloading to /cache and another app is written from /cache to the /data partition at the same time, disconnecting the power source (battery pull) can interrupt the process making this partition unavailable (example: if you take out your USB flash drive from the PC while writing data on it there is a great chance to destroy it - tested myself :) ) The ext4 file system provides a protection for such cases by the way it is managing the writing process - reference here.

    I agree with that. Most plausible theory i read about eMMC fries/corruptions. You've been helping people get out of this crap (i call it crap because it's HTC's fault, cheaping out on us) for a long time now.

    What i don't understand is this - when downloading multiple apps from market (i had 2 - Angry birds, ES file explorer), the phone goes to sleep mode, and NEVER wakes up. No ADB, no 3 key combo, NOTHING. This leads to an unavoidable battery pull, which results in corruption like you said above. Why does the phone enter this "Sleep of Death" if you may call it? What the hell is the problem? Also, why not other HTC devices? (for that, i guess the answer is the unique slide out battery, only in 2 other devices - Bliss and Radar, whose battery can't be removed). If we can solve the "Sleep of Death" mystery, we'll get this issue out.
    (More info - http://bit.ly/rXhDRR and http://bit.ly/v3lsS6 )

    Also, DS (and all new HTC devices) are EXT4 by default. Flashing (not s-off'ing, but flashing a ROM after that) changes back to EXT3. That is probably why my phone survived the battery pull i did as said above. (It was freshly s-offed by XTC Clip, stock ROM).

    Finally, i think this only happens to devices with already screwed eMMCs. Mine survived many battery pulls after the first one. The screwy ones are region specific. I never read anyone from India had the issue.
    1
    Hello everyone.
    1) The faulty guy is usually Samsung eMMC-type BGA chip KLM4G2DE (2 Gb NAND flash), however Sundisk chips were also found to burn.
    2) The problem is rather hardware than software dependent as it is observed without any corellation to hboot/flash installed.
    3) It was noticed that in many cases eMMC fault followed extraction-insertion of battery after phone freeze.

    Just leaving this here for Google'ability. I've experienced a similar case on a Samsung device, equipped with a MAG8DD moviNAND (manuf. date ~10/2009). After pulling the battery the moviNAND died.

    Code:
    mmcblk1: mmc1:0001 MAG8DD 15.3 GiB
    mmcblk1: error -110 sending status comand