Where is EEPROM in Samsung HM060HC HDD?

[Per Hansson]

Hi, I have a Samsung HM060HC that gets recognized by BIOS as a "CAMSENG HM 6 HC" drive at 60GB
Windows sees just a 5.91GB RAW partition...

I bought a new BF41-00100A PCB for it and I was not expecting the swap to work, because I've tried this in the past and it did not...
Drive is not even recognized with the new PCB...

But I can't identify the EEPROM, I know I need to transfer it to the new PCB I bought. I guess it's in either the Marvell chip or the TLS2502
I found also a service manual, it's not for the exact same drive but very similar, but the block diagram showing the "Internal flash ron" (sic) just has me scratching my head...

I attached some pictures of my drive, the service manual for the very similar M40 is here: http://files.hddguru.com/download/Datas ... 20Manuals/

Attachments

[pcimage]

The "ROM" is embedded into the MCU (large "M" chip)

Not DIY

[mr_spokk]

No, not DIY and it looks like a FW corruption.
PM me if you need help on this.

Med vänlig hälsning
Bosse

[Per Hansson]

Thanks for your replies.
I suspected the ROM would be in the Marvell chip.
I will ask the person that gave me this disk how much they want their data back...

But I'm also not afraid to learn, what kind of equipment must be used to get around data corruption in the EEPROM like this?

Because I had a very similar case (see below) but I gave up since the data on the drive was not that important for them anyway...

Code:

MANUFACTURER: HTS421280H9AT00
CAPACITY: 80

PROBLEM DESCRIPTION:
The drive is identified on startup by the BIOS as HTC4"1"8 H)AD0
Once inside Windows the size of the drive is recognized (80GB) and the partitions
But they can not be read, I tried to recover data using RunTimeSoftware GetDataBack NTFS
It was able to read the metadata and list all files, but they where all corrupt when I tried reading them after recovery

PREVIOUS ATTEMPTS:
A donor PCB was bought, exactly matching MLC number (DA1303)
And also matching the first two rows of numbers on the PCB sticker (0A26790, DA1187B)

On first test drive was not found at all, so I desoldered the eeprom from the original PCB and put it on the new one
The drive was now identified as before; HTC4"1"8 H)AD0 and filesystem was unreadable from Windows as before

Next I swapped over the flash memory IC aswell, but there was no change


[Doomer]

Because I had a very similar case (see below)

I wonder what's the similarity, they both drives?

[Per Hansson]

Doomer: Very similar in the way they are recognized incorrectly by the BIOS
Spildit: That other drive was tested on multiple PC's, cables and finally with a new PCB, since nothing helped and the user did not want to pay much for data recovery that drive has been trashed...

[Per Hansson]

...And also very similar in the sense that the corruption of that other drive was also in the EEPROM, since the new PCB behaved just like the original one once I transferred the EEPROM over to it...

[pcimage]

"mr_spokk" can help you with this.

And his prices are reasonable I believe.

[BlackST]

To me the problem on the Samsung is in the INTERFACE (ATA), that can be the MCU itself (one line)

[Per Hansson]

The owner got back to me and said he was not interested in paying for professional recovery services (mr_spokk: Men tack för erbjudandet)

I'm still interested in seeing if I can do this recovery myself, I'm not new to soldering.
But from reading what you are saying it seems that just like with my other drive I described moving the Marvell chip over from the old PCB to my new one is just very likely to move the problem aswell (Corrupt firmware)
So what in broad terms is done to get around a corrupt firmware?

[Per Hansson]

I had another look at the drive today, with the PCB I bought it tries to find the starting area (drive clicking) but gives up and shuts down the spindle motor after three attempts.

So I put back the original PCB, drive sounds great just like before, still detected improperly though of course.
But almost all data in HDAT2 looks good, SMART info etc (no bad sectors) when I try reading the drive in HEX I get nothing though, and the IDENTIFY says CAMSENG too of course just like before...

I'd like to give some background to what I think is the cause of firmware corruption. (Originally I thought it was PCB damage because of this).
The laptop it was in got a bad DC jack and probably fried MOSFET PQ1 on the mobo as the end-user kept using the thing untill it killed it's power adapter. (How someone does not backup at this stage is beyond me).
The end user then continued trying to "fix" the DC plug and made the problem even worse, I'm assuming the HDD was connected all this time...

Is there no service mode I can access in a Samsung drive like this and bring it up in a safe mode without loading all the modules, because I guess one of them must be where the corruption resides?
I do have a TTL interface and have fixed two out of two Seagate 7200.11 drives this way so it's not all jibberish to me

Attachments

[hddguy]

Are you sure in both cases PCB is bad??

[Per Hansson]

Ignore the Hitachi drive, that has long ago been thrown away anyway...
At first I thought it was PCB damage on the Samsung but now after the advice given here I think it's only firmware corruption

[BlackST]

To me, no. Anyway it is not a Seagate and what you 'fixed' on the .11 is not actually a fault. This one is different and NO you can't tinker as you wish with terminal. Data is no longer important, right ?

[Per Hansson]

No, the data is no longer important as the customer does not want to pay for it.
So now it's just a learning experience for me...
So I don't mind if I brick it

Well fault or not on the 7200.11 I guess depends on how you look at it.
All user data impossible to access.
And then running the commands and reattaching the PCB makes it all accessible again

[Per Hansson]

The drive does look to be more alive than I first thought.
R-Studio is able to access the partition that Windows can't see.
(Even though device manager in Windows thinks the total drive capacity is only 5.91GB, i now realize that is probably the hidden Acer recovery partition...)

But it's not able to recover the files themselves, they just come up as jibberish, seems MFT etc is unreadable, but even then some data should be possible to find but nothing so far, some filenames etc and other structures can be read though so drive is definitively working at some level...

Attachments

DiskMGMT.png (1.71 KiB) Viewed 15523 times

[Per Hansson]

Hi, I just thought I'd post an update on this, even though it does not put myself in the best light

To connect to the HDD I used a 2.5" to 3.5" adapter, just like the one in the image below...
Turns out there was a poor soldering in the adapter on pin 12 which is for data 12 in the ATA spec.
Apparently this causes this exact error, after resoldering the surface mount pin the HDD was detected and read just fine!

Attachments

[Vulcan]

Well done for finding the problem and that fits with your initial posting:

I have a Samsung HM060HC that gets recognized by BIOS as a "CAMSENG HM 6 HC"

For example:

1st letter reported to be "C" (ASCII value 0x43) but should be "S" (ASCII value 0x53) - difference = 0x10 missing
3rd letter reported to be "M" (ASCII value 0x4D) and so the altered bit is not noticed to be "missing", as it should be "missing"!
5th letter reported to be "E" (ASCII value 0x45) but should be "U" (ASCII value 0x55) - difference = 0x10 missing
etc.

Due to the way that strings are sent in the response to ATA Identify Device (which is the underlying ATA command being used here), that difference of 0x10 is in the high byte of a wide transfer, and so that is bit 4 (the fifth bit) of the upper byte = data bit 12 (the 13th bit). These sorts of issues have different effects, depending on which bit(s) are changed (stuck high or stuck low).

There are various ways of checking for that type of problem, in addition to the manual review I explained above. I remember at least one old PC diagnostic utility checked for such corruption, due to the IDE cables being a source of similar problems. Hopefully your adapter is now going to behave itself!

[fzabkar]

Here's an easy way to see the bit difference (edited for clarity):

Code:

C:\>debug
-e 100 "CAMSENG HM 6 HC"
-e 110 "SAMSUNG HM060HC"
-d 100 11f
1262:0100  43 41 4D 53 45 4E 47 20-48 4D 20 36 20 48 43   CAMSENG HM 6 HC
1262:0110  53 41 4D 53 55 4E 47 20-48 4D 30 36 30 48 43   SAMSUNG HM060HC
-q