PC3000 flash issue discovered
Posted: Fri Jun 02, 2017 3:40 pm
Although this isn't such a big deal, once you are aware of it, it is when you aren't. I've been working on a 128GB thumb drive recovery with 2 chips, each with 2 dumps. The initial read, after ECC showed about 60% errors in each chip, but I was able to get what looked to be a relatively clean recovery. But, after the client got it back, it was reported that lots of data was missing.
So, I've been digging away at re-reading the bad sectors via the map in the transformation graph on PC3K Flash. But, it would appear that the default dump order (0,1,2,3) in the transformation graph is based on the initial dumps which, for some reason, were saved as 2,3,0,1.
So, I've been digging away at re-reading the bad sectors via the map in the transformation graph on PC3K Flash. But, it would appear that the default dump order (0,1,2,3) in the transformation graph is based on the initial dumps which, for some reason, were saved as 2,3,0,1.
So, when I was re-reading damaged sectors on dumps 0 & 1 on the transformation graph, I was reading them from the first chip thinking that I was merging those sectors into the dumps from first chip. However, it seems that I was merging the sectors from the first chip into the dumps from the second chip and vice versa. Basically, I've spent a couple months on this project and have to start all over again.Chip 0 - dump 0 - 0005.dmp
Chip 0 - dump 1 - 0006.dmp
Chip 1 - dump 0 - 0003.dmp
Chip 1 - dump 1 - 0004.dmp
The default order in the transformation graph is:
0 - 0003.dmp (chip 1, dump 0)
1 - 0004.dmp (chip 1, dump 1)
2 - 0005.dmp (chip 0, dump 0)
3 - 0006.dmp (chip 0, dump 1)