I made the same test in BAD PCB and got some terminal results:

Bridge PLL Enable Failed
Bridge PLL Enable Failed
Bridge PLL Enable Failed
Bridge PLL Enable Failed
ERROR: Flash Led 9C08 - ALF Hardware Initialization Process Failed
Flash HW Init Attempts = 0004

Clump Parametrics:
Clump = 410A
DataType = 0020
ModeFlag = 03
EraseCount = A0100BEE
EraseFailCount = 00
ProgramFailCount = 07
WeakReadCount = 13
UncorrectableECCError = 05

---SOC PSM Command History---
Cmd#/PsmCmd Clump Offset Length LbaMid LbaLow LbaBits39To32 Options Status DestClump DestOffset
000E 410A 3165 E5B6 5C4D 6616 018A DB7F 0080 C207 ED63

11B0 9788 585F BFDE 7FBA 3218 687A 02BE 1828 6CC3 C270

03FB C496 754A 5444 EFE9 C3EC 3D61 2D77 C0E6 674F D480

010E 410A 3165 E5B6 5C4D 6616 018A DB7F 97B0 C207 ED63

A376 4CF1 FD87 774B 9387 D620 FED7 1C6A E3DA ECFE 1268

Flash Statistics: Could not be printed

ALFRecorder:
End of ALF Recorder Trace

Terminal hangs too.

As expected; NAND is bad.

_________________
http://www.northwind.gr
SandForce SSD Recovery
Ransomware Reverse Engineering - NoMoreRansom! partners

Yep, a lot of paper weight, unfortunately.

Many thanks for all.

On bad PCB:
"F3 O>I" ?

i guess he cannot get the fw loaded at all. So no chance to get prompt...

i feel sorry for those drives, i hate when something becomes rubbish because of such errors.
If i had time i would be glad to give them a second life...
pepe

_________________
Adatmentés - Data recovery

I tried to do that, but not accept input on terminal console.

lastmile,
Find the owner of PС3K and ask to patch one disk for you.

@lastmile, thanks for indulging my curiosity. I wonder if we could try another test. Could you show us the underside of the PCB?

I wish to explore the "Bridge PLL Enable Failed" message. IIUC, the "bridge" is the Seagate ASIC which controls the NAND flash. If so, then the PLL (phase locked loop) would be involved in synchronising the clocks for the communication channel between the MCU and the ASIC. This would in turn suggest that the ASIC has been disabled, which would then imply that it is powered from the same 3.3V supply as the NAND. If so, then I would try to disable the NAND in some other way that doesn't affect the ASIC.

Your tests prove that the MCU is switching off the Vcore2 and Vneg supplies. Thanks for clearing that up.

The other interesting thing is the "Clump Parametrics" and "SOC PSM Command History". Your tests confirm that the NAND is not the storage location for these data. Instead I suspect that the SPI flash ("ROM") keeps a record of this info.

_________________
A backup a day keeps DR away.

command history comes from ram.

_________________
Adatmentés - Data recovery

@lastmile, there is a 6-pin IC near pin #1 of the ASIC. Can you tell us its markings? Can you measure the voltages on the heavy traces?

There is another tiny IC at the left side of the ASIC? Can you identify its markings?

_________________
A backup a day keeps DR away.

FWIW, I found these differences in the "SOC PSM Command History":


It could be a red herring, or it may point to bit errors in the TTL adapter (or RAM?).

_________________
A backup a day keeps DR away.

@fzabkar, Of course, picture attached. I hope you find some other whay to disable NAND and give back life to HD....

The underside of the PCB is unhelpful.

Can you measure the voltages on the bypass capacitors surrounding the ASIC (I can see 7)? This should tell us the supply requirements.

What I'm hoping to do is to find some way to defeat the NAND during the POST and leave us with access to terminal. It may not be possible, but we won't know if we don't try.

_________________
A backup a day keeps DR away.

@fzabkar, Images attached.

Many thanks.

It appears that the NAND is the sole user of the 3.3V supply.

The ASIC's Vio rail appears to be powered from the MCU's 1.8V Vio supply via a load switch (AQI marking, SOT23-6 package). I haven't yet been able to locate the datasheet for this IC, but I'm fairly confident that it is actually a load switch, in which case its enable pin would be controlled by the MCU. I believe that the two unpopulated pads between pins 3 and 4 are reserved for a shorting link which would be used when the load switch is unpopulated. In the unlikely event that the load switch is damaged, one could bypass it with such a link.

The 4-pin BGA IC appears to be a 1.2V LDO regulator which derives the ASIC's 1.2V Vcore supply from the main 1.8V rail. I haven't yet found a datasheet, but I suspect that this IC is similar to the NCP110 (similar specs, different pinout):

https://www.verical.com/datasheet/on-semiconductor-linear-regulator-ncp110amx180tbg-5698767.pdf

I'm betting that the round pad (pin #4) is an enable pin, also controlled by the MCU. I would be tempted to short this pin to ground during power-on. Try the bad PCB first. I would first confirm that the Enable pin is not hardwired to the 1.8V rail (extremely unlikely).

_________________
A backup a day keeps DR away.

Try reading the ROM (sys file 32a) on a good PCB:

http://www.hddoracle.com/viewtopic.php?f=83&t=1455

If it turns out that you need a professional tool to patch your ROM, then you can buy MRT Express in instalments ("online repair version"). Hopefully you will only need the first instalment, in which case your cost might be around US$300. That's $3 per drive. (You would need to verify whether MRT supports your model)

I would also investigate whether SeDiv supports your model, in which case you can buy the full version for around US$350.

_________________
A backup a day keeps DR away.

@fzabkar, I tried the procedure above, but nothing on terminal console.

@fzabkar, Thank you so much! I´ll try tomorrow at night and I´ll check MRT Express and SeDiv.

Any news, post here in the forum over the weekend.

I wonder if one could recover the data from this model by using a donor drive as follows:

Secure erase the donor drive. This will hopefully purge the donor's cached data from the NAND. Dump the ROM before and after the secure erase. Check to see whether any part of the ROM has changed.

Transfer the patient's ROM adaptives and code segments to the donor. If the previous before-and-after comparison has uncovered an area of the ROM that is related to the NAND, then don't touch this area.

Install the donor PCB on the patient HDA and hope for the best.

_________________
A backup a day keeps DR away.

i am 99.99% sure it does not touch the rom.
pepe

_________________
Adatmentés - Data recovery