HD204UI not spinning

[James]

I've been away from DR for a little while but working my way back :). Hope you are all doing ok :)

I have a HD204UI which fails to spin

PCB BF41-00314A

Tried a donor PCB with ROM adapt but still no spin

Has anyone known some of these Samsung PCB's to be incompatible even when matching number, ROM adapt etc?

Terminal:

ActiveFW : 00

FWVer : 0001

SATA PLL cal done

DDR size detected = 16MB

*PA VID=0000 PN=0009 Rev=0001- 785x Found

*PA VID=0000 PN=0009 Rev=0001- 785x Found

U

S_0ENG>

 

Seems to me the preamp is ok?

James

[t...@desertdatarecovery.com]

This is the full terminal output of a healthy drive. Looks like yours is not loading the SA overlays.

 

ActiveFW : 00

FWVer : 0001

DDR size detected = 32MB

SATA PLL cal done

*PA VID=0000 PN=0009 Rev=0001- 785x Found

*PA VID=0000 PN=0009 Rev=0001- 785x Found

U

S_0

RV Sensor Circuit Enabled

Shock Sensor Circuit Enabled

SO_1

SpinStartUp: mcSpinRPM = 0

RPM at Handoff: 490

Temp : 19 degC

SpinOk

mS1 00000003

SK C:122723 H:0

Loaded FIT ( 0: 0: 1)

CalibTable Loaded. Rev:0x1B

Selective MARC NX Loaded

ResoTable Loaded. Rev:0x01

RRO1xTable Loaded. Rev:0x01

Fw Active 0000

Ovly loaded to 0x00014D00

Ovly loaded to 0x1002E300

FdtTable Loaded. Rev:0x02

Reading Serial Num Pass

Up MC

 

PwrOn RRO1x @ H0

Table) cos = 512, sin = 1024

Coeff) cos = -3097, sin = -9889

 

 

PwrOn RRO1x @ H2

Table) cos = 768, sin = 512

Coeff) cos = 807, sin = -3993

 

 

PwrOn RRO1x @ H4

Table) cos = -256, sin = 0

Coeff) cos = 3877, sin = -2029

 

TgtCyl:    2032

Hd:   0 Zn:   0 Avg.:-    153

TgtCyl:  264688

Hd:   0 Zn:   1 Avg.:      72

 

SVCAL(0080,0000)-->PASS

RecordValid Ok : 0C07E47D 0007E41D

ReadyTime = 10210284 us

ENG>

 

Tim Homer - Lead Engineer

Desert Data Recovery

t...@desertdatarecovery.com

www.desertdatarecovery.com

--
Data Recovery Certification Group / for issue with google group please email sc...@myharddrivedied.com
---
You received this message because you are subscribed to the Google Groups "DataRecoveryCertification" group.
To unsubscribe from this group and stop receiving emails from it, send an email to datarecoverycertif...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/datarecoverycertification/f0c2e5b7-311a-4c4c-8b5f-bfa5a6fe44ddn%40googlegroups.com.

[pbzcbf...@gmail.com]

Could this be a FIPS problem?

I have written a tool to parse the ROM. Could you upload it?

FWIW, this model has a PUIS bug. Could that be the problem?

[James]

I did read about the PUIS bug. Seems plausible. This drive was operating as normal until the computer never woke again one day. 

From what I read it appears an edit to the FIPS to switch the PUIS from on to off is needed?

I wish to dump the ROM so I can send to you but my tools are a bit limited ATM.  I can desolder and read via programmer but not keen to if I can avoid it :)

Is there a CMD to download the ROM via COM?

[James]

Thanks for the terminal output Tim.

The PUIS bug Franc mentioned is interesting. Will examine that further. 

Cheers

James  

[pbzcbf...@gmail.com]

I don't offer any support for it, but here is the source code for SHTR:

https://files.hddguru.com/download/Software/SHTR/

[t...@desertdatarecovery.com]

We do not see a lot of older Samsungs here, but the ones I have worked on that don’t spin have all been a heads/preamp issue (apart from the ones with known error codes). But you should definitely explorer the firmware options first.

 

Tim Homer - Lead Engineer

Desert Data Recovery

t...@desertdatarecovery.com

www.desertdatarecovery.com

 

From: datarecovery...@googlegroups.com <datarecovery...@googlegroups.com> On Behalf Of James

--

Data Recovery Certification Group / for issue with google group please email sc...@myharddrivedied.com
---
You received this message because you are subscribed to the Google Groups "DataRecoveryCertification" group.
To unsubscribe from this group and stop receiving emails from it, send an email to datarecoverycertif...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/datarecoverycertification/480fbd6a-8495-4655-993d-f66080610b92n%40googlegroups.com.

[James]

Franc I managed to dump the ROM. Could you parse if for me please?

[Tawfeek Mokhtar]

it happen in samsung when it's not the native PCB . this method  i use to determine  the proper donor fir head swap , to put the donor peb on patient HSA , if power up ok i swap heads 

[pbzcbf...@gmail.com]

The ROM looks OK to me.

The FIPS is located at 0x3000 and consists of 0x800 bytes.

Don't be concerned about the BADs. They are normal.

The overall checksum is 0x0000.

Verifying Samsung SpinPoint ROM:  rom_first_half.bin

Checksum of Boot Block header = 0x26  - OK
Checksum of Boot Block (Actual/Expected) = 0x077A / 0x077A  - OK

Searching for FIPS block (expected checksum = 0x0000) ...

Found FIPS text string at 0x003000
Checksum for 0x0400 byte FIPS block = 0x8C49  - BAD
Checksum for 0x0800 byte FIPS block = 0x0000  - OK
Checksum for 0x0C00 byte FIPS block = 0xFE00  - BAD
Checksum for 0x1000 byte FIPS block = 0xFC00  - BAD

Found FIPS text string at 0x014A26
Checksum for 0x0400 byte FIPS block = 0xB073  - BAD
Checksum for 0x0800 byte FIPS block = 0x7EF4  - BAD
Checksum for 0x0C00 byte FIPS block = 0x900D  - BAD
Checksum for 0x1000 byte FIPS block = 0x32B4  - BAD

Found FIPS text string at 0x018D74
Checksum for 0x0400 byte FIPS block = 0xD78F  - BAD
Checksum for 0x0800 byte FIPS block = 0x65F4  - BAD
Checksum for 0x0C00 byte FIPS block = 0xE01B  - BAD
Checksum for 0x1000 byte FIPS block = 0xFF4C  - BAD

Found FIPS text string at 0x0195F0
Checksum for 0x0400 byte FIPS block = 0xF184  - BAD
Checksum for 0x0800 byte FIPS block = 0x4137  - BAD
Checksum for 0x0C00 byte FIPS block = 0x60F9  - BAD
Checksum for 0x1000 byte FIPS block = 0x8900  - BAD

Possible 0x0800 byte FIPS block at address 0x003000

Searching for FLASHTBL ...

Found FLASHTBL text string at 0x004024
Parsing FLASHTBL at 0x004000 ...

ID Byt1 Byt3    Size   ROM address range   RAMaddrs  Cksm (Exp/Act)
-----------------------------------------------------------------
00  00   FF         0                             0            N/A
01  02   FF       320     4000 - 431F      FFF04000  0C 20   - BAD (Note 2)
02  08   FF       A58     4320 - 4D77      FFF04320  39 39   - OK
03  00   FF     13988     4D7C - 18703            0  FA FA   - OK
04  01   FF      32C4    18708 - 1B9CB        14D00  00 0C   - BAD (Note 1)
05  00   FF       EE0    1870C - 195EB      4000000  48 48   - OK
06  00   FF       23C    195F0 - 1982B      4005C00  06 06   - OK
07  04   FF     1584B    19830 - 2F07A     10000300  2F 2F   - OK
08  01   FF     1A6F0    2F07C - 4976B     1002E300  00 96   - BAD (Note 1)
09  00   FF        10    2F080 - 2F08F     18000000  00 00   - OK
0A  00   FF      38DC    2F094 - 3296F     1805E300  99 99   - OK
0B  00   FF      12FC    32974 - 33C6F     200164F0  A2 A2   - OK
0C  00   FF       1F0    33C74 - 33E63     FFFE1000  CF CF   - OK
0D  00   FF      1750     1800 - 2F4F      FFF01800  76 77   - BAD (Note 3)
0E  08   FF         0                      FFF04320            N/A
0F  20   FF         0                      FFF01800            N/A
10  00   FF         0                      FFFC0000            N/A
11  00   FF         0                      200164F0            N/A


Searching for SERVOTBL ...

Found SERVOTBL text string at 0x037024
Parsing SERVOTBL at 0x037000 ...

ID Byt1 Byt3    Size   ROM address range   RAMaddrs  Cksm (Exp/Act)
-----------------------------------------------------------------
00  02   FF       100    37000 - 370FF     FFF37000  EB EE   - BAD (Note 2)
01  00   FF      979C    37104 - 4089F            0  09 09   - OK
02  00   FF       634    408A4 - 40ED7      4000100  31 31   - OK
03  00   FF       2C0    40EDC - 4119B     FFFE1000  23 23   - OK
04  02   FF         0                      FFF37000            N/A


Size            - size of module in ROM expressed in bytes
ROM address     - absolute address range of module in ROM
RAMaddrs        - load point of module in RAM
Cksm (Exp/Act)  - Expected Checksum / Actual Checksum


Note 1:  The address range of affected module may conflict with another module,
          in which case this is probably a false negative.

Note 2:  If this module is the FLASHTBL or SERVOTBL, then this is most likely
          a false negative.

Note 3:  This may or may not be a genuinely BAD module. Examine the checksum
          of the first half of the ROM. If 0x0000, then module is probably OK,
          otherwise it may or may not be bad. Also examine the "adjusted"
          checksum, if applicable.

Note 4:  The address range of the module is outside the limits of the ROM.



Calculating ROM checksums ...
Checksum for 0x000000 - 0x03FFFF = 0x7084
Checksum for 0x040000 - 0x07FFFF = 0xA47E
Checksum for entire ROM = 0x1502

Extents reported by FLASHTBL header = 0x000000 - 0x036FFF
Extents reported by SERVOTBL header = 0x037000 - 0x041FFF

Checksum from 0 to end of SERVOTBL = 0x0502

Checksum (adjusted) from 0 to end of SERVOTBL = 0x0000

[pbzcbf...@gmail.com]

This is the relevant section of the FIPS section:

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

00003000  46 49 50 53 9A 00 00 00 32 2E 30 30 30 20 20 20  FIPSš...2.000  
00003010  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
00003020  FF AA 50 41 4E 32 46 31 4E 44 42 33 35 31 34 35  ÿªPAN2F1NDB35145

Offset 0x3021 has a value of 0xAA when PUIS is enabled, and 0xFF when disabled.

Offsets 0x37FE - 0x37FF are the 16-bit FIPS checksum.

http://www.hddoracle.com/viewtopic.php?f=59&t=1247&p=8221#p8221

I have attached an edited ROM with the PUIS flag disabled.

[James]

Franc, you sir are the man!

I had a lot of trouble getting the ROM written with my programmer but once I did the drive spun up. 

It clicks for a bit but does ID and come RDY. 

I'm going to try and image it now but suspect I will be doing a head swap. 

Thanks heaps for your help mate!

James

[pbzcbf...@gmail.com]

Your ROM dump is for an 8 Mbit chip. The first half is a copy of the second half, so either that is a genuine redundant copy, or you have chosen the wrong chip from your programmer's menu.

To recover from a PUIS enabled situation, you would normally send an ATA SET FEATURES command or a READ SECTOR command. Linux can automatically spin up such a drive. Alternatively, you could wake it up with HDAT2 by using the "/w" modifier. in the early days of Windows 10, one of the updates implemented PUIS, with the result that many users were caught with drives that didn't spin up. This particular Samsung appears to have a bug which causes it to remain asleep after PUIS is enabled. One forum member at HDD Oracle was stung with two HD204UI drives that wouldn't spin up again.

https://www.hdat2.com/hdat2_faq.html#q19

[dradra]

Thanks Franc.

Your explanation below appears to be spot on.

Once I wrote your modified ROM to the donor ROM the drive woke up and ID after some clicking.

I imaged the majority of data with exception of H2.

All other heads are fine.

Time to do a head swap me thinks but, only problem is nobody seems to make a head comb for this model.

Might have to get creative unless anyone knows of a comb available? Maybe Scott's tried, tested and trued pill packet combs.

 

From: datarecovery...@googlegroups.com [mailto:datarecovery...@googlegroups.com] On Behalf Of pbzcbf...@gmail.com
Sent: Friday, 6 May 2022 3:52 AM
To: DataRecoveryCertification
Subject: Re: HD204UI not spinning

 

Your ROM dump is for an 8 Mbit chip. The first half is a copy of the second half, so either that is a genuine redundant copy, or you have chosen the wrong chip from your programmer's menu.

 

To recover from a PUIS enabled situation, you would normally send an ATA SET FEATURES command or a READ SECTOR command. Linux can automatically spin up such a drive. Alternatively, you could wake it up with HDAT2 by using the "/w" modifier. in the early days of Windows 10, one of the updates implemented PUIS, with the result that many users were caught with drives that didn't spin up. This particular Samsung appears to have a bug which causes it to remain asleep after PUIS is enabled. One forum member at HDD Oracle was stung with two HD204UI drives that wouldn't spin up again.

 

https://www.hdat2.com/hdat2_faq.html#q19

 

--

Data Recovery Certification Group / for issue with google group please email sc...@myharddrivedied.com
---
You received this message because you are subscribed to the Google Groups "DataRecoveryCertification" group.
To unsubscribe from this group and stop receiving emails from it, send an email to datarecoverycertif...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/datarecoverycertification/a2545185-8920-4406-b382-c9d9ba9ededen%40googlegroups.com.

[Fraser Corrance]

A while back I had a drive that was behaving in a similar fashion. When I connected it to Linux, the drive would spin up just fine. I moved it over to the PC3K and the drive would not spin when powered on. Franc pointed out something that I was unaware of, Linux will spin up a drive in PUIS when Windows will not. I am not entirely sure if this is true with more recent Linux distros since the distro I have been using is a bit dated. Connecting the drive to Linux may be a quick way of telling if the drive has PUIS turned on.  

[dradra]

Hi Fraser

PUIS was indeed on but Franc kindly edited the ROM which I wrote back to the donor ROM chip. Interestingly I could not get it to write to the original ROM chip but as Franc pointed out may be I selected the wrong chip ID.

The drive spun up perfectly with the edited ROM albeit with clicking but that settle down until H2 was required. H2 was dead.

I performed a swap from donor last night and it has responded well. Scott's pill packaging combs worked yet again in a pinch!

H2 platter surface in one section is likely damaged but possible to image without ECC. Not ideal but better than nothing at this point.

Still imaging data now :)

To view this discussion on the web visit https://groups.google.com/d/msgid/datarecoverycertification/1458e677-9f85-4922-86f8-7a22076ce48dn%40googlegroups.com.