I have run across a number of these drives with the same behavior. When connected to the SATA controller they constantly spin up then spin down.

When I connect the drive to SeDiv through the serial connection I see the message

LED:000000EE FAddr:006F5AC8
Rst 0x08M
(P) SATA Reset Encrypting
SeaCOS 3.6 Build 0

RW cmd 0002 req = 36 69 00 00 01 00 00 00 00 00 00 00 80 BD 04 00 FF BD 04 00 80 BD 04 00

opts = 00001121
RW Err = 43110081

RW cmd 0002 req = 36 69 00 00 01 00 00 00 00 00 00 00 80 BD 04 00 FF BD 04 00 80 BD 04 00

opts = 00001121
RW Err = 43110081

RW cmd 0002 req = 22 8A 02 00 01 00 00 00 00 00 00 00 80 BD 04 00 FF BD 04 00 80 BD 04 00

opts = 00001121
RW Err = C3160084

RW cmd 0002 req = 22 8A 02 00 01 00 00 00 00 00 00 00 80 BD 04 00 FF BD 04 00 80 BD 04 00

opts = 00001121
RW Err = 43110081 SeaCOS Hidden Sector unreadable!
WriteVcardImage(0, 0) failed writing card 000

This loop runs endlessly and I don't know how to break the condition.

Is there any hope for these drives? Any help appreciated.

Are these drives from a big batch of pulled drives from some systems that you got possession of at once?

All drives have the exact terminal output?

_________________
Hard Disk Drive (HDD), Solid State Drive (SSD, SATA, NVMe, etc), USB Flash Drive and RAID Data Recovery Specialist in Massachusetts

Origin of drives unknown. Number of drives unknown. I was given a small sample of 5 drives to help assess the problem. One of the drives does not exhibit the spin problem. This drive is recognized by BIOS, but the BIOS reports 0mb capacity. The other 4 drives have the endless loop problem.

My guess is that they might have been installed in HP enterprise MFP printers at one time. I am looking for a method to secure erase the drives.

Do you recognize the symptoms?

Seems like mechanical and firmware issues.

_________________
Hard Disk Drive (HDD), Solid State Drive (SSD, SATA, NVMe, etc), USB Flash Drive and RAID Data Recovery Specialist in Massachusetts

Yes I am quite perplexed at the moment. Hopefully I will have a known good drive in a few days to make a comparison. Just wish I had a method to stop the firmware looping condition.

As anyone can guess I am a novice in this field, but I am attempting to learn as much as possible.

Thanks for your reply.

To me are FUBAR due to End-of-life or mechanical/media/MHA issue, but only after proper diag I can tell. As an alternative, they are actually pulls and maybe degaussed.

I am sure they are pulls, and if they have been degaussed, that would explain the behavior.

I wonder if there is any "simple" way to prove a drive has been degaussed. Would the degaussing process leave any evidence on any component other than the platters?

Just curious.

Use a DDA and see if servo / framing is OK. Simple as A-B-C.

It will point out (also) if heads are OK / degraded. I do this kind of check on batches or if I have the feeling something is not going well "inside there".

Oh yes, the problem is to have the DDA at hand ...

Thanks for the reply.

"Oh yes, the problem is to have the DDA at hand ..."

And the skill to use one.

"Simple" is the operative word. And dirt cheap in my situation.

Please indulge me with your patience. I am sure I will make some stupid assumptions but I am teachable.

I was wondering if this might be possible

1. Remove the PCB from a test drive.

2. Spin the platters at a constant rate. (Any rate - just needs to be constant. I am assuming this can be done, but not sure how).

3. Bias the read heads on. (Any head or all heads. Again I am assuming this can be done, but not sure how).

4. Monitor any or all read heads with an Oscilloscope for any repetitive response (servo track) as you scan the heads (how I don't know) across the platter.

I would expect a normal platter would have a repetitive response somewhere that you could not miss if your rotation rate was constant. I am simply imagining that a degaussed drive would not retain the servo track and you would only observe random or possibly very similar constant data.

Of course, I could be completely wrong and misguided.

Anyone ever tried this before or have any suggestions (other than quit wasting our time) ?

If servo is lost, there's little to do except re-stw the drive (for re-use, no data ! - and where it is possible) and refurbish the drive. If you want to do some 'coroner work' on these drives and have no DDA do some experiments with GHz range scope and differential probe. Good luck.

I am having difficulty identifying the signals on the 18 pin interface between the logic board and the MHA. Is this info readily available on the net. I assume there is a standard convention in drive families.

If it was readily available on the internet you wouldn't have asked...