Western Digital WD10EACS-00ZJB0 - fried PCB - unscupulous vendor ==> technical dilemma?

[sbpetrack]

I have a Western Digital WD10EACS-00ZJB0; the PCB has the number 2060-701474-002 REV A etched along one edge. It’s a 1.5 TB drive in an external enclosure. I recently moved to the UK from the USA, and although the power claimed to be 120-240V, very shortly after first plugging it in in my new office, the drive ceased to spin. As you can see from the picture of the burnt SMOOTH chip, it seemed possible/likely that the PCB was friend.

From my all-too-quick web-search, I understood that older drives often can be revived by a simple PCB swap. As the drive is not all that new, I thought it was worth a shot. I found a vendor here in the UK who sold me a new PCB for the drive. The letter that accompanied the drive said that that should be enough “90% of the time”, but that if I fell into the unlucky 10% I should send them the whole drive for an estimate.

So I swaped the PCB and put the disk into a new, locally-bought enclosure. And while (or should I say “whilst” :)) it doesn’t appear in Explorer, if I look for the Disk in Administrative Tools -> Storage -> Disk Management, it shows up perfectly as an unitialized 2048MB drive, and asks me to initialize the drive. Remember that I bought it as a 1.5TB drive; but the pleasure of seeing an extra 500GB on the disk was somewhat mitigated by the absence of any data at all. I’ve now read many posts on this forum, and perhaps I should show you the Marvel MCU and position U12 on the PCB:

and

From what I’ve learned from this forum, my guess is that this just means that the new PCB has marked absolutely no sectors as bad, which is why I’m seeing the larger disc capacity. But of course I want my data, which leads me to ask several questions:

1. Is this clear evidence of an unscrupulous vendor? Was it clear to the vendor from the beginning that the PCB would either need an EPROM-transplant or an MCU-transplant, and this was just his way to get me to send him the whole disk? Or … it possible that chkdsk or spinrite or some other disk-repair software can now step in and by brute force recreate the list of bad sectors on the new PCB?

2. It has been said in several places in this forum that some vendors will offer the “PCB adaptation transfer” for free when one buys the PCB. Given what the vendor has already done, am I being an ■■■■■ to write to him and ask him to transfer the MCU so that my already sunk-with-him investment can work? Or perhaps someone can recommend a vendor in the UK who might agree to do just the chip-transfer (for example in exchange for receiving the same margin as he would normally get if I bought the board from him too)…

3. Can the wise members of this forum tell just from the picture of the SMOOTH chip here how if a MCU-transplant is even worth the try? I assume that it is, given the fact that Disk Management sees the disc and is asking me to initilize it.

Of course I’d be thrilled if I can run chkdsk and hope that it will piece the disk back together again (even if it takes several days of work). But I don’t want to just “run it and see”, if there is a chance that chkdsk will merrily try its best to reconstruct the correct mappings, but in fact produce a completely garbled set of files as a result.

I certainly don’t mind naming the vendor, if that might help someone on the forum identify if I should trust him/her, now that he has already “sold me noodles,” as one says in Yiddish.

Thanks for any useful advice; I appreciate it very much. I just want my data back…

-scott

[Alucardx23]

For PCB replacement advice I recommend you to PM fzabkar.

[fzabkar]

A WD10EACS is a 1TB model, not 1.5TB.

The SMOOTH chip is damaged on the side that drives the spindle motor. The side that controls the board’s switchmode power supplies, including the Vcore and Vio supplies for the MCU, is not damaged, so I would expect that the MCU has probably survived.

As for your vendor’s contention that a straight PCB swap is sufficient to revive your drive “90% of the time”, he is either a liar, or he is ignorant. The fact that he is inviting you to send the drive to him for an estimate would suggest that he is a data recovery professional (or thinks he is), in which case one would have to ask, does he do logical recoveries, or physical recoveries, or both? If he does physical recoveries, then he would be well aware that your actual chances would be very slim, probably less than 5% (from what I’ve seen at HDD Guru).

In your case you require a “PCB adaptation” service. Generally speaking, the "ROM’ on your board can be reconstructed using commercial data recovery software. This software accesses the hidden System Area on the platters and retrieves various firmware modules which are then reassembled into a ROM image which can then be written to the MCU’s flash memory. This is a simple, single-click procedure which requires no soldering. That said, some firmware versions do not have the required ROM backup on the platters, so the procedure in those cases may require an MCU transplant, or some other software method which I don’t understand (eg ARCO).

It appears that you have seen some of my posts which identify those PCB vendors who do in fact provide a firmware transfer service. Although my posts may appear spam-like, I have no association with any of these suppliers. In recent times I’ve been trying to make people aware of the pitfalls in dealing with HDD PCB vendors, particularly those who advertise their wares as being for “data recovery only”. It seems that you may have been scammed by one of them. Their modus operandi appears to be to sell you a PCB which they know will not work, and then offer you a discounted “data recovery”. So instead of paying US$50 for a PCB plus firmware transfer, you end up being stung for a $1K data recovery, or you take the $50 loss.

In short, it appears that your vendor is either grossly incompetent or unscrupulous, so he should not be trusted with your data. BTW, it’s good that he put the “90%” claim in writing.

As for what to do now, I suggest you contact donordrives.com and enquire about their “PCB adaptation” service.

BTW, your replacement board is reporting bogus information about your drive. For example, the 2TiB capacity (not 2TB) is symptomatic of an all-ones data pattern in the total LBAs count, ie 0xFFFFFFFFFFFF.

On final question. What are the date codes on the replacement PCB? For example, your MCU has a YYWW (Year / Week) date code of 0737, ie week 37 of 2007. There may also be date codes on the other chips and on the PCB.

The PCB in the following photo has date codes of 741 for the hynix SDRAM, 0753 for the MCU, and 4107 (WWYY) on the PCB.

http://www.pcbfordatarecovery.com/media/catalog/product/cache/2/image/9df78eab33525d08d6e5fb8d27136e95/W/D/WD10EACS-14ZJB0_2060-701474-004_REV_A_PCB.JPG

[sbpetrack]

On[e] final question. What are the date codes on the replacement PCB? For example, your MCU has a YYWW (Year / Week) >date code of 0737, ie week 37 of 2007. There may also be date codes on the other chips and on the PCB.

As far as I could see, this “final” question was also your first question. Let me know please if/what I can tell you in addition to the answer to this question about date codes.

The original PCB has date code 3207;

The original MCU reads as follows:

M

88i6745-TFJ1

YPMA191AE

  0737 B1P

        TW

                   C125

The original hynix reads as follows:

hynix  740E   C

HY57V281620ETP - 5

KOR

NCDN4086DO4

The Original SMOOTH reads as follows:

L6?85   3.0

9916V  VP

?? 99  738

     st      e3

The small chip that sits between the Marvell and the disk drive connector reads:

25.000

E8463878

On the other side there is bar code reading:

2061-701474-300-AA    XC 405 14ZN M 0005200 8205

And there is printed in white ink on the board:

Dynamic KsMOUO

E15030

On the new PCB:

the MCU reads:

88i6745-TFJ1

TYSM

0808 B1S

whilst the HYNIX says:

hynix,     812E   C

HY57V28162OETP-5

and the SMOOTH CHIP’s paramterrs are

SMOOTH

L6284    3.1

D

AAACN   D1

TWN  99  891

           st    e3

Hope this is of interest.

Please note that I asked in a different post in this forum a general question about the firmware parameters that need to be adapted. I asked:

1. Are the only parameters a list of “bad blocks”, or are there other hidden bits of content in addition?

2. Some years ago I bought a disk repair and data recovery software program called “SpinRite.”  If the answer to the previous question is " yes,"  is it possible that the adaptation can be performed by the function in Spinrite which (in one of its modes) does several read/write cycles of every sector of the disk (and recreates the master list of bad sectors for the drives firmware?

In a different forum, dediated to hardware drives and their failures, I was given advice that at this point, I should just do a quick NTFS format of the disk, and then use on it any program meant to deal with data recovery on a disk which was “accidentally formatted.”

This sounds too good to be true, but it’s consistent with the general belief here that !) one needs to recreate the table of bad sectors, and that’s all.

[fzabkar]

The most recent date code on the first PCB appears to be week 40 of 2007 whereas the replacement PCB appears to have been manufactured around week 08 of 2008. That’s a difference of about 5 months. ISTM that the chance of them having the same firmware would be remote, and the chance that they would have similar adaptives would be extremely remote. I suspect that your overall chances of success were close to nil.

[sbpetrack]

I appreciate your looking at all this very much. As you can imagine, without real experience in this, one can’t even know if a 5-month difference in manufacture date is “very little” or “huge.”

Am I correct to summarize things as follows:

1. Although the simple PCB-swap is highly likely to fail under any OS, etc. you **do** believe that it is worth sending the two PCBs to somone can do a reliable PCB adaptation trasnfer, as this is reasonably like to make the drive readable, at least for enough time to get the data off the disk.

2.You can not really tell without trying if a the transfer of adaptation from the old PCB to the new can be done with some oridinary recovery softawre, or if one needs to desolder the MCU from the “fried” Board and use it to replace the MCU in the replacement.

3. Is this “adaptation information” just the list of bad blocks ? Or are there more parameters than those. In particular, if you happen to know the recovery software SpinRite, do you think it might be possible to do use SprinRite to adapt the MCU to the new situation?

[fzabkar]

I believe that a PCB adaptation service is your only option, whether that involves transferring the MCU, or whether the ROM can be reconstructed from the firmware modules on the platters. The latter option requires that you send your drive to your supplier. You would need to contact your supplier for confirmation.

Ordinary recovery software, including SpinRite, will not have access to your data under the present circumstances. The drive is unable to access its firmware in the System Area (SA) on the platters, so it powers up in some kind of safe mode. To access the SA, you would need specialist data recovery tools.

The “adaptive” data and bad block data are two different things. The adaptives are tuned parameters which reflect the physical differences of each head. For example, some heads have better frequency response than others, and the distances between their read and write elements vary. WD accounts for these physical differences by implementing Variable Bits Per Inch (VBPI) and Variable Tracks Per Inch (VTPI). The calibration procedure involves Advanced Read Channel Optimization (ARCO), Advanced Servo Channel Optimization (ASCO), and also PRML Enhanced Read Channel Optimization (PERCO).

The following article gives some insight into “zones, tracks, sectors, servo system, variable density and other stuff”:
http://hddscan.com/doc/HDD_Tracks_and_Zones.html

Adaptive data are stored at the end of the flash memory on the PCB. They are needed by the MCU to enable it to locate the SA on the platters. If the donor PCB’s adaptives are too far out of tolerance with the patient’s, then the MCU will not be able to access the SA.

When a drive powers up, the MCU initiates a power-on self test (POST) during which it confirms the integrity of the SDRAM and the checksums of the flash memory, plus several other things. The MCU then copies the contents of flash memory to SDRAM and transfers control to it. The boot code consults the adaptives to determine the location of the SA, and then attempts to retrieve the run-time firmware modules, plus important data such as the bad block map and translator. The primary and grown defect lists and logical-to-physical sector translator are stored on the platters, not on the PCB.

The following article explains a little about the firmware and the SA:
http://forum.hddguru.com/newbie-info-from-and-for-newbies-about-firmware-etc- t6562-20.html

Here are SA and “ROM” (flash memory) firmware dumps for two WD10EACS examples:
http://www.datadonor.net/HD%20Western%20Digital/WDC%20WD10EACS-32ZJB0.rar
http://www.datadonor.net/HD%20Western%20Digital/Royl%20Series/WDC%20WD10EACS-00D6B0.rar

As for SpinRite, data recovery professionals will tell you that at best it is useless, and at worst it can be a drive killer. AIUI, this is because the typical failure mechanism in today’s drives is head damage. SpinRite’s repeated attempts to recover a particular sector only serve to accelerate the total failure of the weak head.

When a head slaps the platter (“thermal asperity”) it sometimes sustains irreversible damage to its read element, resulting in a degradation of the read signal. If a drive is clicking severely, then a “weak” head is probably the cause. SpinRite assumes that the media is at fault rather than the head, so it hammers a “bad” sector up to several thousand times, hoping for one successful read. Then, instead of backing up these hard won data to a different drive, SpinRite writes the recovered data back to the damaged drive. The patient drive then reallocates the problematic sector to a (hopefully good) spare.

[sbpetrack]

Thank you for taking the time to write such an informative reply. It goes without saying that I’m not so thrilled at the answer, but it goes with even less saying that things could be much, much worse. And I’m very grateful for the explanations and pointers to more information. My main mistake (or rather, my main ignorance) was to imagine that some sort of ordinary software driver could read and write the flash memory across the external SATA interface.

Not to beat a dead horse (or rather, a dead hard drive), but I do imagine it wouldn’t be too hard for the drive manufacturers to add some firmware code to enable just that (i.e. reading and writing the flash via the external bus. That might make a certain number of cases that require specialized hardnware or hardware expertise unecessary. But perhaps those cases don’t happen all that often.

again, thanks