Hi everyone,

I have a Hitachi HTS424040M9AT00 drive
PN: 13G1132
MLC: DA1017

The funny thing is that the drive "apparently" is working (Hitachi Drive Fitness Diagnostics says the drive is perfectly healthy, all the tests pass correctly), but the name of the drive, detected by the BIOS is completely garbled and nonsensical characters!!!

I've put the drive in three different computers, all of them see the drive name as garbled characters! How can this be??

Another problem I have is that I cannot remove the HPA area (which is 8 mbytes currently). I have used the official Hitachi Drive Features tool, but the program thinks that the command executes correctly (it says operation successful), even though it DOESN'T remove the HPA area!!!

I've also used HDAT2, but this program says that the SET_MAX command fails, and cannot remove the HPA. I've tried LBA48, LBA28, volatile, permanent, I've tried all combinations, but it always fails

My main problem is that Windows doesn't recognize partitions in the drive. And I've tried several data recovery software (in read-only mode) but they all fail.

I've also tried the "analyze" function of the opensource TestDisk program (version 6.12 WIP), and this program says that the partition table is wrong, because the drive is smaller than it should be!!

I suppose that the drive is smaller because there is 8 megabytes reserved by the damn HPA area.

Is there any way to get rid of that ANNOYING HPA area somehow??? PLEASE HEELP!!

Thanks a million!

Check your IDE pins.

_________________
www.datarecoveryne.com

@Leolo: I agree completely with harddrivespecialist that you should check the IDE pins. A specific type of problem there, can account for all of your symptoms. You said:


Even though the drive name looks "completely garbled" to you, it can sometimes help to identify the actual problem to see exactly how it is "garbled".

Please supply a screen photo / screenshot (just a small image - not a full resolution 16Mp photo!) showing exactly what "garbled" drive name is being reported.

Thanks for your replies!

I've uploaded some screenshots here:

http://www.leolo.es/dmde.png
http://www.leolo.es/rstudio.png
http://www.leolo.es/gdb1.png
http://www.leolo.es/gdb2.png

fzabkar, another user of this forum, has also told me that it could be a problem with the IDE pins, so I guess there must be something wrong there.

However, I have visually inspected them and I see nothing wrong or abnormal. What is the procedure to troubleshoot the IDE pins? Just resolder them? Can I test them by software somehow?

Also, why does the DOS-based Hitachi Drive Fitness Diganostics pass the drive as healthy so easily??

Shouldn't the test software be a little bit more strict with the problems of my drive?

Thanks!

Thanks for the screenshots. As I expected, they show that the drive model identification is not what I would call "completely garbled" - some parts are completely correct e.g. "424040M9A".

The text before & after that part (including "Hitachi", as you mentioned), varies a little in the outputs from the different utilities perhaps due to ASCII "control characters". Personally, I would be checking the true result of an Identify Device command in MHDD (or similar), to see exactly what hex is being returned to the host for the drive make & model info.


Several approaches are possible... Personally, after getting a better view of the data using MHDD as I explain above, I would start by using an oscilloscope, while doing disk reads - checking the low & high voltage levels and transition speeds on all relevant interface signals (not only data).

As an example, further checks would then include seeing if the contents of all ATA registers seem to be affected - or is this just affecting the data buffer? As with all troubleshooting, the better you can be specific about exactly what is being affected, the easier it is to then identify which components are on the list of "suspects".

However based on the exact form of that corruption, I am not convinced that this is a pin problem. Unfortunately without the drive here, I could waste time making lots of wrong guesses, whereas with the drive in front of you, the answer would be much quicker.


This is a classic example of why you shouldn't (can't) rely on a "good" diagnostic result from any test - in fact I'll use this example of the misleading "Hitachi Drive Fitness" result, when I teach my next troubleshooting class .

As I explained above, the fault is not affecting all I/O. So all you need for an apparently good result, is for the fault not to return an obviously "wrong" answer.

For example, I expect that a "read test" on that drive will not fail - it'll probably just return partially wrong data (which is also why the partitions aren't correctly recognised), but any kind of "read-only fitness test" software won't know that the data which is read isn't the expected data! If you used test software that does a write-read-compare across the IDE interface, that test should fail, but obviously that's destructive to some data on the drive. (Also, since some bytes crossing the interface are being corrupted, I do not recommend that you attempt any write commands to the drive - perhaps bytes written to the LBA registers are also being corrupted (see below) and then the data would end up being written to the wrong place!)

Some drives will do such a write-read-compare to the SA during a SMART test - but since the data pattern used for the write & read does not pass across the IDE interface in that case, then again, that test would still pass even with this type of fault! Are you starting to see how easily you can be misled by a test "passing"?

It all depends on the test that is being run, exercising the defective part and having a way to detect all possible failure (i.e. incorrect result) mechanisms. That's not trivial for software to achieve this (although the quality of diagnostic software varies significantly) , and is especially to detect for some types of partial problem, as you have on this drive. Over the years, I have seen many, many pieces of diagnostic software which do not detect specific faults...

For you, I suspect that the easiest solution (if you can't, or don't want to, find the electronics fault yourself) is to replace the drive's PCB, as well as moving whatever drive-unique info exists on that PCB to the replacement. Others on this forum may be able to advise on how to do that, or may be able to do the job for you.

Hope that helps

I would have preferred a copy-and-paste, but here is a comparison of the good and bad model name, using Debug in a Windows DOS box:



The IDE bus is 16 bits wide, so each pair of bytes in the model name corresponds to bits 0-7 and 8-15 of this bus. As you can see, it is only the first byte of each pair that is corrupt. The bit differences (0x40) point to a fault in either bit 2 or bit 10, depending on the endianness. This in turn points to a problem in either pin 13 or pin 8 of the IDE interface.

http://pinouts.ru/HD/AtaInternal_pinout.shtml

Because the problem persists after switching cables (?) and motherboards, then the fault is most likely a dry solder joint at the IDE connector on the HD, or a faulty terminator resistor, or a faulty I/O pin at the MCU.

I don't know about the HPA, but if the interface has a stuck bit, then any data that is transferred along that interface is also corrupt.

As I suggested privately, if you use CrystalDiskInfo, you can capture the 512-byte block of information that is returned by the drive in response to an ATA Identify Device command. This includes the drive's serial number, total LBAs, HPA information, DMA/PIO capabilities, and various features and settings. Of course all these data will be corrupt due to the stuck bit, but the raw bytes will be instructive.


Software has already told you which pins to inspect. :-)

If you upload a photo of the IDE interface in the area of pins 8 and 13, then we can identify the terminator resistor for you. If you need to replace the board, then there will be an 8-pin NVRAM chip that may need to be transferred to your donor. A photo of the whole PCB would help us identify this chip for you. If you post the markings of each 8-pin chip, then this will help also.

_________________
A backup a day keeps DR away.

The problem shown in the data is with the high-order of the two data bytes - and within that high-order byte, it's the next-to-highest bit which seems to be stuck low in the limited data we've been shown so far.

Therefore just to add a bit of variety into the discussion, I calculate it to be data bit 14 which is affected (that's as a minimum - bit 15 could also be affected; or it could be that the signals for data bits 14 & 15 are shorted together; etc. - can't tell without the additional Identify Device data that I see we've both suggested to the OP ).

Anyone with yet another suggestion?

Sorry, you're right. However, because the Identify Device data are reported in little endian format, I would think that it could also be bit 6. The corresponding IDE pins would be #16 and #5.

_________________
A backup a day keeps DR away.

For more than one reason, I'm confident that it isn't that bit, and is instead bit 14 which is affected (at a minimum, as I explained previously) - but I understand completely why the endianness of that data can lead to confusion.

If you're open to the possibility that I'm correct, perhaps the quickest place you can get that confirmation is from the ATA spec itself. You'll see that all ASCII strings in Identify Device data, are stored in a way which have the first character (in this case, what should be an "H") as the high-order byte within the first word of the ASCII string. Since the "H" (first character) is affected with this fault, then the fault is affecting the high-order byte, meaning that it is bit 14 rather than bit 6 which is affected (at a minimum).

I could find a few mins to look-up the relevant section of the ATA spec over the weekend, if you'd like me to do that?

This is what CrystalDiskInfo says about the drive:

http://www.leolo.es/crystaldiskinfo.txt

Curiously, CrystalDiskInfo doesn't agree with official Hitachi DFT diagnostics software, and says the drive is bad.

I've found a site that seems to have a similar PCB in stock:

http://www.firmwarefinder.com/Search/pa ... id=1230907

Are these guys trustworthy? Has anyone had good experiences buying from them??

Thanks very much for that, and for your correction. And, yes, I'm always open to the real possibility that I'm wrong yet again. :-) Nevertheless, I had been meaning to experiment with an actual drive before I replied to you, but I haven't yet got around to it.

BTW, the Identify Device data are explained in Section 7.16.7. of the following document:
http://www.t13.org/documents/UploadedDo ... A8-ACS.pdf

_________________
A backup a day keeps DR away.

The SMART and Identify Device data are corrupt, therefore any interpretation of these data is invalid.

For example, notice that many of the current values of the SMART attributes are 36 (= 0x24). Since bit #14 is always (?) low, this means that these values are also low. Instead they should be 100 (= 0x24 + 0x40 = 0x64).

Similarly, the Power-On Hours value should be 98 (= 0x22 + 0x40), and the UltraDMA CRC Error Count should be 200 (= 136 + 0x40).

_________________
A backup a day keeps DR away.

I believe the following layout matches the word format in the Identify Device section of the standards document.



These are the data as reported by CrystalDiskInfo:

_________________
A backup a day keeps DR away.

@fzabkar - Agreed completely. The differences which you identified in the reported SMART normalised values, due to the "missing 64" (0x40), explains why they appear to be below the threshold values.

re: the ATA spec - Thanks for that. IMHO the most important part of the Identify Device description in that version of the spec, is where it refers to the model name (and serial number, firmware revision, etc.) as being an ATA string. Some previous versions of the spec called it an "ASCII string", which doesn't hint at the ATA-specific behaviour i.e. the byte-swapping of such strings that we've discussed. Also, in recent versions of the spec the description changed slightly, with less explanation of the PATA transfer behaviour of ATA strings, than in some earlier versions of the spec.

Therefore personally I prefer the explanation given in ATA-7 (vol 1) about which bytes in such a string, get transferred across which byte (low or high) of the PATA interface:

http://www.t13.org/Documents/UploadedDo ... lume_1.pdf

This effect on PATA transfers of these strings is explained in section 3.2.9, where that version of the spec gives an example which says:


So the first character of the model name string ("H" in this case) gets transferred (and, in this case, gets corrupted) across the high-order byte of the PATA interface.

@Leolo - Thanks for that new data. As fzabkar has explained, there is a clear reason why some diagnostic software might report the drive as faulty, due to the corrupted SMART values which the software reads from the drive, caused by the interface-related problem being discussed here.

Looking for something which can reasonably be guessed in the Identify Device response, and which should have all bits set in the high byte, I chose word 92, which is the Master Password Revision code. Normally this would be 0xFFFE and seems to be reported as 0xBFFE on your drive. To me, this extra information indicates that only data bit 14 is being affected (not bit 15, which was also a possibility from the earlier info).

As fzabkar also explained, there is more than one possible cause for this type of behaviour (i.e. it is not necessarily a problem with that physical pin).

Vulcan, thanks again for the correction and explanation.

In addition to word 92, the are several words where the ATA standard stipulates that bit #14 "shall be set to one", ie 50, 83, 84, 87, 93, 106. Obviously these words will all be invalid.

In particular, word 93 reports the "Hardware reset result". Perhaps Hitachi's diagnostic is failing the drive because of this invalid word???

BTW, I have verified that the state of bit #14 is always 0. ISTM that, if the root cause is not a faulty I/O pin on the MCU, then the repair should be relatively easy.

_________________
A backup a day keeps DR away.

No worries - and thanks for the pointers and info from your end too.


Agreed - I just picked one example of a value that hopefully others reading the thread would recognise, since the typical 65534 (i.e. 0xFFFE) value of that word is quite well-known.


Actually the OP reports that the Hitachi tool does not fail the drive:


Which suggests that this program isn't doing comparison of SMART normalised values with thresholds either (since, as you kindly explained earlier, the CrystalDiskInfo program could be using those apparent (but actually corrupted) SMART values, to declare the drive health to be "Bad").


I see what you mean. I guess it's down to the OP as to how much they want to attempt to diagnose & fix the existing PCB vs. replacing it.

Hi everyone,

Yes, I have passed the Hitachi DFT test again (this time from a floppy disk, which offers a logging option) and it passes correctly. No warning, no errors. Everything is correct.

I've uploaded the log here:
http://www.leolo.es/dftlog.zip

But it's encoded in some binary format I cannot understand. And there isn't any tool that I can find to parse the BLZ file...

I'm tempted to buy a replacement PCB, or even an identical drive (it's still on stock on some warehouses) but I don't have the software to reprogram the chips in the PCB of the donor drive.

I suppose I'd also need specialized hardware as well. Or even digital probes and/or oscilloscopes. But unfortunately I don't have any of those, so I'm not sure I can do anything with this drive

If you are lucky, all you will need will be a multimeter and a soldering iron.

Could we see detailed photos of the PCB, including both sides of the area around the IDE pins, particularly at pin #16 in the middle of the connector?

_________________
A backup a day keeps DR away.