OK here is the story, I had a drive come in from a business that the machine was DOA, They had lost it during a power spike. I had a look at the drive and just swapped a board to see if anything happened, the drive made some noise which was better than the old card did . Anyway I went to recover the adaptive data off the old card and it didn't detect the eeprom. So I unsoldered it as I have done may times before but the ground and Write protect legs literally fell off the chip! OK I jerry rigged a Upside down spider with probes that could contact the wires into the chip and It was correctly identified. I read the data and then inspected it, well it was very sparse ? OK not deterred I read it again a little better. After 27 read cycles I don't have single 2 files that are identical! What I am hoping is if someone had a copy of a good st500dm002 adaptive data that I could check my files against. I do realize that I can't use this data to recover my drive but I should give me a insight into weather I have any chance of recovery. Any help would be appreciated.

Thanks
Michael Smith
PS> my reader consistently reads data from W25x40's and I tested it to make sure, I get the right device code before and after the read. Possible fried eeprom?

Which programmer do you use?
I use Willem 5.0, sometimes happens to get bad reading rom (expecially if pins are dirty or if u use a long cable for SOP8 clip adapter), in this case may help changing timings in bar tWP and tWC


I don't have a copy of st500dm002 adaptive, but i have a backup ROM from ST1000DL002 and ST1500DL001.
You may give a look to both:

_________________
My firmware database:
https://mega.nz/folder/O01DkBRI

I am using a GQ-4X and the lead is a little long for the job but my other reader lead is longer and not shielded it works well. Thanks for the files I will have a look tonight. I have files for newer drives and that indicates to me that this data may be corrupt, The business has vinyl cutting data on the drive they need to recover.

Thanks
Michael Smith

I notice that each of the sample BINs has text strings that you could examine.

There is "csiD" at offset 0x10.

Elsewhere there are the model number, serial number, and a date code in MMDDYY format.

02252012
ST1000DL002-9TT153
ST1000DL002-9TT153
W1V12K520000M23249X8
W1V12K52

5YD009NV0000S026NT1U
ST1500DL001
03202010
ST1500DL001-9VT15L
5YD009NV

I would compare any such strings that you find against the expected strings. If you consistently find a difference in a particular bit, then this would suggest an internal problem within the EEPROM, possibly the data bus.

I would also examine the large blocks of 0x00 and 0xFF bytes. Look for bit differences there also.

FWIW, I notice that offset 0x04 points to the starting address of what appears to be a block of data.

_________________
A backup a day keeps DR away.

Well thats why I think this one is toast I couldn't find the serial or model numbers or csiD anywhere in the file. I was considering using a Hex editor but somewhere there will be a checksum that will cause it too baulk for sure or just one piece of dud data will kill the checksum. Thats why I need to check it agaisnt another st500dm002 to see if the format was consistant. Its looking bad for this drives data. In some of the reads 0x00 is all FF FF So I can discount them straight up. My test rig cable is 5 inches long and it is screened...maybe I was wrong, I think it may be a paper weight.
Better get my glasses....
Cheers
Michael Smith

What supply voltage are you using?

What kind of damage did the PCB sustain? Perhaps a post mortem would be in order. I could help you identify the voltage test points if need be.

_________________
A backup a day keeps DR away.

Your programmer reads via USB, my willem reads via LPT.
USB maybe reads the rom too fast, causing a lot of errors.

If you can, try to slow down the read speed.

_________________
My firmware database:
https://mega.nz/folder/O01DkBRI

Hi Fzabkar and Michael , the drive was in a desktop that suffered a catastrophic failure after a storm. The machine went to a computer repair shop, who sold them a new Win 8 machine but couldn't recover any data. Both tvs where crook but even with them disconnected ..nothing. I used another 7200.12 board from a 500g drive I had here and it at least clicked along. I tried to read eeprom but I only got a empty file and no ID, that's when I tried to remove the chip and the leg just fell off. I made my jig and used my 500 times microscope to examine the chip and find the contact area. The earth and Write protect where damaged. I placed the chip upside down to give better access to the damaged area. I glued it down so it will not move and inserted the probes. I could then read the ID but some times even that was corrupt. I slowed the read speed right down, It takes nearly 5 minutes to read the data as apposed to the 56 seconds usually. The Programmer consistently reads data all the time from other drives. I have a new control card ready to go but I need good data. The serial is Z2AA709B, ST500DM002,KC43,DATE CODE 12037 date of manufacture 07/2011,7200.12 .......maybe I could hack a existing file if I could find one close enough. I realize the adaptive data would be different but I only need it to work once!

Thanks for your help so far.
Regards
Michael Smith

So you can read the SA even if the control card has the wrong adaptive data or do they remove the control card completely and directly interface the SA on the disk?
The nearest Pro is 3600 km away and I doubt weather the customer would consider the cost, the final call is the customers. I am still learning about HDD structure. I am more at home with Electronic communication equipment, At work we just toss drives because we always have offsite backups. This customer still doesn't backup so I guess it will have work to at some stage.

Regards
Michael Smith

Completely wrong. No copy an SA!

_________________
Murphy was an optimist

Datarecovery in Belgium, Holland, France and Germany
Datarecoverytools http://www.drtools.eu

Damage to both TVS diodes sounds serious.

Does your board look like any of these?

http://www.google.com/search?q=10061746 ... l&tbm=isch

In this photo, were any of the inductors (or zero-ohm resistors) burnt?
http://pcb-hdd.com/images/ST2000DL003%2 ... EAGATE.JPG

The inductors are the components nearest the +12V and +5V SATA power pins. They are in series with each of the TVS diodes. The fix is usually to remove the diode and bridge the associated inductors, as long as there is no additional damage. It's a bit late for that now, though.

BTW, I'd measure the resistance between the Vcc and Ground pins at the EEPROM location on the PCB. If it's shorted, then that would explain why the EEPROM didn't read in-circuit.

_________________
A backup a day keeps DR away.

inductors where OK just the TVS and it still didn't do anything Pulled the TVS before trying to read the chip. I knew the board wasn't working because I swapped it out with a another board that atleast done something. This was before I decided to read the eeprom. It doesn't have good data from what I can tell I didn't read between the Vcc and earth.
I think this drive is beyond my skill set, My first failed data recovery. I will talk to my customer, the power supply in the tower was toasted looks like 240 volts went threw everythink MOBO is toast too CPU dead..
Thanks for the help guys!
looks like I have a paper weight.
Michael Smith

Hacking sounds like fun, but not with live data. I have no idea what the solution entails, but one way to locate the checksum in the flash memory would be to take a working drive, backup its flash, configure the drive to Power Up In Standby (PUIS), and then backup the flash again. I expect that you will find two differences - the PUIS byte(s) and the checksum byte(s).

_________________
A backup a day keeps DR away.

If you can't read the original eeprom its no use.

_________________
Murphy was an optimist

Datarecovery in Belgium, Holland, France and Germany
Datarecoverytools http://www.drtools.eu