Hi, I'd be grateful for any suggestions before I bin this ST31500341AS & restore from backup.

It spins up, clicks 11 times, then spins down.

There's nothing on serial debug other than a single "ü" (0xFC / 0b11111100) immediately following power-on. No response to Ctrl-z, no echo-back. I've verified my serial setup is good with a working 7200.11 drive (750gb ST3750330AS). Same outcome with motor, heads, or both disconnected.

Drive reports as a 4gb ST_M13FQBL which I think is the default baked into the firmware. I'll try to add a reply for a jpg of the MHDD output, the forum isn't accepting it here for some reason.

Other threads similar to this suggest head failure is most likely. However many of them mention getting useful info from serial, & with mine dead I wonder if maybe it's a logic board issue and maybe even fixable if it's just a generic SMT component. Is there anything I can check in this regard? I have a scope available if need be.

Filesystem is ZFS and I don't recall ever seeing any SMART/checksum issues reported on it before failure.

I have a backup but it's a few months old due to it containing a VM, I'm not sure on the merit of an automated one that runs at the volume level on a running VM. I've already restored from backup to a new drive but I'd like to see if I can get the ZFS deltas synced before spinning up the VM. It's not critical though as it's an AD/Exchange server for personal use (auth & calendar sync), and apparently clients should re-sync newer items back to it. I can export the client PST first in case this fails.

Any thoughts would be appreciated.

Attaching MHDD output.

most likely heads (and maybe surfaces) are bad. Drive cannot load controller fw.

_________________
Adatmentés - Data recovery

This is about checking the board.
You can supply power to the HDD with the "U" key pressed in the terminal.
Or
You can carefully unsolder the flash chip if you have a lot of soldering experience (otherwise you will damage the unique content!).
This should cause a bootcode from the processor - checking your serial connection.

Or measure the presence of +5V -5V on the contacts in the hermetic block (If fzabkar helps. ).
But -5V can be disconnected along with the stop of rotation.

Thanks for the replies!


I'm leaning towards a board fault because I also get a single "ü" on serial with the board removed entirely from the drive, which ought to eliminate both head & surface issues.

The working drive I have still produces a Rst message when the board is removed from the drive.


No change I'm afraid, tried upper & lower case, holding down during power on and also trying to press same time & immediately after.


My soldering skills are not up to the task for that and the guy I know capable of it is out of the country.

Is the purpose of this to verify the serial debug? I feel that this part is fine given that both Tx and Rx work fine on the working drive. Are the serial pinouts & voltages consistent on the entire 7200.11 series?

Is the "ü" itself perhaps some kind of bootcode or panic message, akin to a POST? I tried searching for that and it's hex/binary equivalents but found nothing. It does feel very odd how it immediately outputs this every single time and that it's such a short single-byte payload. A digital form of "nope".


Probing sounds like the only option left but unfortunately try as I might I couldn't find any useful pin-outs for reference.

What does seem odd is the serial debug failing while SATA is still able to communicate with the MB. Seems kinda backwards. If it weren't for that I'd suspect that either the flash or microcontroller were broken (i.e a completely dead board), but with SATA at least sending Manufacturer Info etc there's some brains on the device still working & responding to SATA requests.

The only thing that I can think of is maybe that the "4gb ST_M13FQBL" default part of the firmware is baked into a ROM or the controller itself, and the serial debug part is provided by code on the flash that is initialized just after that point. If that were the case then a corrupt or broken flash would break serial while still responding to SATA (albeit incorrectly). I may try flashing it tomorrow just out of desperation, provided it'll let me given that it's identifying incorrectly.

Don't even think about flashing someone else's ROM. Each HDD has its own unique ROM.
Seagate serial terminal levels can be 3.3V, 2.5V, 1.8V. This may be your problem.
I don't have that particular HDD to check.

if it spinning and clicking, board is 99.9% not the problem.
this is a 2.5V board, a 3.3V adapter likely works with it, ie you should see terminal output, but be aware that some fw versions are pretty much silent, saying nothing.
If i had to think about some problem on the pcb, my bet was the -5V supply rail, but that would not affect the serial output in any way.
Such symptoms indicate head problems in the vast majority of the cases.

pepe

_________________
Adatmentés - Data recovery

Great, thanks for the suggestions!

I was thinking about trying to flash over SATA using the regular official flash util, not a low level copy of the chip itself. But yeah, I'll not bother with that.

I checked the terminal levels using a scope & that may well be the issue. Here's the output a ctrl-z on the good drive whose terminal access works:



The drive's Rx (Channel A) looks fine, I thought the idle level of "1" seemed odd but apparently that's correct for UART serial.

The Tx channel though is ... odd. It's a fraction of the Rx one, even though my scope and interface were able to make sense of it.

It looks the same on the bad drive except that the Tx doesn't change following the ctrl-z.

The interface (MAX232 based) is on a protoboard so I'll re-do it based on one of the diagrams linked elsewhere on the forum. Or perhaps I'll just buy a new simpler one...is there a go-to USB one that is well regarded?


(The "ü" I was seeing on power-on is probably just noise as it's seen simultaneously on the input as well, 0xFC just so happens to be 0b11111100, so not difficult to fluke that with a two-tick drop to 0v)


Thanks for the help!