PC3000

(1)

"MAXTOR: D536DX, D541X, Diamond Max VL40, D540-4D,

D531X, Diamond Max Plus 60, D541X, Fireball 3, Diamond Max

Plus 8, Diamond Max Plus 16, Diamond Max Plus 9"

1. Purpose

Utilities of PC-3000 software and hardware complex can be used for service maintenance of Maxtor drives. Basic repair capabilities:

- correction of damaged data structures in drive firmware;

- hiding physically damaged parts of drive surfaces using reserved space provided by the manufacturer; - removal of data protection password.

We have also reviewed repair methods for electronic boards of the drives as well as causes of specific malfunctions.

Warning! The success of utilities' usage depends on the level of operator's proficiency. Incorrect application of

algorithms implemented in the utilities may irreversibly damage a drive or prevent restoration of its data.

2. Structure of drive families

Table 1. Structure of drive families. Family, factory alias,

utility. Model Capacity, _Gb. Disks

Reading / writing

heads Maximum LBA 536DX, VULCAN, pcmx_dsp.exe, ver. 2.01 4W100H6 4W080H6 4W060H4 4W040H3 4W030H2 100 80 60 40 30 3 3 2 2 1 6 6 4 3 2 195,711,264 160,086,528 120,103,200 80,043,264 60,030,432 D541X, ATHENA DSP, pcmx_dsp.exe, ver. 2.01 2B020H1 2B015H1 2B010H1 20.4 15.4 10.2 1 1 1 1 1 1 40,020,624 30,214,800 20,012,832 Diamond Max VL40, PROXIMA, pcmx_dsp.exe, ver. 2.01 34098H4 33073H3 32049H2 31535H2 31024H1 40.9 30.7 20.4 15.3 10.2 2 2 1 1 1 4 3 2 2 1 80,043,264 60,032,448 40,021,632 30,015,216 20,010,816 D540-4D, ROMULUS DSP, pcmx_dsp.exe, ver. 2.01 4D080H4 4D060H3 4D040H2 4D030H2 30.0 41.0 61.5 82.0 2 2 1 1 4 3 2 2 160,086,528 120,069,936 80,043,264 60,030,432 D531X, NIKE, pcmx_dsp.exe, ver. 2.01 2R015H1 2R010H1 15.0 10.2 1 1 1 1 29,297,520 20,011,824

Diamond Max Plus 60, RIGEL, pcmx_dsp.exe, ver. 2.01 5T060H6 5T040H4 5T030H3 5T020H2 5T010H1 61.5 40.9 30.7 20.4 10.2 3 2 2 1 1 6 4 3 2 1 120,103,200 80.043,264 60,030,432 40,021,632 20,010,816 D541X, ATHENA Poker pcmx_pkr.exe, ver. 2.01 2B020H1 2B015H1 2B010H1 20.4 15.4 10.2 1 1 1 1 1 1 40,020,624 30,214,800 20,012,832 Fireball 3, ARES 64K, pcmx_pkr.exe, ver. 2.01 2F040J0/L0 2F030J0/L0 2F020J0/L0 40 30 20 1 1 1 1 1 1 80,293,248 60,058,656 40,718,160

(3)

Diamond Max 16, FALCON, pcmx_pkr.exe, ver. 2.01 4R060L0/J0 4R080L0/J0 4R120L0 4R160L0/J0 60 80 120 160 1 2 2 4 2 3 4 8 120,103,200 No data No data No data Diamond Max Plus 8,

N40P, pcmx_pkr.exe, ver. 2.01 6E040L0 6E030L0 6E020L0 20 30 40 1 1 1 1 1 1 80,293,248 60,058,656 40,718,160 Diamond Max Plus 9,

CALIPSO, pcmx_pkr.exe, ver. 2.01 6Y200P0 6Y160L0/P0 6Y120L0/P0 6Y080L0/P0 6Y060L0 200 160 120 80 60 3 3 2 2 1 6 5 4 3 2 398,297,088 320,173,056 240,121,728 160,086,528 120,103,200 D541X and D540X-4D drive families consist of two subfamilies: “DSP” and “Poker”, characterized by considerable differences in the functioning of factory mode commands. “DSP” and “Poker” are respective labels on a system controller chip (please see section 9).

In families using a single disk and one head only the rated drive capacity is achieved through usage of different number of physical cylinders.

3. Basic options for repair of Maxtor drives

TheɊɋ-3000 package utilities for the above-listed drives provide for the following repair operations: - drive testing in factory mode;

- restoration of the drive firmware data; - reading of the drive's ROM copy;

- review and checking of the firmware structure;

- loading of a program for firmware data access (LDR file); - creation of an LDR file if an operational drive is available; - review the G-List and P-List tables of hidden defects; - addition of discovered defects to P-List or G-List; - translator recalculation;

- running and monitoring of a drive's self-testing routine (for DSP-based models).

4. Preparation for work

1. Connect the Ɋɋ-3000PRO tester cable to the IDE connector of the drive being tested. 2. Connect the power cable to the drive being tested.

3. Switch on the power. If a PC3K PWR power supply adapter is present, the power supply is switched on automatically at utility start. Power may be switched on without turning the PC off first. Damage to the PC-3000 PRO controller in that mode is unlikely; however its output cascades may be damaged in cases when a burnt-out electronic board is connected.

Attention! You'll need to have EMM386.EXE loaded in order for the Maxtor utilities to operate. Due to some

peculiarities of himem.sys driver functioning in Windows the utilities for Maxtor DSP, POKER/ARDENT have been designed for use of EMS services, therefore the following line must be present in the config.sys file to enable loading of the EMS driver (device=c:\windows\emm386.exe RAM).

4. Start a utility corresponding to the connected drive's family using the shell.com command shell for convenience. 5. Auxiliary utility files are located in the same directory with the utilities. Please see details regarding auxiliary files in section 8.

(4)

5. Utility usage

5.1. Launching the utility

After launching the utility sends a command for reading a drive's ID area and displays a menu for drive family selection. Drive families are identified in the menu by their factory aliases. For correspondence between family aliases and models please see section 2.

After drive family selection you'll see a menu for utility start:

Standard mode Re-read drive ID Initialization from SA LDR-file loading Memory buffer writing

Suppress Reset while utility work

Standard mode starts the utility with complete drive initialization. If the drive is malfunctioning (LDR file is

either not loaded or its loading has not activated the drive firmware) the following error message is output:

Error loading the modules table!

If the DISK(PN=1Fh) module cannot be read the following message will appear:

Error loading configuration module!

Re-read drive ID command updates configuration data in the “MODEL” line. This feature is useful for

diagnostics during drive start.

Initialization from SA command forces partial start of a drive loading firmware from its service data area on

disk. If the drive start succeeds, firmware version should be modified, but that procedure is not automatic. Use the

“Re-read drive ID” command to update the information in the “MODEL” line.

LDR-file loading – accessing that command is recommended without drive initialization in cases, when

firmware data must be restored.

Memory buffer writing command is optional and repeats similar option from the "Work with memory buffer"

menu of the utility. It serves for a more convenient initialization of ATHENA DSP drives, which require for a proper start loading of a RAM copy from another drive in addition to an LDR file.

Suppress Reset while utility work menu option disables the Reset signal during utility launch and operation.

Resetting is enabled by default.

5.2. Utility menu structure

Standard mode selection in the mode selection menu with subsequent drive initialization brings up the main menu of the utility:

Logical scanning Disc firmware zone Disc ID

Defects table

SELF TEST

Exit

5.2.1. Logical scanning

Logical scanning is a drive surface test utilizing logical parameters. This command is described in detail in

(5)

5.2.2. Disc firmware zone

Selection of that option brings up the following menu:

Work with memory buffer Work with SA

LDR- file loading LDR- file creation

Security subsystem

5.2.2.1. Work with memory buffer

Work with memory buffer option brings up the following menu: Memory buffer reading

Memory buffer writing

Both those commands allow respectively reading and writing of memory buffer. Work with memory buffer is necessary while starting a drive with the help of an LDR file. As a matter of fact, when a drive is started using an LDR file several firmware variables remain uninitialized preventing recording to firmware zone. However, this method has limited applicability and works with ATHENA DSP family drives only. We do not consider currently the applicability of the method for other drive families because of its complexity since the procedure of loading adaptive data is just as efficient as memory image loading remaining at the same time much simpler and easier. An opportunity for work with memory buffer is implemented in the utilities for all drive families, so you can try to develop an alternative method different from the one suggested by our experts.

Earlier versions of the utilities used the method of memory image loading instead of firmware initialization after loading of an LDR file, which somewhat complicated utility application. In the current version the problem has been resolved by the "Test firmware zone recording" command (please see section 7).

5.2.2.2. Work with SA

Work with firmware zone menu consists of the following commands: Checking of disc FM structure

SA surface checking Reading of modules Writing of modules Reading module groups Writing module groups SA write test

Modules repairing Translator regeneration Spindle stop

Checking of disc FM structure command outputs a report on the condition of firmware modules. Start of that

command forces reading of modules taking about 1 minute on the average. The command is described in detail in section 6.

SA surface checking command allows testing surface of the firmware zone using the UBA addressing mode. Reading of modules command allows reading of modules. While reading it records copied modules to the

“MXDSPMOD” or “MXPKRMOD” directory. The first four characters represent UBA for the sector containing module beginning in hex format and the four characters following a colon mean module length in hexadecimal notation. The respective column will show the position number. Please see Table 2 for relation between a position number and the purpose of module corresponding to it.

Writing of modules – command accomplishes recording of modules from the “MXDSPMOD” or

“MXPKRMOD” directory. Checksum is not recalculated during module recording because many modules are not protected with a checksum and some of them have a different algorithm of its calculation. The respective column will show the position number. Please see Table 2 for relation between a position number and the purpose of module corresponding to it.

Reading module groups and Writing module groups commands represent another variant of work with data

(6)

Technical support: eng_support @acelab.ru Files of module groups (*.smb) contain all the modules accessible for individual reading plus blank spaces. Those commands are not used in the methods, which we have developed for restoration of hard drives; however, there is a certain probability of malfunctions, which might require their use.

SA write test command loads adaptive data and determines correctness of recording to the firmware zone. The

command is implemented for additional drive initialization after loading of an LDR file. Usage of that command is described in section 7.

Modules repairing command allows restoration of modules with incorrect headers. Usage of that command is

described in section 7.

Translator regeneration command accomplishes creation of translator modules from the factory defects table

(module PN=33h). That command is described in detail in para. 7.3.

Spindle stop command switches a drive to the “sleep” mode. It is used during the Hot Swap procedure.

5.2.2.3. LDR-file loading

LDR-file loading command will offer to select an LDR file and output the following loading mode menu: Load ROM and modules

Load ROM

Load modules

Please see more detailed description of loading modes for LDR files in section 7.

5.2.2.4. LDR-file creation

Using the command with an operational drive you can create a loader file (LDR file) for the drive. The command will function properly only if the family of the connected drive has been selected correctly during utility launch. Otherwise creation of an LDR file will either cause an error or produce a file with incorrect data unable to load.

5.2.2.5. Security subsystem

The option brings up submenu with the following commands:

Review information command displays current condition of security subsystem and set passwords. Clear passwords command disables data protection.

5.2.3. Disc ID

The option serves for modification of model name and its serial number. These parameters are stored in the DISK module of the drive firmware (position number 1Fh).

5.2.4. Defects table

The Defects table command brings up the following menu:

View P-List

View G-List

Move G-List defects to P-List

Erase G-List

Erase P-List & G-List Import from Defectoscope

View P-List command reports defects hidden to P-List.

View G-List command reports defects hidden to G-List. The “LBA(def)” column of the report contains LBA

addresses of defective sectors. The “LBA(subst)” column contains LBA addresses of sectors used for substitution of defective sectors. The “Candidate” column contains flags of candidate defects. If the respective defect row shows “¥” in the "Candidate" column it means that the defect hasn't been actually relocated and the "LBA(subst)" sector for such defect will be the same as "LBA(def)". Complete G-List size is indicated in the «Capacity» line, it is different in various drive families. For example, ATHENA DSP drives have capacity for up to 636 defects.

(7)

Erase G-List command resets defects stored in G-List.

Erase P-List & G-List command clears all hidden defects in a drive and resets the information about the

number of relocated defects in the summary table of defects (module PN = 33h). If it is desirable to preserve the information about the defects previously relocated in the drive, you should create backup copies of modules PN = 37, 18, 78, 1B, 33.

Import from Defectoscope command allows addition of defects discovered by the Defectoscope software to

P-List or G-P-List.

5.2.5. SELF TEST mode

The SELF TEST command brings up the following menu: Start SelfScan

Stop SelfScan

View SelfScan state

Start SelfScan switches a drive to self-testing mode. Stop SelfScan stops self-testing.

View SelfScan state allows monitoring of self-testing progress. Drive's self-testing is discussed in more detail

in para. 8.3.

6. Firmware

6.1. General information

Firmware of Maxtor drives is subdivided into two parts. The first part of the microcode is stored in masked ROM inside the processor chip and in Flash ROM. The second part of a drive's firmware is recorded in the firmware zone. In Maxtor drives it is accessible through logical sectors specifically assigned for that purpose and called “UBA” (Util Block Addressing, somewhat similar to LBA), automatically converted by the microcode into respective physical location on disk surface.

PCB firmware consists of two portions: masked ROM in the processor and an external parallel or serial Flash ROM. Such a scheme has been implemented most likely because masked ROM inside the processor cannot be modified with sufficient ease. The processor is initialized from the external ROM. If it is missing, the firmware microcode will be started from ROM inside the processor. A situation is possible, when the microcode inside processor may belong to another drive family. E.g. CALIPSO drives with disconnected external ROM may be identified as N40P. Maxtor drives have a “safe mode” jumper. When it is enabled, only firmware stored on the PCB loads but the routine for starting motors and initialization of firmware portion on disk is skipped. You can identify precisely the version of PCB firmware. In order to do so enable the “safe mode” jumper and launch the corresponding utility. The “MODEL” line will show ROM version after the model name.

Drive initialization for an operational condition requires complete replacement of the PCB firmware with the firmware from the service area on disk. If for any reason the firmware cannot be launched from the service area, its loading to the drive processor can be forced by starting an LDR file. During the procedure keep in mind that an LDR file contains just microcode (ROM copy and overlays) but it does not contain the data necessary for drive operation (tables of defects, adaptive data and other settings). PCB microcode and firmware on disk have different versions. That difference helps to tell which version is currently being run by the processor. In Poker/Ardent drive families firmware area contains two programs for drive control: a regular version and a program for factory self test.

Identification of firmware version by labels is complicated with Maxtor drives because manufacturing factories do not observe strict version numbering rules, which fact leads to quite a lot of incompatible firmware versions with the same identification codes. Compatibility issues may be caused also by the adaptive parameters for the reading/writing magnetic heads stored in firmware microcode. However, despite the fact that compatibility cannot be 100% guaranteed, firmware version can be identified using the following guidelines:

1. Abbreviated values MODEL+HDA+PCBA+UNIQUE. E.g.: 2B020H1110511. 2. Identifying letters, through a comma. E.g.: K,M,B,E.

(8)

Technical support: eng_support @acelab.ru Modules map in Maxtor drives contains no names of modules, though some of them still do have names. Such names are stored in the header of a respective module. Therefore it is impossible to find out the name of a module without reading its contents. It is possible to introduce unified numbering of modules for various Maxtor drive families, i.e. the so-called position number (hereinafter PN), that allows convenient identification of specific modules' purpose. Purposes of the majority of active modules are described in the Table 2.

Copies of the firmware zone are provided for each magnetic head. It is also duplicated using "senior" UBA locations that are not included into the main map. By default firmware works with all copies since the drive is capable of operation in a mode using all copies. Reading and writing of module groups serves as a means of accessing a copy of firmware zone.

The report output by the “Check firmware structure” command (para. 5.2.2.2) contains the following information:

General information

The section displays selected drive family, minimum and maximum physical cylinders of user's data zone.

DISK configuration module

The module contains drive parameters: number of reading/writing heads and the map of their connections to the pre-amplifier/commutator chip.

Zone table

Physical location of density zones in a drive.

Data modules

The table with a report on data modules consists of: - data module number in “#” column;

- PN – position number of the module; - UBA address of module beginning; - module length;

- reading flag “Rd”, set to “¥” in case of successful reading or “-” if a module cannot be read;

- “ChkSum” flag set to “¥” in case of successful checksum calculation or “-” in case of calculation error;

- “Id” identification string, beginning with “*” character in case of module containing a table and a line identifying the table, it begins with “¥” in case of correct data module identification as well as the header read

from the module; if the header contains an error the line will begin with “-” followed by the header actually read from the module;

- comment that allows to determine the status of modules required for drive operation.

Loadable ROM

The report shows initial UBA, ROM version, identifier, reading status and checksum. Please note that reliable identification of ROM version is possible using checksum only. It is determined by the fact that the same version identifier in ROM corresponds to several different actual firmware versions. If checksums of ROM copies in different drives match, it means that the drives have the same microprogram.

Overlays

The table of report on overlays consists of:

- overlay number in “#” column (a drive has no 18h module); - UBA address of overlay beginning;

- reading flag “Rd”, set to “¥” in case of successful reading or “-” if a module cannot be read;

- “Id” identification flag set to “¥” in case of identifier match or “-” if the identifier does not match;

- “ChkSum” flag set to “¥” in case of successful checksum calculation or “-” in case of calculation error. G-List

The section reflects information on the G-List defects table status.

Passwords

(9)

6.2. Firmware modules

Table 2 contains a summary of data regarding firmware modules and their purpose. It combines position numbers of modules, module purposes and their necessity for drive operation.

Table 2. Position numbers correspondence. Position number

(PN), hex

Module purpose Importance

1E SRV – calibration adaptive data. A

21 RCT – adaptive information of data zone on surface. A

37 U_LIST – firmware zone translator. A

78 RZTBL – zone table. A

18 AT_PDL (P-List) – translator part responsible for P-List. A

1F DISK – drive ID. B

1B AT_POL (G-List) – growing defects table. B

39 ROM copy B

38 First part of microcode overlays B

4F Second part of microcode overlays B

95 Alternative DISK used in several Poker/Ardent drives. B 1D DMCS – translator part responsible for operations’ caching. C

2F S.M.A.R.T. thresholds. D

1A SECU – security system module (ATA passwords). D

30 S.M.A.R.T. attributes. D

70 S.M.A.R.T. Summary Log. D

71 S.M.A.R.T. Self-Test Log. D

63 Copy of S.M.A.R.T. attributes D

33 HUTIL & HUSR – pivot defects table. E

72 S.M.A.R.T. Host Vendor Log E

34 RAER_H00 E 64 MAXATG E 5E EVTLG_00 E 7B FWA E 11 MX_ST_CFG1 E 43 MX_ST_CFG2 E 0D MX_ST_CFG3 E 0E MX_ST_SCRIPT E

22 Various settings (flags) E

7A U_LIST – copy of firmware zone translator E

83 Information on drive parts. E

31 DISK – second drive ID copy E

14 STRS E

35 AT_XAL E

46 OPTI – self-testing settings. E

47 STRS E

48 Information on drive parts. E

Codes of the «Importance» column in Table 2:

A – essential and must have version corresponding to the specific head-and-disk assembly; B – yes, necessary, but can be replaced with one from another drive;

C – yes, necessary, but partial module corruption does not prevent drive from starting;

D – without one the drive starts normally but considerably slower than a totally operational drive; E – a drive is operational without such module.

One more mechanism is implemented in the utility for work with the firmware zone, i.e. reading or recording of groups of modules. A group of modules means modules or sectors combined according to a certain functional feature. For example, here belong modules containing microcontroller code (overlays) or data modules (translator, adaptive data and other tables). The said mechanism has the following differences compared to standard work with modules:

(10)

Technical support: eng_support @acelab.ru - it allows access to firmware zone areas that are not marked in the modules table;

- it allows access to firmware copy using another physical head (or the same head if there is only one present in a drive).

S.M.A.R.T. attributes can be cleared by recording the module with PN=30h from a drive with «good» S.M.A.R.T, using the “Writing of modules” command (para. 5.2.2.2.).

6.3. Translator in Maxtor drives

Translator is a program that translates physical sectors into logical ones used by an operating system. It is a general rule for all drives that factory defects are hidden by means of their exclusion from translation. Thus, for example, if we have a sequence of physical sectors P0,P1,P2,P3, where LBA of physical sector P0 is indicated as L0 and sector P2 is defective, then the sector coordinates will be recorded to the P_LIST in a location inside the zone specifically devoted to the sectors P0-P3 that we have chosen. The record is made not explicitly as Cyl, Head, Sec, but in a special notation instead. The counter of defective sectors in the RZTBL table for the zone including the selected P0-P3 sectors will grow by 1. As a result when an operating system accesses the group of sectors beginning with LBA0 the translator will show the said group as follows:

LBA0 – P0 LBA1 – P1 LBA2 – P3, etc.

Thus we see that sector P2 is excluded from the totality of LBA sectors available to the operating system. Now let us examine a case, when there is no record indicating that the P2 sector is hidden. It can happen in the following cases: recording of translator tables from another drive, HotSwap operation or erasure of defects' tables. The situation will cause sector P2 to appear among the LBA sectors visible for the operating system, but there's more to it! LBA2 used to be indicated as P3, but now it is shifted to P2! Consequently, all numbers of subsequent sectors will be shifted by 1. Thus at an attempt to read the sector located after the LBA2 address and containing a directory or a FAT table the operating system will read not the actual sector containing the directory, but the preceding one containing erroneous information.

The number of defects in an actual drive may come up to several thousands (or even tens of thousands) sectors. Therefore actual locations of files, directories and file system tables can be shifted from the expected values by several hundreds of sectors.

But let us get back to Maxtor. The translator program data are stored in the following modules: U_LIST (PN=37h), AT_PDL (PN=18h) and RZTBL (PN=78h). A drive forms the translator through an intermediate table with the PN=33h. The table contains defects in regular notation: cylinder, head, sector. There is an opportunity of compiling translator tables from that intermediate table using the “Translator regeneration” command. The utility does not show defects interpreting the translator directly but uses the table instead. Therefore if the translator modules get overwritten the utility will continue to show the same list of defects as before modification of the translator modules.

Relocation of defects to the G-List table is accomplished using another method. The G-List table does not exclude sectors from the LBA addressing space. Instead it replaces them using reserved sectors. The reserved space begins after the highest LBA of a drive. Then the above example will be represented as follows.

L0 – P0 L1 – P1

L2 – reserved sector L3 – P3, etc.

During the procedure no shift of LBA sectors occurs. Loss of information in the G-List table does not tell on data restoration in any way. Of course, a situation is possible when a sector hidden by a drive to the G-List could have contained information critical for functioning of the file system. However, such situation is unlikely and it is recommended to clear the G-List if it contains any hidden defects, during the process of damaged firmware zone restoration for data recovery.

7. Software restoration of Maxtor HDD

7.1. Diagnostics of firmware zone malfunctions

Incorrect information recorded to the firmware zone can lead to drive's malfunctions. It may also result from a problem with electronics or mechanical parts. Diagnostics of such problems is complicated by the fact that

(11)

malfunctions of electronics and firmware zone defects can be manifested by the same drive behaviour as incorrect information in the firmware zone modules.

Firmware zone malfunction may manifest itself as follows:

- The drive is identified correctly but it produces an error for each sector at an attempt to read from disk surface using LBA (similar situation is possible if a password is set).

- The drive is identified by its factory alias, for example, “Maxtor ATHENA”.

- The drive starts the motor, unparks the heads but does not report on readiness (hangs).

Practically in all of the above cases (except for CALIPSO drive family, see para. 10.9.) factory mode commands of the drive do not work. In order to switch the drive to a mode, in which factory commands can be started, you'll have to start it using an LDR file. That can be accomplished using two methods:

1. Drive start without setting the “safe mode” jumper.

That method will work if during the utility launch the drive is identified by its factory alias and the safe mode jumper is disabled. The essence of that method consists in loading just a part of LDR file modules. The modules at that must be exactly identical to the original ones in the drive. Step-by-step algorithm:

1. Switch on the power and start the pcmx_dsp.exe or pcmx_pkr.exe utility. 2. In the mode menu select the “LDR-file loading” option.

3. Load an LDR file in the “Modules loader” mode. If the loading procedure succeeds the drive will allow operations with the firmware zone.

One difference of that method compared to drive switching to safe mode is expressed in the fact that during start the drive is able to load the defects table and adaptive parameters from the firmware zone. Drive start in safe mode does not accomplish that. That method will not work if modules having "A" importance are corrupt (see Table 2).

2. Drive start using the “safe mode” jumper setting.

During utility launch in safe mode you'll see the drive's factory alias. The method is recommended in cases, when the drive "hangs during start" or does not start without the safe mode jumper.

1. Set the “safe mode” jumper (see PCB schemes in section 10).

2. Switch on the power and launch pcmx_dsp.exe or pcmx_pkr.exe utility.

3. If you work with a ROMULUS DSP or Poker hard drive run the “Initialization from SA” command (see para. 5.1.).

4. In the mode menu select the “LDR-file loading” option.

5. Load an LDR file in the “Load ROM and modules”. In case of successful loading the drive will spin up its motor and report on readiness.

6. In case of ROMULUS DSP hard drives sometimes you have to suppress the Reset signal during utility launch (see para. 5.1.).

7. Select the “Standard mode” from the mode menu. If during mode entry you see the «Error loading modules table!» message, it means that an unsuitable LDR file has been loaded, drive hanging has occurred while loading RAM copy or some problem with electronics/HDA has taken place.

After drive start with the help of an LDR file in order to determine the modules condition you should start the “Checking of disc FM structure” command (para. 5.2.2.2) and study the report contents carefully using the Table 2. If the report contains incorrect module headers, their restoration is described in para. 7.2.

Prior to modules repair you should make sure that sectors recording to the firmware area is performed correctly. In fact drive start using an LDR file firmware initialization is accomplished incompletely leading to errors in its operation. In order to verify recording correctness you should run the "Test firmware zone recording" command (para. 5.2.2.2). The test consists of two parts: loading of adaptive data from module PN=1Eh and testing of the drive’s ability to write to firmware zone by recording one sector with randomly selected contents to an unused portion of firmware zone called “swap1”. If the recording test succeeds the following message is displayed: «Record offset: 0», which means correctness of recording operations in the firmware zone.

Let us consider the problems which may arise during the test. If the module PN=1Eh is damaged the routine for loading the adaptive data will abort with an error, which definitely means impossibility of correct recording to the firmware zone. If a record offset occurs, operations over firmware are also impossible; that may be caused by drive malfunction during the adaptive data loading stage.

Warning! Save all modules from a drive prior to recording anything to it. That requirement is determined by unstable

drive behavior during recording to its firmware zone. It means that in case of problems with adaptive data one module can be written over another! That will lead to loss of firmware data, which will be unrecoverable, if the data hasn't been saved!

(12)

7.2. Automatic restoration of module headers

One quite frequent malfunction of Maxtor drives is manifested in data corruption in the firmware zone modules. They can become corrupt because of errors during reading/recording operations. Errors may be caused by lack of contact between motor/commutator, magnetic head malfunction, scratches on disk surface or, most often, interruptions in drive power supply. The symptoms in all these cases are the same indicating translator modules corruption.

Usually modules corruption is limited to an incorrect identification string, though checksum remains correct. In order to restore such a module (for example, P-List), it would be sufficient just to record the correct header and recalculate its checksum. The following modules may be damaged as described above: P-List (PN=18h)1, G-List (PN=1Bh), DMCS (PN=1Dh). If they are corrupt, their identification strings are replaced with the following: NO_PLIST, NO_GLIST, NO_DMCS. Similar corruption is possible for the module U_LIST00 (PN=37h), but it is very rare. If this module has correct header, its automatic recovery is not recommended.

Despite the fact that practically all the modules have copies, it is impossible to restore the original modules using their copies, since they are corrupt, too. Checksums of modules are practically always correct; though module contents may be damaged.

For the restoration of a module with damaged header the following command sequence is used: “Firmware data” – “Work with firmware zone” – “Restore modules” (para. 5.2.2.2). Then the name of damaged module is selected from: DMCS, U_LIST, AT_POL (G-List), AT_PDL (P-List) with subsequent pressing [Enter]. If a module is undamaged accidental selection of the command for its restoration will not affect its contents at all.

Warning! The “Restore modules” command just corrects module header and recalculates its checksum! Module

contents remains as it has been read from the drive being restored. If the data stored in the module is incorrect and the drive hangs during its loading, the "Modules repairing" command will produce no effect. That command also doesn't control recording, i.e. if a drive has recorded the module incorrectly or recorded it to another location, the restore operation will return no errors!

Warning! The “Restore modules” command records the module being restored to the firmware zone and a recording

failure may erase important data in the firmware zone. Therefore you should save the modules and create an LDR file prior to launching that command.

7.3. Translator restoration

The task of translator restoration appears when its tables contain incorrect data or unreadable sectors. In such situation it is possible to create translator tables on the basis of a pivot defects table (module PN=33h) provided it is intact.

Translator recalculation is started by the “Translator regeneration” command (para. 5.2.2.2.). The operation may take quite a long time. Everything depends upon the number of defects in the pivot table. The resulting translator will not contain the defects relocated in the service zone (therefore the operation is blocked when relocated defects are present in the firmware zone). All tracks hidden using RZTBL will also be transferred to AT_PDL; theoretically it may cause a discrepancy between the original and recalculated translator. We haven’t encountered such discrepancies in practice.

8. Surface testing of Maxtor drives

8.1. Surface testing of firmware zone

Firmware zone condition can be evaluated using the test provided in the utility: SA surface checking (please

see para. 5.2.2.2). Testing is performed in UBA notation. Discovered defective sectors are added to a report. Only areas

containing groups of modules are tested.

8.2. Logical scanning

(13)

The “Logical scanning” command starts drive surface test utilizing logical parameters (para. 5.2.1). Test parameters:

Initial LBA position: 0 Final LBA position: xxxxxxxx

Reversive scanning: No

Number of passes: 3 Perform writing test: No Verif. instead of reading: Yes

Put defects to: P-LIST

Initial and final LBA position parameters determine the test range.

Reversive scanning defines testing direction. Switching is performed using the [Y] key for "Yes" and [N] for

"No" or [Space]. A drive reads data ahead therefore direct scanning is somewhat faster than reverse.

Number of passes parameter determines the number of complete test passes from the initial to final LBA. Input

range is from 1 to 100.

Writing can be switched on in the Perform writing test and verification procedure can be replaced with reading. Testing quality in such case improves, but its duration increases, too. Switching writing on/off and substitution of reading instead of verification is done using [Y] key for "Yes" and [N] for "No" or [Space]. The surface test is based on an adaptive algorithm – detected defects are not addressed during subsequent passes. This procedure considerably decreases test duration for drives with a large number of defects. Please keep in mind that testing duration depends

heavily on the number of defective sectors in a drive: the greater their number is the longer the test will run!

Put defects to P-LIST or G-LIST. Switching is accomplished using the [Space] key.

Upon completion of the surface scanning procedure, the table of all discovered logical defects in LBA notation appears on the screen. Pressing [Enter] key converts all logical defects into physical ones and displays them on the screen; second pressing [Enter] appends all the defects to previous records in the defects table.

8.3. Relocation of defects

The utility allows hiding defects to the P-List factory defects table as well as to user's G-List table.

P-List defects table can be reviewed using the “View P-List” command (para. 5.2.4). Defects are output from the pivot defects table (PN=33h) and not restored from the respective translation tables. . It means that if the translation tables are overwritten with tables from another drive or modified otherwise, the "View P-List" command will still display the same list of defects as it used to prior to recording and the list will not correspond to the defects actually relocated in the drive. The same inconsistency is observed when module PN=33h is recorded by copying from another drive. However, if the utility tools are used for operations with the defects’ tables the pivot table of defects will be modified correctly.

Some Maxtor drives have relocated defects within the firmware zone. In that case resetting the tables of defects will be disabled because the utility does not provide for firmware zone recording taking into account the relocated defects.

G-List defects table can be reviewed using the “View G-List” command (para. 5.2.4).

Defects search is accomplished using the “Logical scanning” command of the utility or with the help of Defectoscope software (“Import from Defectoscope” command). Discovered defects can be transferred either to P-List or G-List at user's discretion.

Maxtor drives allow hiding of whole tracks as well as track parts, i.e. several successive sectors added together as one defect record saving the table space. Grouping of successive defects is performed by the drive automatically.

Maxtor drives automatically relocate defective sectors to G-List, and the “Defects table” - “Move G-List to

P-List” command sequence transfers those defective sectors to P-List, the procedure simultaneously clears G-List. The

operation is performed by the drive itself, the utility just issues the command, therefore if the transfer of defects ends in an error, it means that the defects stored in G-List cannot be added to P-List.

8.4. Drive self-testing

This version of the utility allows running factory self-testing routine in Maxtor DSP drives; the feature is not implemented for Poker and Ardent drive families yet. Upon self-testing a drive recalculates its adaptive parameters, hides defective sectors and resets S.M.A.R.T. attributes to factory defaults.

A drive is switched to self-testing mode by the Start SelfScan command (para. 5.2.5), whereupon, during subsequent power-on a 30 sec. pause will be made before the drive starts self-testing (drive LED will indicate the running procedure by blinking at 2Hz frequency). If during those 30 seconds you issue a reset or drive ID reading command, the drive will enter its operational mode until next power-off/on.

(14)

Technical support: eng_support @acelab.ru Drive LED will be blinking with varied frequency while performing the tests.

The utility can display progress of the self-testing procedure. To accomplish that you should issue the View

SelfScan state command (para. 5.2.5) for an already connected drive with on-going testing procedure. The window will

show current status: test number, cylinder, etc. Please note, that a connected drive does not respond to utility commands during on-going self-testing process, utility launch in that case may cause self-testing failure.

As a summary we can suggest two methods for indication of self-testing progress with monitoring of a drive connected or not connected to a PC and powered by an independent supply.

1. Procedure of drive start with status monitoring. - SELF TEST - Start SelfScan

- Without leaving the utility and with IDE cable connected to the drive, switch its power off and on. - Start View SelfScan state, then the self-testing progress report will be displayed on-screen.

2. Procedure of self-testing using an independent power supply without a connection to PC. - SELF TEST - Start SelfScan

- Disconnect the drive and connect it to an independent power supply unit.

- Since PCBs in Maxtor drives have no LEDs you can connect an external LED as shown in figure 1.

IDE Pin 39 390 Ohm

+ 5V

Fig. 1. Connection of external LED for monitoring the drive self-testing process.

We have observed different probability of successful self-testing completion with a prior resetting of the defects’ tables and without it. Therefore we advise to clear the tables of defects before running the test.

Successful completion of self-testing will be indicated by the drive LED blinking regularly at 1 Hz, failure and emergency exit from the testing procedure are indicated by much faster blinking – at approximately 10 Hz. Drive hanging during self-testing is manifested by absence of changes in its condition for a long (for example, half an hour) time and lack of LED indication. The LED in such case may be on or off, but it won't blink.

Warning! In some cases when self-testing terminates with a fatal error, firmware zone is considerably damaged

(modules essential for drive operation are missing), therefore you must always backup the firmware zone before beginning self-testing procedure.

Warning! Self-testing will not start correctly if a drive is started using an LDR file. Warning! All user data will be destroyed during the self-testing procedure.

9. Auxiliary utility files

The main pcmx_dsp.exeɢ pcmx_pkr.exe utility files of the complex are supplemented by auxiliary service

files. The names of those files coincide with utility name while their extension corresponds to the file type:

/utility’s name/.log – text file for the drive test results generated by the utility at the first program launch and appended with every subsequent drive test. The file contains all the settings and test results. Data on the automatic drive test performance is also written to this file;

/firmware version/.ldr – firmware update file.

/firmware version/.ram – file containing a copy of drive RAM.

Other file names are selected by user, but their extensions are determined by the utility depending on their types:

*.rpm – technological files of resident firmware modules in a drive. During the reading procedure they are copied to the directory “MXDSPMOD” or “MXPKRMOD, where first four characters represent UBA sector of module beginning in hex notation, while four following characters mean module length in sectors in hex notation.

*.smb – technological files of groups of resident firmware modules in a drive. During the reading procedure they are copied to the directory “MXDSPMOD” or “MXPKRMOD”, where first four characters represent UBA sector of module beginning in hex notation, while four following characters mean module length in sectors in hex notation.

(15)

10. Description of peculiarities in Maxtor drive families

Drive families are represented by their factory aliases. Though an alias is not printed (usually on HDA label) it can be checked quite easily by means of setting the safe mode jumper. If the jumper has been set correctly the drive will not spin up its disks and it will be identified as “Maxtor <alias>”, for example, “Maxtor N40P”. The string is formed by a ROM microprogram and output either in safe mode, or when an error occurs during firmware zone initialization. In some drive families aliases are marked on PCBs using serigraphy.

Safe Mode jumper location is shown in figures representing external view of drive electronics boards.

10.1. PROXIMA drive family

1. RDS035L03 2. 78L08A MAXTOR LUCENT 1181K MS353B3 Master 2 1 LUCENT Jumper Configuration Slave 1 Safe mode 1 1 1 1 3 1 1 2 1 1 1 1 4 3. 20 MHz 4. M29F102

Fig. 2. External view of controller board in MAXTOR PROXIMA drive family.

10.2. RIGEL drive family

The format of G-List table in that drive family is different from the usual. Therefore the information about defects displayed by the “View List” command will be not quite correct. However, defects will be appended to G-List correctly. Automatic restoration of the G-list module will also work correctly.

(16)

Technical support: eng_support @acelab.ru 1. RDS035L03 2. 20 MHz

DSP

MS453 Master 2 1 1 1 D741667APGF AGERE Jumper Configuration Slave 1 1 1 Safe mode 1 1 1 1 1 2

Fig. 3. External view of controller board in MAXTOR RIGEL drive family

10.3. NIKE drive family

1. B3185 2. 78L08A 3. M29F102BB 1

DSP

HY57V161610D Master Slave 2 1 1 1 1 1 2 SH6770C D741864CPGF LUCENT 3 Safe mode Jumper Configuration Slave 1 1 1 3 Safe mode

(17)

10.4. ATHENA DSP drive family

One quite frequent peculiarity of drives belonging to the family is demonstrated by their behaviour in case of P-List malfunctions, when after motor spin-up and removing the heads from parking area a drive turns the spindle motor off but "forgets" to park the heads. The problem can be identified by a typical sound heard when the motor is turned off. Such drives should be restored using the method of loading an LDR file in safe mode (see para. 7.1). Then you should perform diagnostics of problems in the firmware zone, save firmware modules and restore the drive translator (para. 11.2). 1. B3185 2. 78L08A 1

DSP

MS453 48LC1M16A1 Master Slave 2 1 1 1 1 1 2 SH6770C D741667APGF AGERE 3 Safe mode Jumper Configuration Slave 1 1 1 3 Safe mode 3. M29F102BB

Fig. 5. External view of control board in MAXTOR ATHENA ATA2-PLUS drive family.

Appendix 1 hereto contains a circuit diagram for connection of motor control chip in PCBs of ATHENA DSP drives.

(18)

10.5. ATHENA Poker drive family

1. B3185 2. 78L08A 1 POKER C6 HY57V 161610DTC-6 Master 2 1 1 1 1 1 2 SH6770C 040108200 4370J2 0224S 4849943 Jumper Configuration Slave 1 1 1 Safe mode 1

Fig. 6 External view of controller board in MAXTOR ATHENA Poker-based drive family.

10.6. ROMULUS DSP/Poker drive family

Malfunction of one of the heads in drives belonging to that family causes knocking sounds while loading an LDR file or during calibration at utility launch.

1. RDS035L03 2. A172E

DSP

MS453 Master 2 1 1 1 ₂ D741667DPGF AGERE Jumper Configuration Slave 1 1 1 Safe mode 1 1 1 1 1 3 3. 20 MHz

(19)

10.7. VULCAN drive family

1. PHN210T 2. PHN207 3. A171B 040405000 D741667CPGF CC-15AE72W MS453 Master 2 2 AGERE Jumper Configuration

Slave Safe mode

1 1 1 1 4 1 1 3 1 1 5 5. M29F102BB

Fig. 8. External view of controller board in MAXTOR VULCAN drive family.

10.8. ARES 64K drive family

"L" letter in model name indicates that a fluid dynamic bearing was used, for example, 2F040L0. "J" letter means that a ball bearing was used, for example, 2F040J0.

With that drive family Maxtor designers began to use two firmware zones with similar structure but totally different purposes. The main firmware zone is used during normal drive operation. It contains all the modules with correct data required for drive operation.

Table of correspondence between starting modes and firmware versions in ARES 64K drives. User mode of operation ROM loader mode Self Test mode

(20)

Technical support: eng_support @acelab.ru 1. B3185 2. 78L08A 1 Poker HY57V161610D Master Slave 2 1 1 1 1 1 2 SH6770C 040111600 LUCENT 3 Safe mode Jumper Configuration Slave 1 1 1 3 Safe mode 3. M29F102BB

Fig. 9. External view of controller board in MAXTOR ARES 64K drive family.

10.9. N40P drive family

In this drive family ST25P10V6 external Flash ROM with serial access is used.

Quite numerous existing ROM versions complicate the issue of their compatibility making it difficult to pick a matching board. ROM chip can be soldered to a new board since it does not have too many pins so the procedure can be performed fairly quickly. Such variety of versions results from the fact that program microcode, namely, overlay 6 and ROM chip on PCB contain built-in adaptive parameters for the reading/writing heads. When modified heads are installed during the manufacturing process, the whole firmware version has to be changed. That produces numerous versions and as a result the microcode in the masked ROM of the drive processor ceases to match those versions. Consequently it has to be supplemented with external ROM containing the necessary modifications to the adaptive data and firmware version. That situation also influences drive starting with the help of an LDR file. The utility may start a drive using another firmware version, but the adaptive data of that version may not match the drive. Usually it is practically impossible to read the firmware if the adaptive data built-in into the microcode does not match the drive, although running a loader file with suitable adaptive data makes everything work fine. Compatibility of adaptive data can be controlled using the ROM version on PCB output by the drive in “safe mode”.

This family is characterized by peculiar P-List corruption. Besides the header one or several sectors of P-List become BAD. After header restoration and recalculation of checksum the drive is still unable to start and, moreover, it is impossible to make it record anything else to its firmware zone.

(21)

1. ST25P10V6 2. SH6782B 3. FDS9431A 2125G W981616BH-6 Master Slave 2 1 2 Ardent C5-C1 040110100 ARDENT-C5C1 -790UK 023S 4963143 Safe mode Jumper Configuration 1 3

Fig. 10. External view of controller board in MAXTOR N40P drive family.

10.10. FALCON drive family

1. 2 2. DPFS20V FDS9431A MAXTOR LUCENT 1181K MS353B3 Master 2 LUCENT Jumper Configuration

Slave Safe mode

4 2 1 1 3. M29F102BB 4. 20 MHz 3

(22)

10.11. CALIPSO drive family

Just like in N40P drive family here external Flash ROM with serial access is used.

For this family a specific malfunction is typical, when one of magnetic heads goes out of order. As a result such drive is identified as Maxtor CALIPSO, but allows reading/writing of firmware zone without an LDR file and all the modules remain intact. The said effect is caused by the fact that during start the drive does not find one of the heads included into its table. Therefore the firmware zone mapped for a different number of heads cannot be correctly processed by the drive control microcode. Such drives produce slight knocking sound if a calibration command is issued!

The following problem is possible with drives from that family: incorrect recording during an attempt to restore a module will erase some modules having A or B importance. Consequently the drive’s firmware during the next start will be unable to load the essential modules from the main firmware zone and it will have to switch to the alternative zone. Therefore the modules prove to be intact after restart, but those are in fact absolutely different modules. That condition cannot be repaired using the current version of the utility.

The “safe mode” jumper position is yet unknown for the Serial ATA modification of CALIPSO drive family. That family uses two formats of the G-List table of defects. The utility cannot recognize table format automatically and thus it is set up for the newest format. The older format will be displayed incorrectly. In order to view G-List in the older format you should enter the utility having selected, for example, N40P.

1. 2 2. DPFS20V RDS035L03 MAXTOR LUCENT 1181K MS353B3 Master 2 LUCENT Jumper Configuration

Slave Safe mode

4 2 3 1 1 3. 25P10V6 4. 20 MHz

(23)

11. Data restoration

11.1. Diagnostics during data restoration

The task of data recovery from a Maxtor drive requires, first of all, precise diagnostics of malfunction, preferably without HDA disassembly; with simultaneous minimizing of further damage to the drive or data loss. Malfunctions, just like methods of diagnostics can be subdivided as follows:

- PCB malfunction. - Motor/bearing failure. - Parking element failure. - Reading/writing heads failure. - Heads failure and surface scratch. - BAD sectors.

- Complete or partial loss of firmware data.

When the scope of problems is identified it is time to begin diagnostics. What of the above has happened? In the first turn keep in mind that damage to the firmware zone in Maxtor drives is usually not independent. It frequently results from constant (appearance of numerous BAD sectors) or short-term malfunctions of the mechanical (bearing, etc.) or electronic components (pre-amplifier, heads, motor control circuit, etc.).

Step 1. Let us begin with the electronics board. In order to make sure that the board is operational it is sufficient to connect it to another drive with the same firmware version and check, whether the drive works flawlessly with the board. That method is not complicated for Maxtor drives since the board contains no adaptive data and its start in another drive requires just firmware version match. Please see section 6 for details on firmware version.

Step 2. If the problem is not caused by electronics then motor diagnostics should be performed. If the motor does not spin up though the board is operational the cause is either damaged motor winding or heads sticking to disk surface. However, in Maxtor drives the situation of motor malfunction caused by stuck heads does not occur probably due to quite powerful motor or insignificant heads sticking. One more cause preventing rotation is seizure of a fluid dynamic bearing. Seizure practically does not occur in drives using ball bearings in spindle, but another problem appears, namely motor operation with obviously high noise level. That is caused by considerably greater disk beating. One more motor problem may be related to bad contact or cable break in the connector between the electronics board and HDA. As a result motor problems can be identified by the following signs:

- Winding closure or break.

- Seizure of fluid dynamic bearing (FDB). - Motor operation with considerable noise level.

- Problem with connection between the motor and electronics board. - Problems with voice coil glue quality.

Step 3. If a drive with operational electronics having no obvious problems in motor functioning does not knock heads or produce slight knocking at attempted calibration we should proceed to the following step. Now we should start diagnostics of surface scratch. It is difficult to perform the diagnostics completely without drive disassembly, but through the STW lifter opening one can see up to 90% of the surface from the PCB side. In drive families containing just one head the opening shows the work surface. A scratch having appeared on one of the surfaces will very quickly spread to all the rest. If a significant scratch is present, it would be sufficient to identify it without disassembling the HDA.

Step 4. If the diagnostics procedure proves operable condition of the motor, control board, absence of scratches, and the drive unparks its heads without knocking, the cause of malfunction is either in heads damage or their incorrect functioning (and inability to read firmware zone as a result), or in the presence of BAD sectors or in corrupt firmware data. That is the hardest issue for identification because several malfunctions have the same signs.

Let us set the safe mode jumper. The jumper position is shown in section 10 for each drive family. Then you should load from the menu shown at utility launch any LDR file corresponding to the family of the connected drive. Appearance of knocking sound at loader roll-in will indicate heads malfunction. If the loader roll into memory is not followed by knocking, but an error reading modules table occurs at entering the standard mode, it means that the loader version does not match the ROM contents and you should select such an LDR file, which would allow reading the modules table.

(24)

11.2. Solution to the translator problem for data recovery

In very rare cases a drive may not start or it may hang at power-up when its G-List contains incorrect information under a correct header and valid checksum. You can view the G-List with an LDR file loaded. An attempt to reset (the record to the firmware zone should be correct) G-List in that mode will not achieve a proper result as the replacement LBA will be defined as –1. Recording a clear G-List copied from another drive of that family with the same capacity represents a more accurate method.

There is a rather frequent situation when translator modules have correct headers and checksums and all other essential modules are in order, but the drive still does not function using its logical parameters. At present two reasons for such condition are known:

The first and quite rare cause occurs in CALIPSO drives when one of drive heads gets physically disconnected – the drive translator refuses to load. That happens because the RZTBL (PN=78h) module contains the number of heads. Diagnostics of that malfunction is described in more detail in para. 10.11.

The second variant of that situation is encountered practically in all Maxtor drives supported by the PC-3000 complex. It results from occasional recording of random or pseudo-random data to the translator table fields (data from one module can be recorded to another). Module headers and checksums at that may remain correct. Automatic restoration of modules in such a situation will not help restore the drive.

In order to perform diagnostics in that situation you should record to the malfunctioning drive translator modules (PN=37h, PN=18h and PN=78h) copied from an operational drive with the same capacity. Prior to the operation save all modules from firmware zone, especially module 33 and ensure that the firmware zone has no relocated defects. The suggested method of diagnostics is not applicable if the firmware zone contains hidden defects. If after recording of the translator modules the drive starts normally and can be accessed using its logical parameters, it means that the problem resulted exactly from invalid data in the modules.

If the module PN=33 is intact (the utility will output a list of defects upon P-List query) you can perform the “Translator recalculation” procedure (see para. 5.2.2.2 and para. 7.3).

(25)

A A vr200 Q501 78L08A C102 J4 RADIX 1 2 J2 REGULATOR 8V REGULATOR 3.3V IRF7101 (W241) SPINDLE MOTOR CT A B C C506 (BSP 100)

MAXTOR ATHENA ATA2-PLUS motors controller Title

Size Document Number Rev

5V 12V 2 4 5 1 3 VCM- VCM+ MOTB CT MOTC MOTA 3.3V 3.3V 12V 8V SPSNS C1 + 33mkFx 16V u504B 3 4 6 5 u503B 3 4 6 5 C01 C2 u502A 1 2 8 7 R520 WDN R207 u501A 1 2 8 7 1 2 8 7 U500 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 $PIN0 $PIN1 $PIN2 $PIN3 $PIN4 $PIN5 $PIN6 $PIN7 $PIN8 $PIN9 $PIN10 $PIN11 $PIN12 $PIN13 $PIN14 $PIN15 $PIN16 $PIN17 $PIN18 $PIN19 $PIN20 $PIN21 $PIN22 $PIN23 $PIN24 $PIN25 $PIN26 $PIN27 $PIN28 $PIN29 $PIN30 $PIN31 $PIN32 $PIN33 $PIN34 $PIN35 $PIN36 $PIN37 $PIN38 $PIN39 $PIN40 $PIN41 $PIN42 $PIN43 $PIN44 $PIN45 $PIN46 $PIN47 R515 R305 C203 R3 R513 C512 u504A 1 2 8 7 u505A 1 2 8 7 L1

VOICE COIL MOTOR

u503A 1 2 8 7 R517 C10 u502B 3 4 6 5 C6 u506A 1 2 8 7 R2 u505B 3 4 6 5 R503 u501B 3 4 6 5 IRFD110 2 1 3 R518 +_{15 mkFx 25V} C5 1 8 2 3 6 7 OUT IN COM COM COM COM C3 3 4 6 5 R519 u302 (48) DSP (121) DSP (123) U302(25) DSP (148) DSP (57) DSP (98) DSP (103) DSP (119) J2(9)

(26)

A A A MOT C MOT B MOT A CT 25P10V6 6 5 1 7 4 2 3 8 SPINDLE MOTOR Q500 SMOOTH L7250E 1.0 S500 Q501 U401 Q400 200 Plug to HDA (Preamplefier) 1Om 1Om 1Om 1Om 1Om 1Om 1Om 1Om 1Om 1Om 1Om Voice Coil Motor Control Line

Port for Diagnostic -5V

REGULATOR +3.3V Shock Sensor 3 2 1 2 Q501 6 7 1 Q500 3 8 4 5 2 4 1 7 2 3 8 6 5 4 1 7 2 3 8 6 5 REGULATOR +1.7V Converter DC-DC -5V Control Line IR230M +1.7V +1.7V +3.3V

ACE Lab. PC-3000 Documentation 1 Maxtor Diamond Max Plus 9 CALYPSO

B

1 1

Friday, January 23, 2004 Title

Size Document Number Rev

Date: Sheet of +12V FCOMM +12V +3.3V +3.3V +3.3V +12V +12V c +5V +5V -5V +5V KT VCMI +3.3V KT C C C C C C505 R 8.2k R 2k R513 R C508 C401 R C 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 C Q400 5,6,7,8 4 1,2,3 C C R512 C R C C C C209 R C C C R511 R C511 C C C C C C506 R504 C C R516 C C514 C R229 C R510 C C C C519 L500 C C C R C507 C C C C R231 R508 C C C 2 3 1 R519 C501 R C210 C BUX C C513 R230 R R06 R 1K C U401 1 2 3 4 8 7 6 5 S Q W GND Vcc HOLD C D Ardent (8) Ardent (130) Ardent (170) Ardent (128) Ardent (138) Ardent (4) Ardent (212) VCM-VCM+ Ardent (5) Ardent (211) J1 (41) Ardent (12) Ardent (44) Ardent (27) Ardent (79) Ardent (71) Ardent (89) Ardent (114) Ardent (126) Ardent (154) Ardent (150) Ardent (157) Ardent (184) Ardent (190) Ardent (203) Ardent (87) Ardent (67) Ardent (29) Ardent (26) Ardent (58) Ardent (166) Ardent (102) Ardent (171) Ardent (144) Ardent (174) Ardent (206) Ardent (145) Ardent (137) Ardent (155) Ardent (7)

(27)

IBM

22GXP, 34GXP, 37GP, 40GV, 75GXP, 60GXP, 120GXP

1. Structure of drive families...2 2. Utility command menu...2 2.1. Launching the utility ...2 2.2. Utility usage ...3 2.2.1. Servo test, surface scanning ...3 2.2.2. Firmware data ...3 2.2.2.1. Work with memory ...4 2.2.2.2. Work with firmware zone ...4 2.2.2.3. “Modify configuration” command ...7 2.2.2.4. “Run an LDR file” command...8 2.2.2.5. Translator recalculation...8 2.2.2.6. Spindle stop...8 2.2.2.7. Enable write cache ...8 2.2.3. Drive ID ...9 2.2.4. Formatting...9 2.2.5. Logical scanning ...9 2.2.6. S.M.A.R.T. table ...9 2.2.7. Defects table...10 2.2.8. Automatic mode ...10 2.2.9. SELFSCAN...10 3. Drive firmware...12 3.1. Structure of IBM HDD firmware...12 3.2. Compatibility of electronics printed circuit boards...13 3.3. Description of structure and methods of firmware zone access in case of malfunctions...13 3.4. Critical modules for drive data...16 4. Description of IBM drive families ...17 4.1. Construction peculiarities of 22GXP(DJNA7), 34GXP(DPTA7), and 37GP(DPTA5) drive families ...17 4.2. Construction peculiarities of 40GV(DTLA5), 75GXP(DTLA7), 60GXP(AVER), and 120GXP(AVVA) drive families...18 4.3. Software repair...20 4.3.1. Identification and relocation of defects in user's area ...20 4.3.2. Malfunctions of “Open modules' table cannot be read!” type ...20 4.4. Peculiarities of software restoration...21 5. Auxiliary utility files for IBM drives ...21 6. Malfunctions of electronics boards in IBM drives...22 7. Electric circuit diagram...22 7.1. Elements layout...22 7.2. Electric circuit ...23

(28)

Technical support: [email protected]

1. Structure of drive families

Table 1. Family,

Utility.

Model Capacity, Gb

Disks Heads Physical cylinders Sect. / track Maximum LBA 22GXP1_, pcibmdjn.exe, ver. 1.15 DJNA-372200 DJNA-371800 DJNA-371350 DJNA-370910 22.60 18.04 13.57 9.11 5 4 3 2 10 8 6 4 15400 15400 15400 15400 351-214 351-214 351-214 351-214 44,150,400 35,239,680 26,520,480 17,803,440 34GXP1, pcibmdpt.exe, ver. 1.15 DPTA-373420 DPTA-372730 DPTA-372050 DPTA-371360 34.21 27.37 20.52 13.67 5 4 3 2 10 8 6 4 17493 17493 17493 17493 450-270 450-270 450-270 450-270 66,835,440 53,464,320 40,088,160 26,712,000 37GP, pcibmdpt.exe, ver. 1.15 DPTA-353750 DPTA-353000 DPTA-352250 DPTA-351500 37.50 30.00 22.52 15.02 5 4 3 2 10 8 6 4 17687 17687 17687 17687 522-280 522-280 522-280 522-280 73,261,440 58,600,080 43,985,088 29,336,832 40GV, pcibmdtl.exe, ver. 1.15 DTLA-305040 DTLA-305030 DTLA-305020 DTLA-305010 41.17 30.73 20.57 10.27 2 2 1 1 4 3 2 1 34326 34326 34326 34326 792-370 792-370 792-370 792-370 80,418,240 60,036,480 40,188,960 20,074,320 75GXP1, pcibmdtl.exe, ver. 1.15 DTLA-307075 DTLA-307060 DTLA-307045 DTLA-307030 DTLA-307020 DTLA-307015 76.86 61.49 46.11 30.73 20.57 15.36 5 4 3 2 2 1 10 8 6 4 3 2 27724 27724 27724 27724 27724 27724 702-351 702-351 702-351 702-351 702-351 702-351 150,136,560 120,103,200 90,069,840 60,036,480 40,188,960 30,003,120 60GXP1, pcibmavr.exe, ver. 1.15 IC35L060AVER07 IC35L040AVER07 IC35L030AVER07 IC35L020AVER07 IC35L010AVER07 61.49 41.17 30.73 20.57 10.27 3 2 2 1 1 6 4 3 2 1 33946 33946 33946 33946 33946 780-373 780-373 780-373 780-373 780-373 120,103,200 80,418,240 60,036,480 40,188,960 20,074,320 120GXP1, pcibmava.exe, ver. 1.15 IC35L120AVVA07 IC35L100AVVA07 IC35L080AVVA07 IC35L060AVVA07 IC35L040AVVA07 IC35L020AVVA07 123.52 102.93 82.34 61.49 41.17 20.57 3 3 2 2 1 1 6 5 4 3 2 1 55443 55443 55443 55443 55443 55443 928-448 928-448 928-448 928-448 928-448 928-448 241,254,720 201,045,600 160,836,480 120,103,200 80,418,240 40,188,960

2. Utility command menu

2.1. Launching the utility

At the start the utility offers the choice between two available initialization modes: “Standard” and “By Default”. When started in the standard mode the utility reads certain parameters from the drive and initializes its internal structures accordingly. A launch in the default mode forces the utility to act as though the drive does not respond to its queries; however, the utility skips the delay allocated for awaiting response. Actually it does not access the drive in that mode. That may be useful in cases of damaged drive’s firmware, when a drive does not respond to access attempts or fails beginning to knock.

Let us review the “Standard” mode of utility launch in detail (the “By Default” launch respectively will be accompanied by all the error messages mentioned below and pertaining to collection of information about the drive).

PC3000

"MAXTOR: D536DX, D541X, Diamond Max VL40, D540-4D,

D531X, Diamond Max Plus 60, D541X, Fireball 3, Diamond Max

Plus 8, Diamond Max Plus 16, Diamond Max Plus 9"

Contents

1. Purpose

2. Structure of drive families

3. Basic options for repair of Maxtor drives

4. Preparation for work

5. Utility usage

5.1. Launching the utility

5.2. Utility menu structure

5.2.1. Logical scanning

5.2.2. Disc firmware zone

5.2.2.1. Work with memory buffer

5.2.2.2. Work with SA

5.2.2.3. LDR-file loading

5.2.2.4. LDR-file creation

5.2.2.5. Security subsystem

5.2.3. Disc ID

5.2.4. Defects table

5.2.5. SELF TEST mode

6. Firmware

6.1. General information

6.2. Firmware modules

6.3. Translator in Maxtor drives

7. Software restoration of Maxtor HDD

7.1. Diagnostics of firmware zone malfunctions

7.2. Automatic restoration of module headers

7.3. Translator restoration

8. Surface testing of Maxtor drives

8.1. Surface testing of firmware zone

8.2. Logical scanning

8.3. Relocation of defects

8.4. Drive self-testing

9. Auxiliary utility files

10. Description of peculiarities in Maxtor drive families

10.1. PROXIMA drive family

10.2. RIGEL drive family

DSP

10.3. NIKE drive family

DSP

10.4. ATHENA DSP drive family

DSP

10.5. ATHENA Poker drive family

10.6. ROMULUS DSP/Poker drive family

DSP

10.7. VULCAN drive family

10.8. ARES 64K drive family

10.9. N40P drive family

10.10. FALCON drive family

10.11. CALIPSO drive family

11. Data restoration

11.1. Diagnostics during data restoration

11.2. Solution to the translator problem for data recovery

IBM

22GXP, 34GXP, 37GP, 40GV, 75GXP, 60GXP, 120GXP

Contents

1. Structure of drive families

2. Utility command menu

2.1. Launching the utility