WD Scorpio Black 750GB - PCB Swap - help with EEPROM

[mike_bee]

Hi All

Im a bit of a noob with this stuff, I'm an electrical eng whose neglected my electronics knowledge, so have pity on me - anyway I've tried a board swap on a WD scorpio black and can't get it to work. The old board was damaged due to overvoltage. I have some important data I need to get off the disk.

The HDD is a WD7500BPKT, the PCB is a 2060-771629-006 rev P1 (P with an underscore). There's an external EEPROM (PM25LD040) in location U12.

Theres another version of this PCB without the underscore under the P - this one uses a winbond flash (and it's different in other ways too) - this isn't the one I am using

Anyway... I've read all I can find on this website and based on that info I have already tried the following in this order:

1) Reading the EEPROM from the damaged board using a generic EEPROM programmer - I couldn't read the EEPROM unless I removed it from the PCB - I kept getting 'Overvoltage protective actions, external short IC reversed' errors on my programming software.

2) I purchased an exact replacement PCB. When I installed the PCB (before attempting to transfer contents of the U12 EEPROM), the patient HDD spins clicks but doesn't give me access to my data.

3) When I attempted to write the contents of the old EEPROM to the new one, I was not able to write to the new EEPROM (or read from it for that matter). My programmer keeps giving me the same 'Overvoltage protective actions, external short IC reversed' error. Note that I was trying to write to the EEPROM while it was still installed in circuit on the new PCB (I didn't want to desolder, etc)

4) Having had enough of that I hastily desoldered the old EEPROM and attempted to install it to the new board. After my (very poor) soldering, I installed the old EEPROM to the new board but this time the HDD didn't even spin (when I installed the new board without transferring the EEPROM it did spin but clicked and no data)

Anyway, based on these observations I have these questions that I'd like your opinion on:

A) Is it possible to read/write this EEPROM in-circuit? It doesn't look like it is (from the errors I am getting and the fact that I was able to read/write with the chip removed from the board), however I can't rule out that the errors I was getting might be due to bad pin contact with the test clip I was using to read/write the EEPROM

B) I've read about PSV mode - maybe I need to put the HDD in this mode in order to read/write the EEPROM?

C) Now the bit that confuses me is the following: I have one of the other version of the drive PCB (that I mentioned at the start of the article). When I install this PCB, the drive does not spin, however I am able to read/write this EEPROM in circuit (the winbond EEPROM). This has me a little confused

So, anyone have any thoughts/advice. Should I be able to read/write this EEPROM in circuit? My next action will be to order another PCB (as I damaged the last replacement PCB) so I am ready to make a new attempt and would like to incorporate any feedback you guys have

Cheers!

[jono-ats]

A) Not often / not likely. Your EEPROM programmer is trying to energize everything connected to the Vcc on the PCB. Isolate that one lead from the rest of the circuit and you may be able to do it. But if you are going to go through that much trouble, just pull it.

B) You can read / write in kernel mode if you know what you are doing and have the tools.

C) ??

Regarding your final question(s) -see "A" above. Did you ruin the traces trying to install the EEPROM? If so, you should let someone else with the tools and expertise do it for you. Or try to repair the traces yourself.

I'll bet fzabkar, who lives in Oz, will gladly do this for you for $5.00 or $10.00. Contact him through this forum.

[fzabkar]

I'll bet fzabkar, who lives in Oz, will gladly do this for you for $5.00 or $10.00.

My advice is free, but my labour is not. In any case I'm retired.

That said, the OP's local TV/AV repairer would have charged him about AU$30 to transplant the chip. Some board suppliers include such a service for US$10.

[mike_bee]

Thanks guys, no worries fzabkar. I will proceed by ordering a new PCB and spending alot more time/attention/appropriate tools to remove the EEPROM, program out of circuit, and resolder. See how we go, thanks guys

[fzabkar]

@mike_bee, could you upload your EEPROM dump? I could try to verify its integrity (checksums) for you.

Could you also tell us the 2061 numbers on the PCB stickers, for all your boards? I suspect that these numbers would reflect the loaded components, whereas the 2060 numbers would relate to the PCB artwork.

As for reading/writing the EEPROM in-circuit, you could use WDR-UDMA or WD HD Pro software (~US$150).

FWIW, here is a thread where a board swap and U12 transfer produced an unexplained no-spin result:
wd5000bmvv-t22207.html

It seems that "compatible" boards are not always compatible.

[mike_bee]

Thanks for that thread although it makes me a bit uneasy about my chances of success :s haha

I have uploaded the EEPROM .bin file here:

http://dl.dropbox.com/u/64887924/EEPROM_20120301.BIN

(hopefully this is a format you were expecting, if not let me know)

When you say the 'PCB stickers' do you mean the white square sticker on the PCB?

I have only 1 of the PCBs with me at the moment (the donor) and it has the square sticker but there's no numbers starting with 2061, all it has is '771629-206' and some other alphanumerics about 8-10 chars long.

Thanks, Michael

[mike_bee]

OK so the sticker numbers are:

* Patient board: 771629-106

* Donor board 1: 771629-206

(this is the board I have been trying the most, the one with the PM25LD040 EEPROM, I've also noticed that this has a different RAM chip to the patient board, the MCU looks the same)

* Donor board 2: 771629-106 (this is the board with the Winbond EEPROM)

[fzabkar]

At the beginning of the ROM is a table that contains the starting offset and size of 8 blocks of code. Each entry in the table occupies 32 bytes. The last byte is a checksum of the previous 31 bytes.

Code:

5A 02 00 00 9A 18 00 00 98 18 00 00 00 01 00 00
40 08 01 00 40 08 01 00 00 00 00 00 00 00 00 51

01 0C 00 00 29 1E 00 00 28 1E 00 00 9A 19 00 00
00 00 80 28 FF FF FF FF 02 0A 00 00 00 00 00 FD

02 01 00 00 0D 99 00 00 0C 99 00 00 C3 37 00 00
00 00 00 00 FF FF FF FF 02 0A 00 00 00 C4 00 14

03 01 00 00 B1 04 00 00 B0 04 00 00 D0 D0 00 00
EC F7 00 00 FF FF FF FF 02 0A 00 00 70 05 00 6D

04 03 00 00 4D 02 00 00 4C 02 00 00 81 D5 00 00
88 00 00 04 FF FF FF FF 02 0A 00 00 1C 03 00 AD

05 03 00 00 11 02 00 00 10 02 00 00 CE D7 00 00
08 08 00 28 FF FF FF FF 02 0A 00 00 48 03 00 5D

06 01 02 00 2D B3 01 00 2C B3 01 00 DF D9 00 00
00 50 02 28 FF FF FF FF 02 0A 00 00 8C 30 00 C0

07 01 02 00 01 C9 01 00 00 C9 01 00 0C 8D 02 00
30 82 E4 FF 00 00 00 00 02 0A 00 00 9C 6C 00 E3


If we compute the checksums of each entry in the table, we have ...

Code:

Block #  Calculated / Stored
           8-bit Checksum
----------------------------
0         51 / 51
1         FD / FD
2         14 / 14
3         6D / 6D
4         AD / AD
5         5D / 5D
6         C0 / C0
7         E3 / E3


Therefore it appears that the table is OK.

If we now turn to the actual blocks of code/data, we find that each has an additional checksum byte at the end of the block.

For example, block #0 begins at 0x0100 and has a length of 0x1898 bytes (little endian). Its checksum byte is located at offset 0x1999 (or 0x1998 ?).

5A 02 00 00 9A 18 00 00 98 18 00 00 00 01 00 00
40 08 01 00 40 08 01 00 00 00 00 00 00 00 00 51

Similarly, block #1 begins at 0x199A and has a length of 0x1E28 bytes. Its checksum byte is located at offset 0x37C2.

01 0C 00 00 29 1E 00 00 28 1E 00 00 9A 19 00 00
00 00 80 28 FF FF FF FF 02 0A 00 00 00 00 00 FD

If we compute the checksums of each block, we have ...

Code:

Block #   Offset  Length  Calculated / Stored
                           8-bit Checksum
------------------------------------------------------
0           100    1898    AE / 7E or 43  ???
1          199A    1E28    E7 / A0
2          37C3    990C    CE / 26
3          D0D0     4B0    14 / 14
4          D581     24C    D6 / D6
5          D7CE     210    0D / 0D
6          D9DF   1B32C    51 / 51 
7         28D0C   1C900    BA / BA


AISI, the first three blocks have checksum errors. I could be wrong, but I have performed the same analysis on a known good ROYL ROM and found that its checksums were consistent with the format as outlined above.

The end of the ROM has several ROYL MODs. These are checksummed differently. If they are intact, then that is the most important thing. That's because they contain your drive's unique "adaptive" data. I will check these MODs and follow up with another post as soon as I can.

[mike_bee]

Thanks for the descriptive response mate and your ongoing efforts, much appreciated.

[fzabkar]

Each ROM MOD begins with a "ROYL" header.

Offsets 0x08/0x09 are the MOD ID (little endian).

Offsets 0x0B/0x0A are the size in sectors.

Offsets 0x0C - 0x0F are a 32-bit little endian checksum which is chosen such that the sum of the contents is 0x00000000.

The following table lists the MODs:

Code:

ROYL   Offset  Length   Checksum bytes
MOD #                   
--------------------------------------
47     7F1D5    400      A726BA3C
4F     7F5D5    400      75BBA8A6
0D     7F9D5     8E      8421F330
30     7FA63    400      4CF43BA4
0B     7FE63    14F      71CDEED8
0A     7FFB2     3E      59E0A40A


MOD 0D contains your firmware version (01.01A01) and your model number (WD7500BPKT-00PK4T0).

MOD 0B is a directory of the ROM MODs.

Here are my results after extracting each MOD and computing its checksum:

chksum -32 MOD47.BIN
MOD47.BIN: Checksum = 0x00000000

chksum -32 MOD4F.BIN
MOD4F.BIN: Checksum = 0x00000000

chksum -32 MOD0D.BIN
MOD0D.BIN: Checksum = 0x00000000

chksum -32 MOD30.BIN
MOD30.BIN: Checksum = 0x00000000

chksum -32 MOD0B.BIN
MOD0B.BIN: Checksum = 0x00000000

chksum -32 MOD0A.BIN
MOD0A.BIN: Checksum = 0x00000000

Therefore it appears that each MOD is intact.

If I'm correct in my analysis (???), and the first three code blocks are corrupt, then it would appear that you could reconstruct your ROM by taking an image from a drive with identical firmware, and then pasting your ROM MODs over this image.

If you have a drive with the same firmware, then we should be able to read its ROM in-circuit using freeware. Otherwise we need to search for suitable resources. Often the professionals will upload their ROM and SA modules to various databases. If we find a suitable image, I'll do the same checks just to make sure I haven't got things horribly wrong.

BTW, I'm not a data recovery professional, so you should view my advice with caution.

[mike_bee]

Thanks mate, this is a bit to digest - I will have to go away and do some homework. Thanks all for your efforts