Dead Hitachi HUA723020ALA641 2TB 3.5" 7200rpm (Jun-2012) HDD

[fzabkar]

Start by measuring the resistances at the motor rather than the PCB, with the PCB off the drive. Then measure the same resistances at the PCB terminals, with the PCB off the drive.

Sometimes a good PCB will measure shorted. This is because a capacitor is holding charge, even in the powered-off state, and this charge is turning on the MOSFETs. You can use tweezers to discharge the capacitors around the motor controller before confirming your measurements.

Your preamp isn't shorted. That's all I can say about it.

My theory is that the motor seized up, and one or more of the motor controller's MOSFET phase drivers was shorted. This then took out the MOSFET power switch (122A) on the bridge PCB.

[nc513]

Oh, ok, putting the PCB aside did indeed make a difference.

* Bad HDD without PCB:

Pin 1 to pin 2: 0.9 Ohm
Pin 1 to pin 3: 1.0 Ohm
Pin 1 to pin 4: 1.0 Ohm

Pin 2 to pin 3: 2.3 Ohm
Pin 2 to pin 4: 2.2 Ohm

Pin 3 to pin 4: 2.3 Ohm

So that's pretty much identical to how a known good HDD measured (without the PCB installed).

All measurements so far (also in the post from 1.5h ago) were taken at the 4 solder blobs on the HDD, right where the motor supposedly is located.

Then measure the same resistances at the PCB terminals, with the PCB off the drive.

PCB terminals on the PCB or on the HDD's flex cable, where it usually connects to the PCB?

This drive has been running pretty much constantly since Aug-2017, but has never been abused in any way. I suppose 6 years is quite a long time, though.

[fzabkar]

I still feel that the spindle motor has a problem, perhaps a seized bearing. In any case, I think the drive needs to be examined in a cleanroom.

[nc513]

Yes, I'm starting to think that there's not much more I can do myself now. I did try to power up the drive once more and got exactly the same result as in my YouTube video: 6 x BZZZZ and then a faint bump+knock sound, only once. Then nothing more.

How certain is it that the ROM is ok, though?

Btw, the technical docs for this HDD say that it uses "industry standard TCG Enterprise_A encryption". Could this make a recovery even more challenging in some way?

[fzabkar]

If the ROM were bad, there would be no activity.

I don't think encryption has any bearing on this case.

[nc513]

Any idea what the faint bump+click sound is? Does it maybe park the heads after six failed spin-up attempts?

I stole the PCB off a perfectly good drive, so what I suppose I could still do (to e.g. verify that encryption should not be a problem moving forward) is to try to get that drive up and running again. This would require buying a donor PCB and doing another ROM transfer. Then I'd just check if the drive works normally through a SATA-USB bridge as well as connected directly to a PC motherboard.

[fzabkar]

It sounds like the headstack is "chattering" on the ramp (does this model have a ramp?). I don't see any DIY solution.

[nc513]

Yes, 5 thin platters and it does have a ramp. Well, that is assuming they put the correct picture in the technical docs;

hitachi_inside.jpg (37.55 KiB) Viewed 24139 times

Also: "The upper and lower magnet of these drives are connected and can't be disassembled by classical methods. This means that heads must be disassembled together with the magnets. This support tool secures position of heads in relation to both magnets during heads replacement process".

I won't be opening the drive myself.

[nc513]

Wonder if it'd be possible to dump the ROM while it's soldered to the board. Pins 2 (serial data out) and 5 (serial data in) are connected to each other on the PCB. Does this make sense?

[fzabkar]

I guess that would be OK if the MCU were using the one GPIO pin in bidirectional mode, but it's not something that I would expect. Is there actually a direct physical link between the two pins?

[nc513]

Yep, there's a direct trace between the two pins, right under the chip;

[nc513]

Well, I've now dumped the ROMs (out of circuit) of my two Hitachi drives; both the bad and the good one. Would anybody be able to tell if they look like proper drive firmware and if the way in which they differ seems logical? Zip-file with .bin images attached.

Attachments

ROM_dumps_nc513.zip

(230.15 KiB) Downloaded 472 times

[fzabkar]

The structure looks OK to me. They differ in the NVRAM data, but that's because this data is unique to every drive.

[nc513]

Ok, that's good. What about these differences; anything to worry about?

[fzabkar]

I would think that protection bits would only be of concern during a firmware update or a write to NVRAM. One instance of an NVRAM write that would occur during normal operation would be if the user were to enable Power Up In Standby (PUIS). In such a case the PUIS flag would be written to NVRAM. I can't think of any others.

I think you are wasting your time looking for a problem in the ROM.

Just FYI, I have attached the differences. All except 4000-6FFF.bin have an XOR sum of 0x0000.

Attachments

differences.7z

(3.72 KiB) Downloaded 657 times

[fzabkar]

This is the only other difference:

Code:

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

0007F000  50 4E 5F 4C 4F 47 45 58 30 4A 31 34 30 37 38 42  PN_LOGEX0J14078B
0007F010  41 34 34 34 33 5F 50 4D 5A 32 30 35 54 54 50 30  A4443_PMZ205TTP0
0007F020  50 4E 5F 4C 4F 47 41 43 20 20 20 20 20 20 20 20  PN_LOGAC       
0007F030  20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20       

Code:

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

0007F000  50 4E 5F 4C 4F 47 45 58 30 4A 31 34 30 37 38 42  PN_LOGEX0J14078B
0007F010  41 34 34 34 33 41 50 37 53 32 32 31 30 47 52 44  A4443AP7S2210GRD
0007F020  50 4E 5F 4C 4F 47 41 43 20 20 20 20 20 20 20 20  PN_LOGAC       
0007F030  20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20

[nc513]

I think you are wasting your time looking for a problem in the ROM.

Yep. At this point I'm basically just collecting information. For whatever reason, I don't know.

I've pretty much already decided to send the drive to a lab. Or if that route turns out to be extremely expensive, I guess I'll just have to accept the loss (which isn't really a huge one).

All except 4000-6FFF.bin have an XOR sum of 0x0000.

Does that indicate that they put an XOR sum check byte at the end of some of the "subchunks" the .bin image consists of?

At this point, many thanks for your assistance and for your patience with also my "stupider" questions.

[fzabkar]

First, let me say that I'm not a data recovery professional, I'm just an observer. My knowledge is limited to what I have been able to see through a foggy window, plus my own analyses of firmware modules, etc.

I believe that these chunks (aka "NVRAM") have a 16-bit word at the end which is calculated so that the XOR sum of the chunk is 0x0000. Preceding this XOR word is a 32-bit word whose function I don't know. I suspect it could be an additional CRC, or it could be ECC. One way to find out would be to enable Power Up In Standby (PUIS) and observe how these chunks are affected.

This is my checksum calculator:

https://web.archive.org/web/20230522150553/http://www.users.on.net/~fzabkar/FreeBasic_W32/Utils/checksum.exe
https://web.archive.org/web/20230522150553/http://www.users.on.net/~fzabkar/FreeBasic_W32/Utils/checksum.bas

[nc513]

First, let me say that I'm not a data recovery professional, I'm just an observer. My knowledge is limited to what I have been able to see through a foggy window, plus my own analyses of firmware modules, etc.

In any case, you're quite a valuable resource around here!

I believe that these chunks (aka "NVRAM") have a 16-bit word at the end which is calculated so that the XOR sum of the chunk is 0x0000.

Ah, yep, that's basically what I was trying to say, but I guess my brain was stuck in Commodore 64 8-bit mode (many C64 tape loaders use XOR based check bytes).

[nc513]

My theory is that the motor seized up, and one or more of the motor controller's MOSFET phase drivers was shorted. This then took out the MOSFET power switch (122A) on the bridge PCB.

Sounds quite plausible, as far as I can understand!