Hi

I have an old HDD

IBM Deskstar
Model IC35L080AVVA07-0
82,3GB
S/N A4GDT9VA
P/N 07N9210
Mar 2002

The HDD isn't recognized by the BIOS anymore. On various systems.

When only connected to the power cable, the head is moving and searching continuously with no end in intervals of about 1-2 seconds. Back and forth ...and so on.

I think the drive is looking for its firmware which isn't found anymore. The drive has no head crash.

The drives are well known for bad soldering.

How can I know/learn if the problem is bad soldering or a damage of/on the "system area" ("SA") ?

The drive was working but suddenly during execution of

SeaToolsforDOS Version 2.23
http://www.seagate.com/files/www-conten ... 223ALL.ISO

the drive began to do these endless movements of head back and forth.

Is this bad soldering (electrical problems) ?
Or damage of SA (firmware) ?

How to differentiate ?

Please let me have your advice.

Thank you.

Regards

AW

These drives are well known for OTHER failures. Never seen such problem on hundreds of them I have either serviced or reconditioned. If you have doubts, reflow the pcb / suspect areas with IR and fluxer.

You just need a HW tool like PC3000 to diagnose it with 100% success.

Otherwise, trial and error is your option (PCB, then non volatile memory, then you're at a dead end as it is media, SA or heads or a combination of these factors).

There's nothing you can do with free stuff on the internet if the problem is either in service area or u-code.

If the drive contain no valuable data accept the loss and carry on, if it is from customer it's time to use the tools if you have any (I mean real hardware HDD diagnostics not the free software from manufacturers), otherwise outsource.

Good luck.

P.S. if the drive with only power gives endless clicking , it's usually bad news.

Isn't this model = "Deathstar" ?

http://www.astro.ufl.edu/~ken/crash/

"Deathstars" came in different flavors....

If the drive had powered up and identified itself correctly to BIOS or SeaTools, then it will already have loaded the NVRAM into SDRAM, and it will have successfully accessed the SA. If the failure subsequently occurred while the drive remained powered on, then AFAICS it must be a HDA fault, not NVRAM.

In any case, I'm finding it difficult to accept that any designer would allow a microprocessor based device of any kind to power up if the integrity of any flash/ROM/EEPROM could not be verified. Surely a HDD designer would implement a checksum test as part of any POST?

_________________
A backup a day keeps DR away.

NVRAMs and ROMs usually do not ask permission when they think it's time to suicide neither glow saying "hey dude I got corrupted because something happened".
Any further explanation is pointless for the "OP" .



Tell Seagate, IBM and co. If commercial stuff is designed that way there's a reason, not a conspiracy against users that get their stuff bricked/unusable. The vast majority of stuff have NO integrity check of their firmware/modules for precise reasons (and honestly I like it very much ).

Here is a course outline from Salvation Data:
http://www.salvationdata.com/news/20120614.htm

HITACHI IBM DRIVES:

- firmware structure
- how to check if firmware booted correctly
- SA-A and SA-C booting
- NVRAM command set test
- NVRAM STRUCTURE
- NVRAM BOOT FLAG
- NVRAM CHECKSUM
...

_________________
A backup a day keeps DR away.

Play with a real AVER / AVVA , not with Google. You'll discover something interesting.

I've examined quite a few Hitachi/IBM HDD resources and ISTM that the NVRAM checksum/CRC/ECC bytes are probably located at offsets 0x0C - 0x0F. However, I haven't yet managed to work out how these bytes are calculated.

In another similar thread I suggested a method by which the location of the checksum could be determined (by setting and resetting the PUIS flag and comparing the chip contents before and after), but apparently my method would only have applied to the "ROM", not the NVRAM. Nevertheless, one of your colleagues reported that his tool (PC3K?) would not allow him to write a ROM image that had a bad checksum but was otherwise OK. AISI, this confirms that checksums are important for Hitachi/IBM drives.

More recently, I have been told that PC3K allows one to edit the NVRAM, and that Ace Lab provides an additional utility to recalculate the checksum.

_________________
A backup a day keeps DR away.