yashsingh1/xdaforums huggingface dataset:
[Nexus 7 (2013) Q&A] 459below:
I thank you for this very important word of caution. Fortunately I already made this experience a few years earlier with a rubbish board I bought for little money on eBay. I am aware of how incredibly fragile pads on a PCB are. It's like performing surgery on a housefly. In addition I had already removed the old eMMC. I held the eMMC by the sides with reverse action tweezers and slightly lifted the whole board by the eMMC. Then I heated the eMMC up until it just popped off. In retrospect I'd probably wouldn't repeat this, since I'm now very concerned about other components being misplaced while the board was hot, especially the ones on the other side of the board.

And thanks! I'll try my best.
[Nexus 7 (2013) Q&A] 459below:
I'm struggling while soldering the new eMMC to the motherboard. It does seem to take a lot more heat in comparison to reballing and soldering it to the USB device. I catiously cleansed the connector of residue using wick and applied flux before aligning the eMMC, however even though I became rather tenacious in applying heat to the chip, it just did not connect. I wonder whether I'm doing something dreadfully wrong. Or should I merely increase the amount of heat I'm introducing to the system?
[Nexus 7 (2013) Q&A] k23m:
This is great news for data or IMEI recovery. Thank you again for testing it out. Can you please post a link of the USB-eMMC adaptor? There were three versions of them and not all controller ICs may actually work with read-only Kingston chips.

The thermal profile of N7's motherboard PCB is much more demanding than the small USB device's PCB. BGA soldering without both top AND bottom heaters is indeed difficult. You may have to take the risk of greater heat.
[Nexus 7 (2013) Q&A] Dazmatic:
Don't forget to add a little flux to the board otherwise the solder won't flow very well.

Are you using leaded balls or lead free? Lead free has a higher temperature profile than leaded and it's a nightmare to reflow.
[Nexus 7 (2013) Q&A] 459below:
This is the one https://www.aliexpress.com/item/USB...t-Flash-Memory-eMMC-Adapters/32844033399.html it took quite a bit of time to arrive, but other than that it was fine.

Alright, thank you. I will increase the heat and try it like that.

Yes, I have added flux before I tried to solder it. I'm not certain which composition the balls on the new eMMC have, since those are the ones it was shipped with. I thought about how those balls could be meant for higher temperature.
[Nexus 7 (2013) Q&A] DimidiusDeus:
Forgive me if this has already been answered, but...

I have a hardware failure symptom #4 as listed in the OP.

I also have a situation where the bootloader is locked. (sucks, I know)

Device: Flo (WiFi only)

My question is... Will a "sgdisk --zap-all /dev/block/mmcblk0" work for my situation, as mentioned in post #204 of this thread, or am I completely screwed?

"If" sgdisk will help my situation, would someone be so kind as to tell me where the files need to go prior to booting TWRP?

Thank you. :)
[Nexus 7 (2013) Q&A] k23m:
It was discovered a while ago that "fastboot oem uart-on" command, which writes just 1 byte to the "aboot" partition, actually worked on generally read-only bricked Kingston. Would you be able to try the following command on your USB-eMMC assembly?

printf '\x06' | dd of=/dev/sda12 bs=1 count=1 seek=5241856

BTW, this is no random byte to write, the location is responsible for the lock/unlock status and allows for unlocking without user data destruction. Also, sda12 is the "aboot" partition. Thank you in advance for the experiment.

OK, so Alcor AU6438 chipset is proven to work for data recovery on bricked Kingston eMMC. :good:

#4 could be an Android OS issue or, in the OP hardware context, a bricked Kingston case - please do the Fastboot Diagnostics to verify it. If your eMMC is gone, no "soft" method will help you to get it working again, but if you want to recover your data we could try something "soft" if you wish. While sgdisk is irrelevant in your case, it works from twrp temp ramdisk after transfer via adb shell.
[Nexus 7 (2013) Q&A] 459below:
[root@manus ~]# printf '\x06' | dd of=/dev/sdf12 bs=1 count=1 seek=5241856
1+0 records in
1+0 records out
1 byte copied, 0.0013799 s, 0.7 kB/s

It seems it worked.

Yes, this is how it will appear on the system:

058f:6366 Alcor Micro Corp. Multi Flash Reader

Regarding the composition of the balls on the eMMC: Tomorrow I'm going to apply some flux on my new eMMC and attempt to get it to reflow. The balls look a tad dull and if I'm not mistaken, that indicates oxidation, which will affect how well it behaves while soldering. If that doesn't really work, I would assume, that the composition isn't feasible for my application and remove them then reball the eMMC.

/edit

It came to me, that in case the balls have a higher melting point it would make sense to try to solder it at least to the other USB to eMMC device. In case I succeed, I could verify that the new eMMC is not a dud and restore the partitions right then and there.
[Nexus 7 (2013) Q&A] DimidiusDeus:
Already verified the Fastboot part. Seems it's toast then, and I don't need any data from it. Thank you for the reply tho. :)
[Nexus 7 (2013) Q&A] k23m:
Lead-free balls look like that and they do have a higher melting point. You could restore the partitions using a USB adaptor but since we have now the service ROM it is no longer necessary to risk overheating damage during additional de/soldering. I guess you do not have a temperature-controlled BGA rework station, so the risk is real.
[Nexus 7 (2013) Q&A] 459below:
Lead-free balls would explain quite a bit. The reasoning for soldering it to the USB device first, was to take out the heat absorption by the motherboard out of the equation and in case it worked, I could've initialized it, before removing the eMMC from the device again. But I just unsuccessfully tried this a few minutes ago, which renders the additional soldering redundant. So I am going to remove those nasty balls and replace them with new ones, which will have a melting point of 200 degrees. Then I will solder it to the motherboard and hope for the best. :fingers-crossed:

Unless I misunderstand, this station is temperature-controlled. However it was "only" 70 €, thus I reckon it to diverge a tad from the nominal value, which I set to 300 degrees by the way.
[Nexus 7 (2013) Q&A] 459below:
OK. So I spent today cleaning and reballing the eMMC. On the fourth try or so I had to my own surprise created a proper reball with all 169 balls uniform. It then took me three attempts to solder it to the motherboard. I was eventually successful after I increased the heat to 350 degrees and heated it a tad longer. I'm now going to reassemble the devices and test it. I'm posting this beforehand, since I will certainly not be exceptionally motivated to reply in case I failed.
[Nexus 7 (2013) Q&A] 459below:
Well that didn't work...
[Nexus 7 (2013) Q&A] k23m:
A BGA rework station can measure and control entire target surface PCB's temperature. With hot air blower alone there are risks. Apart from PCB tracks/pads, prolonged excessive temperature will also fry up silicone inside ICs. Your screenshot indicates that the eMMC is either partially disconnected or damaged. Please zip up and post MiFlash log file from "C:\Program Files\Xiaomi\MiPhone\MiFlash-xxxxxxxxx.log"
[Nexus 7 (2013) Q&A] 459below:
That's good to know.

Interesting. So it seems it is partially detected? I have tried to connect it to the USB-device with a somewhat botched reball beforehand. I was reluctant to connect that to the motherboard. I guess it could've been still too little heat.

I would've been happy to post the logs, but there were 4 GB, so I deleted them. It was the same message from the screenshot repeatetly. MiFlash crashed after some 300 seconds of trying to write the first block, probably because the logs spammed the memory. If I find the time tomorrow, I can continue with this. Should I regenerate the logs and post a truncated version of it?
[Nexus 7 (2013) Q&A] k23m:
After removing the chip from N7 please run MiFlash again and we will know for sure what it shows and logs when eMMC is completely damaged or non-existent. A truncated version of the log would be useful for reference and future diagnostics. I could test it myself by cutting power to the chip, I've done it before (attached) in a different context, but you are already in the middle of it ;)

As we don't know if the chip is fried or wasn't 100% soldered, testing it on the USB adaptor would provide conclusive answer. I hope this 64GB chip is still fine and you'll have the first ever N7'13 with such NAND capacity upgrade! :fingers-crossed:
[Nexus 7 (2013) Q&A] 459below:
Bad news. Looks like I've torn a few pads.
[Nexus 7 (2013) Q&A] k23m:
Your persistence is inspiring. It is definitely worth 12 € for a mobo with faulty eMMC. Let us know when it arrives. Can you please check the read/write performance of your new 64GB flash drive with ATTO or equivalent app? Perhaps it is worth assembling such $1.5+eMMC drives based on the Alcor AU6438 adapter :)

Cheers!

/edit - Alcor AU6438 is USB2 so bad read/write performance is guaranteed :(
[Nexus 7 (2013) Q&A] 459below:
Thank you. The funny thing is, that I intentionally used my small 30 watt iron instead of my expensive 60 watt iron, so that I won't damage the board with too much heat. And it seems, that I damaged it because I used too little heat to overcome the heat sink properties of those pads and their traces. In Germany we call this sort of thing: paying apprentice's due.

Yes, they are not incredibly quick. The dd from one to the other had an sequential write speed of 21.6 MB/s. I reckon, that this should be far below of what the eMMC is capable of. I had an USB3 stick, which was about 6$, but I destroyed it when I didn't anticipate the bloating soldering mat.
[Nexus 7 (2013) Q&A] 459below:
Probably should've watched something like this beforehand: [youtube]_f2SSXYIF9E[/youtube]

Maybe it safes someone from pad tearing.
[Nexus 7 (2013) Q&A] k23m:
I see D7 and a few VSS/VCCs gone. You don't have to worry about VSS/VCC as there are plenty of "spares". Data D7 has a small track extension and if active "via" connection is below it then this PCB could work again with a single tiny wire mod :cowboy:

I know it is a long shot but it's doable....

[YOUTUBE]bDrpftBjRdk[/YOUTUBE]​

https://www.youtube.com/watch?v=bDrpftBjRdk
[Nexus 7 (2013) Q&A] 459below:
Quite interesting indeed. Though I don't completely understand how this is to be accomplished. Do you mind elaborating on the track extension and the active via connection? As far as I grasp the task, it would consist mainly of scraping where the D7 pad would be and soldering a tiny wire to it. Does the wire serve the purpose of protecting the bare trace, which we will have exposed from following suit and get torn out as well?
[Nexus 7 (2013) Q&A] k23m:
First it has to be established if it is an "offset via". On D7 there should be a pull-up resistor somewhere or a placeholder for it, and ohmmeter can confirm proper link. With offset via a tiny wire soldered across the track would provide the missing pad connection, like in the YT video above. It's a microscope job....
[Nexus 7 (2013) Q&A] 459below:
This is definitely fascinating. I'm going to experience a bit of a time shortage in the next few weeks, so I'll have to put a pin in it, but I am most certainly revisiting this idea. I'm really gaining a lot of useful experience here.

I'm expecting the less defective board to arrive next week. If this board proofs to be mostly intact, I will have a chance to utilise my newly acquired wisdom to perhaps not butcher it, like I did with the old one. :good:
[Nexus 7 (2013) Q&A] 459below:
I have received the replacement board and its condition was truly excellent. It didn't boot, but the eMMC seems to be intact. However I managed to slip up again. I stored the N7 fully assembled and apparently l left it in QLOAD. The battery was completely drained and after I connected the USB, it indicated via the 3 flashes, that its battery is entirely discharged. So I connected the charger and waited a few minutes until I could boot it into QLOAD and flash the service rom, which did work as expected and I'm now able to boot into fastboot :good: But the battery is below 30% and it refuses to flash or boot anything. Additionally it won't boot the tiny "charging OS", which displays the battery charging icon, like it did before flashing the service rom. Out of the frying pan and into the fire! I have connected it to the original charger via an amperemeter, which shows an intake of 20mA, while the tablet is connected. If I'm not mistaken this should be 100 times larger, when it charges properly. At this point I'm not even sure if it charges at all. I've seen clues, that other devices support the command fastboot getvar battery-voltage, but I did not get a proper response in my case. I did a rule of thumb estimate and calculated the capacity of the N7 battery times .3 divided by the intake of the charger, which was (3950 mAh * .3) / 20 mA = 59.25 h. Given that it's actually charging, that would mean about 2 1/2 days until I'm allowed to do anything.

Does somebody have any ideas how I would be able to solve this problem? :confused:

/edit

I turned it off and let it charge for a while and it worked. When fastboot did allow me to do stuff, I quickly booted TWRP (fastboot boot twrp-flo.img). Now the charger pulls 40 mA and it shows its level, which is 36% ATM. So this time I'm going to let it fully charge :) I reckon my estimate was way off. 20 mA on 230 V should translate to much more on 5 V (or 4.35 V?). But 40 mA is still better than 20 mA.
[Nexus 7 (2013) Q&A] 459below:
I'm reporting on a somewhat hollow victory. The replacement board from eBay was in brilliant shape and even a Hynix. I did not notice anything wrong with it, besides the OS not booting up properly. I was under time pressure and didn't try fastboot, before flashing the service rom. Using the exact instructions on in-circuit programming I managed to restore all the necessary partitions including my original persist partition, which I rescued from the old eMMC via the eMMC-to-USB device. So the device is up and running and as of now there are no adverse effects noticable at all. I catiously declare this devices resurrected :victory:

I thank all participants and especially k23m. My main task is accomplished, nonetheless there are still a few loose ends, which need to be tied up in a sort of dénouement. Since I was able to snag another board by the same seller, I am determined to utilise the 64 GB eMMC after all. Additionally I am going to use the damaged board to map out the pads to their resistors as well as trying to reconnect the torn pad via a wire mod. Unfortunately this will have to wait a few weeks, but anticipation is the greatest joy. :)
[Nexus 7 (2013) Q&A] k23m:
Thanks in advance for the mapping. I'm pretty sure that all relevant BGA pads have connections to components or tracks around the chip. Theoretically, instead of BGA soldering and attempting to reconnect the torn pad, you could flip up the chip, glue it in, and then use the mapping to wire it like in this "adventure" :) https://ripitapart.com/2016/10/28/e...g-my-own-64gb-memory-card-with-a-6-emmc-chip/
[Nexus 7 (2013) Q&A] 459below:
Would the relevant ones be: all the green and yellow ones plus one red and one blue?

On that note, isn't a 153 BGA eMMC just as feasible? I've noticed, that there are guiding lines on the motherboard for what looks like 153 chips. I've glanced at the pinout for 153 and they look identical too me, besides the additional 16 unconnected pads on the outside.
[Nexus 7 (2013) Q&A] 459below:
So I've found the first issue with the device: The touchscreen doesn't turn on every time, when the display is turned on from sleep. I can imagine, that it could be as trivial as issues with the cable. I'm afraid that this could damage the IC, if the connection is dirty.

[105585.666593] qup_i2c qup_i2c.3: QUP: I2C status flags :0x1300c8, irq:183
[105585.667997] qup_i2c qup_i2c.3: I2C slave addr:0x10 not connected
[105585.667997] elan-ktf3k 3-0010: [elan] elan_ktf3k_ts_set_power_state: i2c_master_send failed
[105585.668058] qup_i2c qup_i2c.3: QUP: I2C status flags :0x1300c8, irq:183
[105585.668089] qup_i2c qup_i2c.3: I2C slave addr:0x10 not connected
[105585.668119] elan-ktf3k 3-0010: [elan]elan_ktf3k_ts_get_data: i2c_master_send failed
[105585.668119] [ektf3k]:[elan] elan_ktf3k_ts_resume: wake up tp failed! err = -22

/edit

OK, so I cleaned the connector and cable (https://www.ifixit.com/Guide/Nexus+7+2nd+Generation+Motherboard+Replacement/36967 the one in step 5) with some alcohol and blew it off with the duster, then seated it carefully and now the touchscreen does turn on properly. I'm fairly certain, that the cable was the issue and I think this also caused the boot to stop at the Google logo one time for me.

/edit 2

https://www.youtube.com/watch?v=cOnccu6Nbl0

So this seems to be a common thing on the N7...
[Nexus 7 (2013) Q&A] k23m:
Yes any eMMC will work in this flip-up mod. I attached actual schematic to verify needed connections. N7 runs in 8-bit mode so the yellow ones are definitely used. Also, unlike the referenced project, I'd use more than one GND/VSS connection to ensure speedy and reliable operation.

Sure it is. The same cable and connector are responsible for a number of problems with touch, boot, USB, accelerometer and compass https://xdaforums.com/showpost.php?p=66952073&postcount=3
[Nexus 7 (2013) Q&A] Aoi v1:
Hi! I check this forum once or twice a year, hoping there would come a solution for mi issue, and seems it finally did! So, I'm stuck on a bootloop, Google logo shows and goes. I can access fastboot and tried the suggested diagnostic, but got a different result:

C:\Android-SDK\platform-tools>fastboot format cache
mke2fs 1.43.3 (04-Sep-2016)
Creating filesystem with 143360 4k blocks and 35840 inodes
Filesystem UUID: 10bfba32-39e8-11e8-a413-13e4f1b207cb
Superblock backups stored on blocks:
32768, 98304

Allocating group tables: done
Writing inode tables: done
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done

target didn't report max-download-size
erasing 'cache'...
OKAY [ 0.413s]
sending 'cache' (348 KB)...
OKAY [ 0.034s]
writing 'cache'...
OKAY [ 0.039s]
finished. total time: 0.503s

I assumed it was still a good result, is it not? So, what should the next step be? I tried MiFlash, but my laptop doesn't recognize my device during the bootloop (instructions say to turn on N7, doesn't specify if it's in normal mode, fastboot mode, etc.).

Thanks for your help! :)
[Nexus 7 (2013) Q&A] k23m:
Re: MiFlash - it does specify this... "If your tablet can boot in fastboot mode, you do not need it" - OK?

Your tablet has passed the format test and there is no problem with eMMC at all.

All you have to do is fix some trivial Android issue. There are numerous reasons for the bootloop. If you don't care about your data then just flash factory image - instructions are here https://developers.google.com/android/images

If you need to recover your data or factory flash is unsuccessful, then please post a reply in this thread.
[Nexus 7 (2013) Q&A] Aoi v1:
This is the same problem I've had for more than 3 years:

sending 'system' (843549 KB)...
OKAY [ 26.748s]
writing 'system'...
FAILED (remote: Bogus size sparse and chunk header)
finished. total time: 63.808s

As you suggested, if I have fastboot access, I should just flash a factory image, right? Well, I've never found anything related to this error. Do you know what it might be?
[Nexus 7 (2013) Q&A] k23m:
Let's do some diagnostics, please post the output of the following commands:

boot the Nexus in fastboot mode (when off press power+vol.dn)

connect it to your PC

on PC run:

fastboot getvar all

fastboot oem gpt-info
​

Next...

go to your folder with fastboot.exe and adb.exe

download twrp-3.2.1-0-flo.img to the folder

also unzip and copy the attached "twrp-log.bat" to the folder

in the folder open a DOS command window and copy/paste: fastboot boot twrp-3.2.1-0-flo.img [Enter]

when TWRP is up and running (may ask for ADB driver) and you see the menu, double-click on

twrp-log.bat

Note, all of the above steps must be done withn 3 minutes to ensure complete dmesg log

then you will find a new file

twrp.txt

in the folder

zip up

twrp.txt

and attach it to your next post

Cheers :good:
[Nexus 7 (2013) Q&A] Aoi v1:
C:\Android-SDK\platform-tools>fastboot boot twrp-3.2.1-0-flo.img
downloading 'boot.img'...
OKAY [ 0.293s]
booting...
OKAY [ 0.032s]
finished. total time: 0.337s

Well, after that line of code, my Nexus goes back to the boot loop, so it doesn't make it to twrp recovery. Any other suggestions?
[Nexus 7 (2013) Q&A] riyan65:
I have nexus 7 2013 which has hard bricked.how can i repair my nexus 7 2013

Hey I have Nexus 7 2013.it has hard bricked due to charging.can I repair it. If I charge it and press the power button for 3seconds after few hours I received that it has sync with google. i have send it to Asus service center but they have told that "they will not give me assurance it will work or not"
[Nexus 7 (2013) Q&A] k23m:
You had forgotten to post the output of:

fastboot getvar all

fastboot oem gpt-info​

I modified the latest TWRP, it will not attempt to mount any partition and cause possible kernel 'panic'. I also added 'parted' binary to it as it may be useful in this case. Download and try to boot it.

Tell us more and select one of these:

device is totally dead

dead but flashes a few times the white LED next to USB port

dead but with active USB on PC device list

works up to fastboot stage or Google logo

may slowly boot Android sometimes

intermittently Android does not boot or work at all
[Nexus 7 (2013) Q&A] riyan65:
I can't say it is dead as it has sync with Google.but it will not show any thing on screen and not connect to PC also
[Nexus 7 (2013) Q&A] echow2001:
will this work with a mmc that is not blank but not from the nexus7? like if I harvest it from a LG or HTC donor for example
[Nexus 7 (2013) Q&A] k23m:
Maybe the LCD's backlight is off? Use a torch to see if something is visible on the screen.

Yes, but check the donor's eMMC type just to be sure, you need FBGA169, v4.5-v5.0, 16GB+, blank or not does not matter. :fingers-crossed:
[Nexus 7 (2013) Q&A] riyan65:
Nothing is visible on the screen.is there any other way to fix it.
[Nexus 7 (2013) Q&A] 459below:
:victory:

I've been successful! After I destroyed my original board, I had a lot of luck, when that eBay seller sold off those two motherboards for the incredibly low price of 24 Euros. One of which was a 16G Hynix, which did work OOTB. The other one was a 32 GB Kingston, which had - as expected - a defective eMMC. I did learn from my first mistake, when I butchered my own 16 GB Kingston motherboard. Mainly: Cleaning up BGA pads is extremely delicate work. This time I didn't use any wick, since that's where I probably pulled most pads. Instead I used my 60 watt and hovered a blob of leaded solder over the pads. It cleaned up the pads very nicely. I got this procedure from this video https://youtu.be/CWM2-wvUVOA?t=176.

Now I own a 64 GB 2013 Nexus 7 :cool: The eMMC I used was the H26M78003BFR by Hynix.
[Nexus 7 (2013) Q&A] Dazmatic:
When using solder wick, it's better to snip a little bit off and hold it with tweezers and clean that way than to use it while attached to the reel. Copper dissipates heat so quickly that you'll essentially just end up heating the whole roll of wick as opposed to the solder you want to remove. That's how I clean any board now, slither of wick with flux.

Congrats though, do you intend on doing a write up on what you did to get to that stage?