HDT721010SLA360 - where a problem might be

[John1]

Thank you for your replies.
If I use another (working) PCB, which IC must be replaced from the old PCB?

[fzabkar]

You must replace 93C86. This IC stores drive specific info. The other IC may also need to be changed if the donor's firmware version is not matched.

[John1]

@fzabkar:
I finally was able to read M25P10VP. Can you please check the content if it is OK?


Thank you

U7_M25P10VP_firmware_hex.zip

(57.25 KiB) Downloaded 615 times

I am going to dump 93C86WP after I modify my programmer

[fzabkar]

The only way I know to check your ROM code is to compare it against a dump from a drive with the same firmware version:

https://firmware.hddsurgery.com/index.php

Unfortunately, I don't have access to the above database. If you can tell us your firmware version, perhaps someone will have a copy they could upload.

[John1]

Can you tell me where I can find out the firmware version of my drive?
From drive's label?
Thank you

[fzabkar]

I was hoping I could see the firmware version in the ROM, but I couldn't find anything. Can you tell us the S/N and MLC numbers on the label?

[John1]

S/N:MH1DNVSW
MLC:BA3013

Thanks again for help

[michael chiklis]

I've found 6 fw versions for HDT721010SLA360

The first three are the only that have s/n which starts with MH1 chars

Code:

ST6OA31B

https://www.mediafire.com/file/tg1mwyjbwaptq07/

Code:

ST6OA3AA

https://www.mediafire.com/file/0kcwuk20u9ehb2l/

Code:

ST6OA3CH

https://www.mediafire.com/file/bpen0ymtjr9vn91/

-----------------------------------------------------
Drive with the following fw version has s/n which starts with MH0 chars

Code:

ST6OA10Q

https://www.mediafire.com/file/g86jqdf387n3j0m/

-----------------------------------------------------
Drives with the following fw version have s/n which starts with MS2 chars

Code:

ST6OA39P

https://www.mediafire.com/file/q58y32m2z5b1cvm/

Code:

ST6OA32E

https://www.mediafire.com/file/rdodqoofxjizzls/

As your drive s/n starts with MH1 chars, i would start trying to compare rom against this first three.

[michael chiklis]

I just compared your rom with all 6 i've uploaded, it perfectly matches with all exept with version ST6OA10Q.
So i would say that your rom is good, at least until offset 0x18000h. Your rom after this offset is FF padded until end to fill the 128K rom (20000h size).
Shouldn't be there NVRAM data there?

[John1]

@michael chiklis:
Thank you for your comparing.
Does it mean that the content of M25P10VP is good and the IC should work properly?

And the same must be done (comparing) with 93C86WP chip?

And does it also mean that in case either 93C86WP or M25P10VP was faulty, I can use a brand new chip and flash firmware( like that you compared) and the drive will work? Or is there any item/part of drive that is unique and can not be replaced at all?

[michael chiklis]

So you've two SPI rom chips on your pcb?
Well, that means nvram is separated from rom, nvram code should be on 16Kbit chip (2 KB), which is the 93C86WP.

In my opinion, the content of rom chip (M25P10VP) is ok.
I would check NVRAM in 93C86WP, Frank probably will be able to help you with that.

93C86WP content is unique.
M25P10VP swap would not help you, that's not the problem.

[John1]

I finally dumped 93C86. Can anyone please check/compare if the content is correct?
I read it as 2048 x 8 bit organization. Or is it 1024 x 16-bit organization?
Thank you

U5_93C86_hex.zip

(1.21 KiB) Downloaded 424 times

[michael chiklis]

Or is it 1024 x 16-bit organization?

Yes, i believe it should be read as 1024x16bit, because i see in hex editor that your nvram dump has flipped byte order.
As you can see at the end of the BIN file, the serial number has flipped chars.

Read it as 1024x16bit or just reverse bytes by 2 in WinHex... well i already did it for you.

This is the nvram file as should be

U5_93C86_hex reversed bytes as 1024x16bit reading.rar

(1.24 KiB) Downloaded 613 times

I compared your "fixed" nvram file with the one inside the fw resourse i've posted yesterday from fw version ST6OA31B... they're very similar so i think that the structure of your nvram is ok... but someone who has better experience than me maybe could see something wrong... i don't know.
Of course they can't be identical, nvram has unique data... i can show you the differences

the picture is not complete, but you can check in log the offset where bytes are different (called as "replaced"), but that is normal because portions of nvram are unique

Content comparing.txt

(2.62 KiB) Downloaded 600 times

[michael chiklis]

WAIT !

I see at the end of your nvram those 2 "FF" bytes, on nvram from fw resource i posted yesterday those are "00"
I think those two FF should be 00, but i don't know if that can affect on hard drive power up, it's better to ask an opinion to Frank or Pepe about it.

[John1]

Thanks a lot for comparing.

So, do you think 93C86 content is correct? Or how to check so that I can be sure of that?
Should I replace those FF with 00 and test?

Voltages are correct, U5 (93C86WP) and U7 (M25P10VP) seems to be OK, yet hard drive not working(no voltages on
flex cable coming to motor, no sound).
Is there still another way how to check the reason (why hard drive is not working)?

P.S.
I read 93C86 again now in 16bit organization

U5_93C86_16bit_organization_hex.zip

(1.24 KiB) Downloaded 446 times

.

[michael chiklis]

Yes, now that you've read 93C86 chip as 16 bit organized, the dump has all bytes in proper order. In fact now it perfectly matches with the file that i've corrected before for you by modifying the byte order in WinHex.

Now you could try to replace those 2xFF bytes with 00 in your last nvram dump... or just directly download the file on bottom (i filled those 2 FF with 00 for you).

U5_93C86_16bit_organization_hex FF to 00 at end.rar

(1.23 KiB) Downloaded 525 times

then write it on 93C86 as 16 bit organization and try if your drives finally starts.
If it doesn't, wait for someone else opinion.

[fzabkar]

This appears to be the firmware version:

Code:

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

000003F0  53 54 36 4F 41 33 31 42                          ST6OA31B

I don't completely understand the checksum algorithms, but in this particular model there is a 16-bit XOR checksum at offset 0x7D4. The previous 4 bytes appear to be ECC bytes or CRC bytes, but I haven't been able to identify the algorithm. If I truncate the file at offset 0x7D6, the XOR checksum calculated over the truncated file is 0x0000. In short, the NVRAM looks OK. I don't know about the bytes after 0x7D6, though.

Code:

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

000007C0  00 00 00 00 00 00 00 00 48 4D 44 31 56 4E 57 53  ........HMD1VNWS
000007D0  B1 50 6B 84 16 5B 00 00 00 03 00 00 00 00 00 00
          ^^^^^^^^^^^ =====
          ECC / CRC?  XOR checksum

000007E0  FF 00 00 00 00 00 00 00 00 00 00 1C FF 00 00 00
000007F0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

[fzabkar]

I see at the end of your nvram those 2 "FF" bytes, on nvram from fw resource i posted yesterday those are "00"
I think those two FF should be 00, but i don't know if that can affect on hard drive power up, it's better to ask an opinion to Frank or Pepe about it.

Could these bytes be related to PUIS (Power Up In Standby)? That said, my understanding is that a PUIS-enabled drive should still be detected, albeit without a full ID.

[John1]

Thank you for your reply.
So, firmware of U5 and U7 seems to be good , voltages also, yet the drive does not work.
Is there still any other procedure that I can try so that I will be able to repair the drive?

[michael chiklis]

Thank you for your reply.
So, firmware of U5 and U7 seems to be good , voltages also, yet the drive does not work.
Is there still any other procedure that I can try so that I will be able to repair the drive?

Have you tried to write on 93C86 (U5) the last nvram i've uploaded?

U5_93C86_16bit_organization_hex FF to 00 at end.rar

i've replaced those 2 FF bytes with 00