Hitachi name garbled!! What the heck is this??

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.

@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:

Leolo wrote:the name of the drive, detected by the BIOS is completely garbled and nonsensical characters!!!

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.

Leolo wrote:I have visually inspected them and I see nothing wrong or abnormal. What is the procedure to troubleshoot the IDE pins?

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.

Leolo wrote: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?

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:

Code:: C:\>debug -e 100 "HTS424040M9AT00" -e 110 08 "T" 13 "424040M9A" 14 "00" -d 100 11f 12EB:0100 48 54 53 34 32 34 30 34-30 4D 39 41 54 30 30 06 HTS424040M9AT00. 12EB:0110 08 54 13 34 32 34 30 34-30 4D 39 41 14 30 30 12 .T.424040M9A.00. -q

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.

Leolo wrote:What is the procedure to troubleshoot the IDE pins? Just resolder them? Can I test them by software somehow?

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.

fzabkar wrote:The bit differences (0x40) point to a fault in either bit 2 or bit 10, depending on the endianness.

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?

Vulcan wrote:Therefore just to add a bit of variety into the discussion, I calculate it to be data bit 14 which is affected :)

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.

fzabkar wrote:I would think that it could also be bit 6.

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??

Vulcan wrote: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?

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

Leolo wrote: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.

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).

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

Code:: 0 1 2 3 4 5 6 7 8 9 _________________________________________________________ 0 045A 3FFF 8837 0010 0000 0000 003F 0000 0000 0000 10 2020 2020 2020 0D50 0132 3031 1132 0739 0555 3441 20 0003 0D97 0004 0D41 324F 0136 3056 0854 1334 3234 30 3034 304D 3941 1430 3020 2020 2020 2020 2020 2020 40 2020 2020 2020 2020 2020 2020 2020 8010 0000 0F00 50 0000 0200 0200 0007 3FFF 0010 003F BC10 00FB 0100 60 1300 04A8 0000 0007 0003 0078 0078 00F0 0078 0000 70 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 80 007C 0019 346B 3FE8 0023 B469 3C48 0023 203F 0011 90 0000 0080 BFFE 200B 80FE 0000 0000 0000 0000 0000 100 1300 04A8 0000 0000 0000 0000 0000 9796 0000 0000 110 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 120 0000 0000 0000 0000 0000 0000 0000 0000 0009 000B 130 00B9 0000 0000 0000 0000 0000 01FC 0000 0000 0000 140 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 150 8000 0000 324F 0000 0000 0413 0000 0000 0000 0000 160 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 170 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 180 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 190 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 200 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 210 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 220 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 230 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 240 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 250 0000 0000 0000 0000 0000 39A5

These are the data as reported by CrystalDiskInfo:

Code:: C:\>debug low_b14.bin -d 100 2ff 12FB:0100 04 5A 3F FF 88 37 00 10-00 00 00 00 00 3F 00 00 .Z?..7.......?.. 12FB:0110 00 00 00 00 20 20 20 20-20 20 0D 50 01 32 30 31 .... .P.201 12FB:0120 11 32 07 39 05 55 34 41-00 03 0D 97 00 04 0D 41 .2.9.U4A.......A 12FB:0130 32 4F 01 36 30 56 08 54-13 34 32 34 30 34 30 4D 2O.60V.T.424040M 12FB:0140 39 41 14 30 30 20 20 20-20 20 20 20 20 20 20 20 9A.00 12FB:0150 20 20 20 20 20 20 20 20-20 20 20 20 20 20 80 10 .. 12FB:0160 00 00 0F 00 00 00 02 00-02 00 00 07 3F FF 00 10 ............?... 12FB:0170 00 3F BC 10 00 FB 01 00-13 00 04 A8 00 00 00 07 .?.............. 12FB:0180 00 03 00 78 00 78 00 F0-00 78 00 00 00 00 00 00 ...x.x...x...... 12FB:0190 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 12FB:01A0 00 7C 00 19 34 6B 3F E8-00 23 B4 69 3C 48 00 23 .|..4k?..#.i<H.# 12FB:01B0 20 3F 00 11 00 00 00 80-BF FE 20 0B 80 FE 00 00 ?........ ..... 12FB:01C0 00 00 00 00 00 00 00 00-13 00 04 A8 00 00 00 00 ................ 12FB:01D0 00 00 00 00 00 00 97 96-00 00 00 00 00 00 00 00 ................ 12FB:01E0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 12FB:01F0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 12FB:0200 00 09 00 0B 00 B9 00 00-00 00 00 00 00 00 00 00 ................ 12FB:0210 01 FC 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 12FB:0220 00 00 00 00 00 00 00 00-00 00 00 00 80 00 00 00 ................ 12FB:0230 32 4F 00 00 00 00 04 13-00 00 00 00 00 00 00 00 2O.............. 12FB:0240 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 12FB:0250 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 12FB:0260 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 12FB:0270 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 12FB:0280 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 12FB:0290 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 12FB:02A0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 12FB:02B0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 12FB:02C0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 12FB:02D0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 12FB:02E0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 12FB:02F0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 39 A5 ..............9.

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

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

@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:

Some parameters are defined as a string of ASCII characters.
[...]
When such fields are transferred, the order of transmission is:
the 1st character [...] is on DD(15:8) [...]
the 2nd character [...] is on DD(7:0) [...]

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.

fzabkar wrote:Vulcan, thanks again for the correction and explanation.

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

fzabkar wrote: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.

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.

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

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

Leolo wrote:Hitachi Drive Fitness Diagnostics says the drive is perfectly healthy, all the tests pass correctly

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").

fzabkar wrote:ISTM that, if the root cause is not a faulty I/O pin on the MCU, then the repair should be relatively easy.

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?

Hitachi name garbled!! What the heck is this??

Hitachi name garbled!! What the heck is this??

Re: Hitachi name garbled!! What the heck is this??

Re: Hitachi name garbled!! What the heck is this??

Re: Hitachi name garbled!! What the heck is this??

Re: Hitachi name garbled!! What the heck is this??

Re: Hitachi name garbled!! What the heck is this??

Re: Hitachi name garbled!! What the heck is this??

Re: Hitachi name garbled!! What the heck is this??

Re: Hitachi name garbled!! What the heck is this??

Re: Hitachi name garbled!! What the heck is this??

Re: Hitachi name garbled!! What the heck is this??

Re: Hitachi name garbled!! What the heck is this??

Re: Hitachi name garbled!! What the heck is this??

Re: Hitachi name garbled!! What the heck is this??

Re: Hitachi name garbled!! What the heck is this??

Re: Hitachi name garbled!! What the heck is this??

Re: Hitachi name garbled!! What the heck is this??

Re: Hitachi name garbled!! What the heck is this??