Drive recognised but every sector is bad

[fzabkar]

Google tells me that this is the OP's PCB:

http://g02.a.alicdn.com/kf/HTB1OdflHVXX ... 4-2061.jpg

http://g03.a.alicdn.com/kf/HTB1HFzyHVXX ... 4-2061.jpg

[Taserx]

Google tells me that this is the OP's PCB:

http://g02.a.alicdn.com/kf/HTB1OdflHVXX ... 4-2061.jpg

http://g03.a.alicdn.com/kf/HTB1HFzyHVXX ... 4-2061.jpg

Ok thanks for all the help guys.

That is the board I've got. There is a big M on the MCU. I'll download MDMarvel Demo.

Because there are no copies from head 1, could this mean that head 1 is not working? Or would the drive just be clicking and be giving me nothing if head 1 was dead?

[Taserx]

Also sorry it seems like I'm taking so long to reply, the mods still need to approve each of my posts.

Edit: Or maybe just some? I wrote one this morning saying that is my PCB and the MCU does have a big M on it. I'll download the MDR demo.

Because there was only modules dumped from one head, does that indicate that only one head is working? I would have thought if one head was dead it would just click and I'd get no response?

[fzabkar]

NazYura's track dumps include some tracks from head 1.

The approach that most people seem to take is to read partial copies of the damaged modules from each head, then stitch together a good module from the available good sectors. With any luck, the damaged sectors will be zero-filled. A checksum test will confirm this.

If you can't get suitable results from the demo-ware, then we can manually attempt to read the damaged modules with MHDD (freeware). However, it will be more tedious as we will need to write scripts.

BTW, SeDiv demo is another option.

http://sediv2008.narod.ru/Easy3.9Passwo ... 567890.rar
http://sediv2008.narod.ru/Settings.rar

SeDiv WD Read ROM & Modules:
https://www.youtube.com/watch?v=9UgFfhkkAwY

[Taserx]

Ok I've got MD Marvel demo going. It says the Family is Mammoth. Does this change anything?

I've attached a screen shot of the output from reading the modules, they appear to have been backed up.

Should I proceed with using WDR DEMO and the quick format with P-List command to regenerate the translator?

Attachments

[Taserx]

This is just another screenshot showing the drive family.

Attachments

[fzabkar]

Please don't write anything to your drive.

NazYura's tool found MOD 20 but this doesn't appear in the WDMarvel screenshot.

Edit: The reason is that MOD 20 is not in the module directory, so that is OK.

Code:

ID   TRAK        SECTOR  SIZE
------------------------------
0x01 0x01 0x0000 0x0001 0x0002
0x02 0x02 0x0000 0x0006 0x0002
....
0x1E 0x01 0x0000 0x00B8 0x0015
0x21 0x08 0x0000 0x0001 0x0033

Also, NazYura couldn't read MOD 2D, but this is absent from WDMarvel's error report. Was this module read successfully by WDMarvel?

Modules E1 - E9 are not required for normal operation (they are manufacturing logs) so they can be ignored.

Your second WDMarvel screenshot is complaining about a ROM Dir error (MOD 0B) and errors in SA MODs 109 and 103. These modules only exist in Marvell ROYL architecture. Your drive's firmware architecture is pre-ROYL, so the drive appears to have been incorrectly identified by WDMarvel.

Try to read MOD 32. It consists of 8 sectors. Even if you can only read the first sector of either copy, this will be enough.

[fzabkar]

Here are the resources for a WD800JB-00FMA0:

http://files.hddguru.com/index.php?acti ... y/Mammoth&

You can see what MOD 32 should look like.

[fzabkar]

Here are the resources for a WD800JB-00FMA0:

http://files.hddguru.com/index.php?acti ... y/Mammoth&

You can see what MOD 32 should look like.

Here are the resources for a WD400JB-00FMA0:

http://files.hddguru.com/download/PC-30 ... 200435.rar

[Taserx]

Yes, Module 2D appears to have been read by WD Marvel. I've uploaded it here
http://www.filedropper.com/2d

When I try to make it read Mod 32 I get this error

Error reading module ID32, state - DISK_DAM_ERROR

Is there any other way to try to read it?

Also sorry for the rookie question, what program do I use to open and view module files? WD Marvel outputs them as .MOD files, in the resources you linked me to they are .RPM files. I'm assuming the extension doesn't actually matter, but I'm not sure how to correctly open/view either of them. Thanks

[fzabkar]

The extension doesn't matter. Just view them in a hex editor. I use HxD (freeware).

https://mh-nexus.de/en/hxd/

As for module 32, you might get lucky if you keep trying. The other modules appear to have intermittent problems. For example, NazYura had trouble reading the En modules, but the tool was able to read the tracks on which they are located.

Alternatively, download MHDD ver 4.5 and copy the "rdmod32" file to the SCRIPTS subdirectory and the rm32.bin file to the MHDD directory.

http://hddguru.com/software/2005.10.02-MHDD/

Then type ...

.rdmod32

... to execute the script.

This should read module 32 one sector at a time. Each sector should be written to a separate file -- 321.bin, 322.bin, 323.bin, ... 327.bin.

Code:

;script name: rdmod32
;reads module 32 on WD Marvell drives
;
reset
waitnbsy

; VSC enable

regs = $45 $0b $00 $44 $57 $a0 $80
waitnbsy

; send VSC to read module 32

regs = $d6 $01 $be $4f $c2 $a0 $b0
waitnbsy
checkdrq
sectorsfrom = rm32.bin

%modsec = 0

; reads module 32, one sector at a time
; and creates one file for each sector

@loop:

%modsec = %modsec + 1
if %modsec = 9 @end

waitnbsy
regs = $d5 $01 $bf $4f $c2 $a0 $b0
waitnbsy
%error = iserror
if %error = 1 @loop
checkdrq
sectorsto = 32%modsec.bin

goto @loop

@end:

512 byte rm32.bin

Code:

0x000   08 00 01 00 32 00 00 00 00 00 00 00 00 00 00 00
.....
0x1F0   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Attachments

read32.rar

(440 Bytes) Downloaded 373 times

[Taserx]

Ok thanks I'll give that a go. Do we need to attain some information unique to the drive within Mod 32 before we regenerate it?

[fzabkar]

In your Marvell firmware architecture module 32 is the "relo list". This can simply be cleared -- it does not need to be "regenerated".

For example, this is MOD 32 from my WD2500BB Starling drive:

Code:

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00000000  08 14 31 84 32 31 35 30 30 3F 00 00 00 00 00 00  ..1„21500?......
00000010  00 00 00 00 00 00 14 00 5C 00 00 00 A0 00 00 00
00000020  DC 1A 00 00 F8 27 00 00 FC 02 00 00 1C 00 FC 02
00000030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000040  D0 90 6B 1D A4 65 58 1D B2 46 01 00 00 40 00 00
00000050  FC 02 00 00 6F CE 12 00 13 34 6B 1D 00 00 00 00
........
000027F0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

This module is clear. Offset 0x18 points to the location of the first data block (0x5C). The remaining data blocks are located at 0xA0, 0x1ADC and 0x27F8. All blocks are empty. Clearing the relo list involves writing zeros to these blocks. That's why I believe that only the first sector is important.

[fzabkar]

Here are the SMART data that I extracted from MOD 23 at offset 0x5E4A. These represent the initial state of the drive after manufacture.

Code:

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B

00000000  01 0B 00 64 FD 00 00 00 00 00 00 00
0000000C  03 07 00 64 FD 00 00 00 00 00 00 00
00000018  04 32 00 64 FD 00 00 00 00 00 00 00
00000024  05 33 00 64 FD 00 00 00 00 00 00 00
00000030  07 0B 00 64 FD 00 00 00 00 00 00 00
0000003C  09 32 00 64 FD 00 00 00 00 00 00 00
00000048  0A 13 00 64 FD 00 00 00 00 00 00 00
00000054  0B 13 00 64 FD 00 00 00 00 00 00 00
00000060  0C 32 00 64 FD 00 00 00 00 00 00 00
0000006C  C2 22 00 64 FD 00 00 00 00 00 00 00
00000078  C4 32 00 64 FD 00 00 00 00 00 00 00
00000084  C5 12 00 64 FD 00 00 00 00 00 00 00
00000090  C6 12 00 64 FD 00 00 00 00 00 00 00
0000009C  C7 0A 00 64 FD 00 00 00 00 00 00 00
000000A8  C8 09 00 64 FD 00 00 00 00 00 00 00

Here is the same section from MOD 21:

Code:

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B

00000000  4F 46 DA C7 3E E9 CD 0E 38 EF EB FB
0000000C  6E 3B 6C 55 55 A7 53 19 19 FF F9 F2
00000018  FC FC FE 01 01 03 00 BE 4F EB FB FB
00000024  FD FD F7 C8 C8 00 00 00 00 2F FE FB
00000030  CF EF FB C8 01 00 00 00 00 CF DF FC
0000003C  F7 FF FE 64 01 00 00 00 00 B9 F3 FF
00000048  ED 7E CA 64 3F 32 02 1E 25 7F FE DF
00000054  7F FB F7 63 63 B0 B4 08 B3 F7 DB 87
00000060  EF E5 CF 64 01 C3 00 00 00 5D DF DD
0000006C  FD 27 FF 85 04 0A 00 00 00 DB FE F5
00000078  E8 77 FF B0 3F 18 00 00 00 F7 F7 EF
00000084  F5 FF F7 C8 C8 00 00 00 00 FC F3 FD
00000090  AF EF EE FE BB 6F BF BF BF FF DF BF
0000009C  E7 FF E0 F7 4F EC FC FF AF 5F FB EC
000000A8  EB FC CE F5 EF BD FB FB FF FF B7 5E

Column 00 contains the attribute IDs (see your CrystalDiskInfo screenshot). Clearly the SMART modules are badly corrupted. I don't know how this will impact on your drive's behaviour, but we should be able to clean these modules up as well. That said, I don't know why they became corrupted. Perhaps there are other problems.

[Taserx]

Alternatively, download MHDD ver 4.5 and copy the "rdmod32" file to the SCRIPTS subdirectory and the rm32.bin file to the MHDD directory.

http://hddguru.com/software/2005.10.02-MHDD/

Then type ...

.rdmod32

... to execute the script.

This should read module 32 one sector at a time. Each sector should be written to a separate file -- 321.bin, 322.bin, 323.bin, ... 327.bin.

I tried many times in WDMarvel but kept getting the DISK_DAM_ERROR or DISK_ECU_UNSAFE_ERROR and wouldn't read.

So I tried in MHDD with the scripts you provided, but it gave an error too, see the screenshot below.

Does regenerating Mod 32 based on the resources for this exact drive, but without the first sector from the actual module, still jeopardize the data?

Attachments

[fzabkar]

Let me experiment with my BB drive, then I'll get back to you.

[fzabkar]

The rdmod32 script is OK with my WD2500BB drive (see attachment).

To answer your question, if we rewrite module 32 with a copy from another resource, then we need to be certain that it is compatible with the other firmware modules. I wouldn't want to risk such an approach until we have exhausted all other options.

My next approach would be to try reading the track, or partial track, on which this module resides. If you can give me some time to experiment with my drive, I'll try to come up with a suitable script.

Attachments

mod32_sectors0-7.rar

(551 Bytes) Downloaded 376 times

[Taserx]

Ok thanks, your help is greatly appreciated!

[fzabkar]

The following script works on my BB drive. There are four BIN files (rd32h?s?.bin) which need to be copied to the MHDD directory. The script file (RD32SEC2) needs to be copied to the SCRIPTS directory.

Code:

; reads first 2 sectors of module 32 on heads 0 and 1

reset
waitnbsy
regs = $45 $0b $00 $44 $57 $a0 $80
waitnbsy


regs = $d6 $01 $be $4f $c2 $a0 $b0
waitnbsy
checkdrq
sectorsfrom = rd32h0s1.bin

regs = $d5 $2D $bf $4f $c2 $a0 $b0
waitnbsy
checkdrq
sectorsto = mod3201.bin


regs = $d6 $01 $be $4f $c2 $a0 $b0
waitnbsy
checkdrq
sectorsfrom = rd32h1s1.bin

regs = $d5 $2D $bf $4f $c2 $a0 $b0
waitnbsy
checkdrq
sectorsto = mod3211.bin


regs = $d6 $01 $be $4f $c2 $a0 $b0
waitnbsy
checkdrq
sectorsfrom = rd32h0s2.bin

regs = $d5 $2D $bf $4f $c2 $a0 $b0
waitnbsy
checkdrq
sectorsto = mod3202.bin


regs = $d6 $01 $be $4f $c2 $a0 $b0
waitnbsy
checkdrq
sectorsfrom = rd32h1s2.bin

regs = $d5 $2D $bf $4f $c2 $a0 $b0
waitnbsy
checkdrq
sectorsto = mod3212.bin

; end

; rd32h0s1.bin -- 0C 00 01 00 FE FF FF FF 00 00 F6 01 01 00 00 00
; rd32h0s2.bin -- 0C 00 01 00 FE FF FF FF 00 00 F7 01 01 00 00 00
; rd32h1s1.bin -- 0C 00 01 00 FE FF FF FF 01 00 F6 01 01 00 00 00
; rd32h1s2.bin -- 0C 00 01 00 FE FF FF FF 01 00 F7 01 01 00 00 00

Attachments

rd32sec2.rar

(530 Bytes) Downloaded 355 times

[Taserx]

The following script works on my BB drive. There are four BIN files (rd32h?s?.bin) which need to be copied to the MHDD directory. The script file (RD32SEC2) needs to be copied to the SCRIPTS directory.

And then I just type .RE32SEC2 to execute the script? Ok I'll give that a shot, many thanks.