After ECC correction:
Chip 0
- dump 0 - 15.97GB of 16GB Bad
- dump 1 - 15.97GB of 16GB Bad
Chip 1
- dump 2 - 2.57GB of 16GB Bad
- dump 3 - 5.41GB of 16GB Bad
Thus far, we have been unable to read anything more.
Any suggestions on getting these chips to read better? Set to slow read hasn't made a difference. I will probably apply heat later, but am not optimistic that it will help dig out of this big hole.
Also, is it worth trying for a RAW recovery to see what I can get?
PF530 (2C84C54B)
Moderators: Nick_TS, Roman_TS, Filipp_TS
Re: PF530 (2C84C54B)
1. ECC
2. Readout with read retry
3. Readout with Voltage control and switched-off read retry
http://blog.acelab.eu.com/pc-3000-f ... 1-ecc.html
http://blog.acelab.eu.com/pc-3000-f ... adout.html
http://blog.acelab.eu.com/pc-3000-f ... ol-p3.html
2. Readout with read retry
3. Readout with Voltage control and switched-off read retry
http://blog.acelab.eu.com/pc-3000-f ... 1-ecc.html
http://blog.acelab.eu.com/pc-3000-f ... adout.html
http://blog.acelab.eu.com/pc-3000-f ... ol-p3.html
With best regards
ACELab Technical Support
ts.acelab.eu.com
blog.acelab.eu.com
ACELab Technical Support
ts.acelab.eu.com
blog.acelab.eu.com
Re: PF530 (2C84C54B)
Tried all three yesterday.
1. ECC - is how I got it to show the numbers above
2. Readout with read retry read not a single sector more
3. Readout with Voltage control and switched-off read retry read not a single sector more
Amazingly, I've been able to get the broken file structure and recover 7.28GB (2,901 Files) of good healthy files, with file and folder name, from the very broken dumps.
1. ECC - is how I got it to show the numbers above
2. Readout with read retry read not a single sector more
3. Readout with Voltage control and switched-off read retry read not a single sector more
Amazingly, I've been able to get the broken file structure and recover 7.28GB (2,901 Files) of good healthy files, with file and folder name, from the very broken dumps.
Re: PF530 (2C84C54B)
It might be mistake. Do not confuse those things. Your Flash drive might be filled by data on 15%, and all other 85% would be empty. If your CPU is AU669x or SSS (those one which are crypt not only DA but also SA with ECC), there might be situation when empty ranges would be marked as "uncorrected" - because there is no data in sectors, so there is nothing to fix.
You didn't tell that your controller is AU699x, and that's why you get almost perfect result with folder structure and good files.
BEFORE STARTING ANY RECOVERY PROCESS, DON'T FORGET TO ASK YOUR CUSTOMER HOW MUCH DATA SHOULD BE ON FLASH!
Because looks like in your case, total number of all files were aprox 8GB
You didn't tell that your controller is AU699x, and that's why you get almost perfect result with folder structure and good files.
BEFORE STARTING ANY RECOVERY PROCESS, DON'T FORGET TO ASK YOUR CUSTOMER HOW MUCH DATA SHOULD BE ON FLASH!
Because looks like in your case, total number of all files were aprox 8GB
With best regards
ACELab Technical Support
ts.acelab.eu.com
blog.acelab.eu.com
ACELab Technical Support
ts.acelab.eu.com
blog.acelab.eu.com
Re: PF530 (2C84C54B)
If it were not for the fact that the file structure shows 80% of the folders (ironically enough, the most current) are empty, I'd think you were correct. But it is good to know of the issues with AU699x controller and how they store data on the NAND.
Return to “Data Recovery from NAND Flash memory chips”
Who is online
Users browsing this forum: No registered users and 10 guests
