Hi everybody,

I need help of knowledgeable guys with my attempt to save data from suddenly died 7200.11 ST3750330AS 750Gb HDD.
By luck I have 7200.11 1TB HDD (ST31000340AS), with looks like exactly the same PCB, and Firmware different only slightly: SD35 on dead, SD15 on good 1Tb.
Both PCB have the same number 100466824, but revision is different (B on 750, and C on 1Tb)

Bad PCB does not show any signs of fried elements but it has light distinct smell of fried components.
HDD is silently dead, no spinning.
Direct swap of boards with 1TB drive, made progress in a way that drive started to spin and produce clicking noises like heads try to position themselves without success.

Based on what I read on this and other forums I assume that most likely what I need is swap EEPROM chips and I would have chance to recover my data.
I checked also TVS diodes and both of them have resistance around 500 Omh in both directions... kind of strange for diode behavior so can it be all that simile that only diodes is damaged?

I would like also have confirmation that my assumption is right and I can use PCB from 1TB on 750Gb drive.
Some elements looks slightly different so I decided to confirm before doing any further actions.

Any suggestions would be greatly appreciated!!!

Attached below are pics of both PCB:
750GB Bad: http://img843.imageshack.us/img843/5284/badei.jpg
1TB Good: http://img233.imageshack.us/img233/4426/goods.jpg

Thanks a lot!!!

Just as an update. I did took both TVS diodes out, but it did not helped a bit, HDD still dead silent with original board.
So can I try luck with 1Tb board and re-soldered EEPROM from original one or better buy 750GB HDD?

In the bad picture you put up, in the lower right of the picture is a small 8 pin chip. Swap that to the good board and it "should" work.

Good Luck

Hello,

It seems to be the famous LBA 0 problem. Not sure at 100% but check it out anyway ! Maybe it will save you.

The drive doesn't spin up with the original PCB. That's a PCB fault. The "0 LBA" issue doesn't prevent a drive from spinning up.

_________________
A backup a day keeps DR away.

A TVS diode is only a problem if it measures close to 0 ohms. Since the diodes are connected between the supply rail and ground, your meter is actually seeing the resistance of every device that is connected to the same supply. In any case, you could have compared your two boards.

To add to what has already been said, both models are members of the Moose family. When applying the SD1A firmware update, both models use the same firmware image file. Both have the same amount of cache memory (32MB), and both have the same data density (250GB per platter). The difference is that the ST3750330AS has 3 platters and 6 heads, whereas the 1TB has 4 platters and 8 heads. Based on these similarities, I would haven given your idea a go, but I'm not a DR guy.

_________________
A backup a day keeps DR away.

Thanks, everyone for replies!

And finally fzabkar is back, I hope you had no problems with flood that covered some parts of Australia.
Thanks for your respond as this is what I was hoping for.
I think on my PCB both MCU and Memory were damaged. they have some brownish shade, that initially I thought is just fingerprint, and as diodes did not helped for sure problem is still there.
Would you recommend to update 1Tb to SD1A before changing anything or I can do it with SD15?

Also just for info, can I update HDD in external enclosure under windows, I think so as seagate website had win tool but better check with guru just in case.

I don't believe Seagate's Windows executable will see the drive in a USB enclosure. AIUI, the updater needs to detect the drive's firmware modules and compare them against an update matrix in a configuration file, namely ...

http://www.users.on.net/~fzabkar/MS-SD1A.TXT

To do this, it requires vendor specific ATA commands which would be rejected by the USB-SATA bridge chip in the enclosure.

The CD ISO version of the updater does not refer to an update matrix. It only needs to match the family and model. Therefore, if the Windows EXE rejects your drive, use the CD ISO instead.

That said, I don't know whether any portion of the update image file is written to the serial flash memory. The bulk, if not all, of the firmware would be written to the platters. AISI, it would make no difference if you chose to update the firmware, except that it may address the 7200.11 BSY bug, which is a different issue.

As for the patient board, I saw the discolouration, but wasn't sure what to make of it. You can take some measurements of the onboard supplies to narrow down the fault. The post mortem may provide clues as to what happened, and it may also tell you whether the flash memory is likely to have survived.

The MCU gets a Vcore supply from the DC-DC converter immediately above it. Set your DMM on the 200 ohms range and measure the resistance between the 4R7 coil and ground. Also measure the R200 resistors.

The MCU also needs two Vio supplies, one which it shares with the SDRAM (+2.5V), and the other (+3.3V) with the serial flash memory. The +3.3V supply is derived from the DC-DC converter above the preamp connector (J4). Measure the resistance between the 2R2 coil and ground. Alternatively, measure the resistance between pins 4 and 8 of the serial flash (25FW406A = Sanyo LE25FW406A ?).

Measure the resistance between pins 1 and 66 of the SDRAM. Those are the 2.5V supply pins. Alternatively, measure the resistance between ground and pin 1 (or pin 6) of the 6-pin "1L02" device above the SDRAM. This chip is a 2.5V linear regulator.

The DC-DC converter (4R7 coil) to the left of the motor controller is the -5V (?) supply for the preamp. Pins 4,6,8, and 10 of J4 are the +/-5V supplies and the two grounds for the preamp. IIRC, pins 5 and 7 connect to the voice coil. Confirm that the -5V supply is not shorted to ground.

References:

ST1L02PM, Very low quiescent bicmos voltage regulator, Fixed output voltage: 1.8V, 2.5V, 3.3V:
http://www.datasheetarchive.com/pdf-dat ... 630896.pdf
http://www.st.com/stonline/products/lit ... /11242.pdf

HY5DU561622ETP-D43, Hynix, 256M(16Mx16) DDR SDRAM:
http://www.hynix.com/datasheet/pdf/dram ... ETP(Rev0.3).pdf

_________________
A backup a day keeps DR away.

Thanks again for helping.
I hope that flash of the donor survived...

So here is all mesurements that you asked:
1) MCU 4R7 - Ground = 330 Ohm
2) R200 = around 1 Ohm
3) 2R2 - Ground = 81 Ohm
4) Flash pins 4-8 = 144 kOhm
5) hunix 1-66 = 850 Ohm
6) 4R7 preamp - Ground = 0 Ohm

Any chance that preamp and flash survived?

Although neither reading is a problem, I expected that readings 3 and 4 would have been identical. Just to be sure, pin #1 of the flash memory is identified by a small dot on the PCB. Pin #4 is the bottom pin on the left side, and pin #8 is the topmost on the right side.

The 4R7 coil in the preamp's negative supply is testing OK. The negative supply uses a "polarity inverting buck-boost" topology, whereas the positive regulators use a "buck" topology.

http://i.cmpnet.com/powermanagementdesi ... ure_1a.jpg

Instead you should determine which pins at the preamp connector are grounded, probably 4 and 10. Then measure the resistance between ground and the remaining two pins, probably 6 and 8. One will be the +5V supply, the other will be -5V.

_________________
A backup a day keeps DR away.

You were right, I did mistake with flash measurements. So corrected ones:

4) Flash pins 4-8 = 836 Omh
7) J4 6-Ground = 852 Omh
J4 8-Ground = 454 Omh
4 and 10 as you predict were grounds.

OK, so there are no shorts on any of the supplies. This means there are no obvious culprits. Therefore I'd say the flash memory is probably OK.

I would now power up the board on its own and measure each supply voltage. Using SATA power ground as your reference, measure the voltages at the 2R2 coil (+3.3V), the centre 4R7 coil (+1.2V ?), pins 6 and 8 of the preamp connector (+/-5V), and pin #1 of the SDRAM or pin #1 of the ST1L02PM chip (+2.5V). Be very careful, as a slip of the probe may cause serious damage. Also confirm that +5V and +12V are present at the cathodes ("v" on PCB) of each of the TVS diodes.

_________________
A backup a day keeps DR away.

It might be motor fault as well . The PCB could be OK. Look at the terminal.

Before going with further measurements under load, considering risk of shortening, I would probably first try to switch eeproms and see if it gives any result.
As for the motor, no it is not a motor, as I mentioned in first post, after direct switch of boards - dead hdd started spin an click.

Yes, I think your plan is the best one. However, when you get your drive going, it would be nice if you could find the fault on the original board. AFAICS, you wouldn't need to replace the EEPROM to do this, assuming it's a power supply issue. Others may also benefit from your reverse engineering.

_________________
A backup a day keeps DR away.

Sorry for not update on the status earlier.
It took a while to find someone who would do chip swap, but after a while found one person who agreed to do it for 30$.... to bad I had no special tools to do it myself.
So after getting resulted PCB home, I started HDD, and!!! Yes it worked fine!!!
So I got all my data back and it cost me just 80$ total, not bad overall.

Thanks everyone and especially fzabkar for valuable inputs.

As for further testing on PCB... decided to skip it as afraid to accidental destroy my enclosure board, and I have no other power source to properly power it up.

Still puzzled so why board got fried, I suspected that enclosure, but it still works... so source probably was hidden somewhere else.

All:

I am new to this particular forum, but already a big fan of the bright minds on here. So anyways, I am not sure of rules/policies here -- specifically if whether what I am about to present belongs in this thread or a new one altogether, so if the admin can please advise.

My issue:

I have a ST3750330AS, firmware SD81, SN starting with 5Q. Per Seagate, this is a drive that is NOT affected by their firmware bug, but there are many people who were told the same thing, yet their drive was "bricked" with same BSY issue as SD15, and they fixed it the same way (or so is my understanding from the the posts).

In any case, for me also, one day my drive was working fine. I restart the machine, the drive is recognized that time, but Windows boot sequence shows errors. I restart again, by reset switch, this time the drive is not detected at all. I power the machine off, and stick a Windows installation disk in the drive (in case I just need to repair the installation or MBR), this time the drive detects, but the installer pretty much hangs from launching windows and the HDD busy light is lit solid red. I hit reset, and the drive is not detected by the Bios. I turn off again, carefully remove the drive, make sure it is cool, and try the drive on other ports. In all cases now, (cold boot, or boot after reset), the drive is not recognized at all (the system does hang a little trying to recognize it however). The drive does spin up, with completely normal sounds, etc.

Prior to this, there were no SMART warnings or such, or any degraded performance, noises, etc, that would imply oncoming failure. With this said, I believe it to also be BSY issue (not LBA 0) or anything else. I suppose it could be a larger PCB related issue.

Any thoughts so far?

My approach was to try the terminal connection and see if I do at least have control of the motor. There are files on the drive that I do want, and I'd like to see them in the original folder structure. I don't care for the OS, but its an NTFS drive and I'd like the original long filenames. As you can tell, I have some good and bad experiences with recovery software.

So anyway, would using the commands at the start of the BSY fix indeed determine that my PCB is ok? Spin up and spin down, should not change what is written on the platters, is that correct? What I mean to say is, by doing this, the data on the platters should stay in tact. ?

Reading the process, the piece wanted to understand was the last step, of formatting and creating partitions? I presume it is always necessary, but I am curious what it actually does to the disk and can it cause damage to the file system (making data recovery harder or worse yet impossible). My disk is a single partition of 750GB.

I appreciate you advice.

Thanks

Edit: I see you started a new thread. I am posting my reply there.

_________________
http://www.northwind.gr
SandForce SSD Recovery
Ransomware Reverse Engineering - NoMoreRansom! partners

Well everyone. I guess I have my answer, that this is not the bricking issue. That could have been there as well, but there must be something else here.

I was able to successfully complete all the steps. Everything was as predicted, nothing took longer than expected either, so with that I am hoping that would be sufficient to rule out any physical issues with the drive. (PCB, spindle motor, etc).

After finishing the process, I was able to get the drive to detect. On a cold boot, after removing and replacing the SATA cable, I can get the drive to show up in the bios. The drive shows up as 750GB, LBA supported, SMART supported, etc. I've disabled SMART, to rule that out.

Continuing on, once the drive shows up at POST, I've tried Windows and a Linux live cd. Windows hangs - while starting, I can hear it trying to read the disk. I see the disk busy light. After a long while, windows starts, but without showing the disk (even in computer manager). The linux rescue cd, boots just fine, but again, cannot mount the drive. The busy light in windows doesn't show up until late in the sequence. I had tried Linux to see if a more simple driver would help the situation.

Here is the output from the Terminal:




F3 T>/2

F3 2>Z

Spin Down Complete
Elapsed Time 0.147 msecs
F3 2>U

Spin Up Complete
Elapsed Time 10.436 secs
F3 2>/1

F3 1>N1

F3 1>
F3 T>m0,2,2,0,0,0,0,22
Max Wr Retries = 00, Max Rd Retries = 00, Max ECC T-Level = 00, Max Certify Rewr
ite Retries = 0000
User Partition Format 5% complete, Zone 00, Pass 00, LBA 00004339, ErrCode 000
00080, Elapsed Time 0 mins 05 secs
User Partition Format Successful - Elapsed Time 0 mins 05 secs

F3 T>

Let me know your thoughts on this case.


Thanks everyone!

To other members: The ongoing thread for sfdoctorp and the above problem, is in the thread linked below:

st3750330as-seagate-7200-sd81-bsy-pcb-t22203.html

I suggest that follow-up should be in that thread, and not here, to avoid duplication of effort.