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.

_________________
A backup a day keeps DR away.

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.

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.

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.

_________________
A backup a day keeps DR away.

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?

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

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

_________________
A backup a day keeps DR away.

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.

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

_________________
A backup a day keeps DR away.

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

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.

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?

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?

_________________
A backup a day keeps DR away.

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

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.

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

_________________
A backup a day keeps DR away.

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

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.

_________________
A backup a day keeps DR away.

This is the only other difference:

_________________
A backup a day keeps DR away.

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).

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.

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

_________________
A backup a day keeps DR away.

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

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).

Sounds quite plausible, as far as I can understand!