Hey guys, I have an IBM Deskstar IC35L040AVER07-0 that has died many years ago with the click of death. After multiple attempts at getting it work, I have possibly broken it further because now the click of death is not present anymore, instead the head just clicks once when the reset line is toggled and then the device is not recognized by the BIOS (just like before).

I received today a working IBM Deskstar IC35L040AVER07-0 from eBay and was able to verify the the PCB from mine was working fine (I moved the EEPROM from the working HDD to the PCB from the non-working one and put that PCB on the working HDD).

I understand that data corruption in the EEPROM is also a possibility so if anyone can tell me the address of the checksum byte/word, I would appreciate it very much.

If the EEPROM proves to be fine too, then we enter a realm I know nothing about, the stuff that's inside, so maybe someone can give me some clarifications regarding what's there and how it all fits together.

I noticed that there's a connector or IC that comes out of the HDD and connects to the PCB, I suspect that's the data line, but I can't figure out if it's an IC or not - any chance that I fried it? perhaps I can replace it with the one from the working one - are the configuration parameters in the EEPROM referring to it too? Actually, what are the EEPROM parameters for? Is the pinout available?

I suspect there's additional electronics inside, for controlling the heads, perhaps an amplifier too connected to the heads. Is this part worth debugging? or what would be the best course of action here? What do you think I should check next?

Are there documents out there describing the function and structure of the service area? Or anything technical regarding a HDDs operation/protocols?

What would it take to drive the the HDD myself?

Sorry for the amount of questions! There are just so many unknowns for me right now, it's hard to get a clear picture of how everything works.

I should note that I have some general purpose test equipment at my disposal that can help in the debugging process.

Any suggestions will be appreciated,
Thank you.

For general reference: http://hddscan.com/doc/HDD_from_inside.html
More than likely, initially, the PCB of the failed drive was not the issue. Clicking behavior typically indicates a mechanical failure of internal read-write components.

If you could explain in detail what you did to change the drive's behavior prior to getting the donor drive, then we may have a better idea of what is going on. Photos should help.

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

I suspect that it will only be of academic value, but if you want to check the EEPROM, then upload its contents and I'll try to compute a checksum for you. ISTR a thread where prominent forum members claimed that a drive could still spin up with a corrupt NVRAM, but I confess that I don't understand how that could be possible, assuming that the NVRAM is checksummed during the drive's POST.

_________________
A backup a day keeps DR away.

@labtech,

Thanks for the link, very good information!

The problem about how I changed the behavior is that I don't know how it happened. I've been trying to resurrect this HDD for years, in various ways. I think I even opened it at some point, but I'm not 100% sure, I definitely messed with the screws, but I remember having second thoughts. What I know for sure is that even if I opened it, I have no memory of messing with anything inside so odds are that I didn't even keep it open for too long.

Among the things I tried to do to it: I kept it out in the cold (not for too long, just enough so it chilled a bit). Have it run in different orientations, tap it vertically and I guess that's about it, but many many times over the course of the past 10 years or so.

What photos are you interested in?

@Spildit,

I have a HEPA 14 air purifier in my lab. I guess I can clean everything up, leave the purifier running for a couple of hours and then I'd be good to go. I don't plan to reuse this so if it works for 30 minutes, that's enough for me.

I remember seeing a HDD running with the hood open, but it was a long time ago, so I guess the construction might have been different.

@fzabkar,

Thanks, I'll desolder it and try to make a dump. Already found the datasheet so it shouldn't take long.

Thank you.

I suspect that the checksum is more complicated than a simple XOR16, but the following appears to work for some NVRAMs:

XOR16 checksum calculator for Hitachi NVRAM:
http://www.hddoracle.com/viewtopic.php?f=22&t=80&p=4588

Note that the checksum may not be calculated over the entire address space. We need to examine the NVRAM contents to be sure.

_________________
A backup a day keeps DR away.

Ok, this might take a bit, the EEPROM is not SPI compatible so I have to bitbang the start instruction bits.

http://datasheet.octopart.com/S-93C66BD ... 356334.pdf

Looks like dumping the EEPROM will take a bit longer, it's not SPI as I initially thought, but MicroWire.

I ended up writing a little protocol decoder in order to make sure that I'm communicating with the chip properly and out of curiosity I hooked up the logic analyzer to the EEPROM, while it was mounted on the PCB and the PCB on the HDD.

I may have stumbled upon the reason why the EEPROMs on these HDDs are known to get corrupted.

It appears that they're clocking in the data in reverse clock polarity than what the EEPROM is expecting. They setup the data on the same edge that the EEPROM is sampling it and they're getting away with it just because there's a bit of a delay between the setup time and the clock edge, so the EEPROM reads the correct value.

They either misread the datasheet and got confused by the fact that the EEPROM is expecting data in on the rising edge, but it's pumping out data to be sampled on the falling edge, or the main MCU was unable to deal with this properly and they had to work around it, but if that was the case, they could have simply used a different EEPROM, because this solution would have simply been unacceptable. My money is on misunderstanding the datasheet and getting away with it through sheer luck, which from time to time ran out and the 10 command that indicates a read, became a 11 command, which indicates a write.

PS: Sorry for when my previous post shows up, I would have edited that one but it's currently being moderated because it has a link in it.
I would have added some screenshots here to prove my findings but I don't want to risk this post ending in the moderation queue too.

Couldn't find the edit button, but I wanted to add a rectification to my previous post. 11 is not a write command, but an erase command.

Wow! That's an amazing bug.

_________________
A backup a day keeps DR away.

Indeed. I attached a couple of screenshots to back my claims.

In the logic analyzer screenshot you can see how the DI data is being setup on the same edge with the DO data, when the datasheet clearly shows that that's not how it should be, because after the opcode and address are received, there's a polarity change and the data shifted out by the EEPROM is meant to be sampled on the opposite edge than the data shifted in.

I will attach the contents of the two EEPROMs in a bit, I just managed to extract the contents from the IC that was on the working HDD.

I attached the dump of the EEPROMs. A quick file compare doesn't show many differences and none of them seem to be the result of an erase.

As expected, both checksums are OK.



As for the traces, the datasheet specifies a minimum data setup time (tDS) of 0.2us. ISTM that the delay between the trailing edge of DI and the leading edge of SK may actually satisfy this requirement, but you would need to expand the scale to be certain.

_________________
A backup a day keeps DR away.

Looks like you may be right about the setup time, I thought I'm on to something. The time between the samples in the LA screenshot is 0.5 us so I'll have to check again once I have one of the HDDs assembled again.

Thanks for the checksums. I suppose that leaves me with:
1) Heads or preamp fried.
2) Mechanical failure.
3) Some important data that it's looking for, it's not there anymore.

I suppose I should prepare myself to open it up. Any further thoughts?

Thanks.

@Spildit,

Well, then I suppose my only chance right now is to replace the head assembly. That's gonna be fun.

may be somebody knows ?
what microprocessor architecture is used on these IBM
thank you

It's proprietary Mitsubishi core with 24bit instructions.

_________________
SAN, NAS, RAID, Server, and HDD Data Recovery.

there is some description of the system commands ?

not that I know of.
опкоды неизвестны, дизасмов коммерческих нет. Ядер было несколько, все с неизвестными опкодами.

_________________
SAN, NAS, RAID, Server, and HDD Data Recovery.

thank you
эвристически там кой чего понятно.даже адреса видны отчетливо. но вот с кодами ошибок (напр. на MRU reset)
не могу ухватить.