Method and Apparatus for Replacing Resident Peripheral Device Control Microcode by Download via an Application Program

The present invention relates to a method and apparatus for replacing the control microcode in a peripheral device by download via an application program executed on the computer system to which the peripheral device is coupled.

Computer systems generally have coupled to them peripheral devices which provide either information storage or the capability to interact with users through input/output (I/O) devices. As these peripheral devices have become more complicated, they have had special processors installed in them, called resident processors in the remainder of this application. These resident processors execute programs, called microcode in the remainder of this application, which are generally stored in a non-volatile memory in the peripheral device. One example of such a peripheral device is a magnetic disk drive, providing information storage for the computer system. Other examples of peripheral devices which often include resident processors are tape drives, optical disk drives, CDROM drives, sound and video I/O adapters, etc.

In order to upgrade performance of, or provide new features for, such peripheral devices, the control microcode may be updated via a download of new control microcode from the computer system to which the peripheral device is attached. This has generally required that the computer system send a special peripheral control command (e.g. in a SCSI disk drive, a write buffer command) to the peripheral device. However, operating systems executing on the computer system generally control all access to attached peripheral devices, allowing access only through correctly called operating system routines, and denying all other access. To update the peripheral device control microcode in a computer system running such an operating system, a special operating system routine is required. However operating systems do not in general include such routines, and such routines, if they are supplied, are generally available only for disk drives which were manufactured or provided by the manufacturer of the computer system. However, peripheral devices, in general, are supplied by manufacturers other than the manufacturer of the computer system.

Alternatively, the operating system may be shut down, and a standalone program run on the computer system which can directly access the peripheral device. However, this requires that the computer system to which the peripheral device is attached be shut down. This makes the computer system unavailable for use during the time necessary to shut down the operating system, update the control microcode in the attached peripheral device, and restart the operating system. This sequence can take a substantial amount of time, (up to several hours) during which time users may not use the computer system. For a computer system to be unavailable to users for this amount of time is generally unacceptable to the users. In addition, it may be necessary for a service engineer to be dispatched to the site of the computer system to perform the update of the resident microcode of the peripheral device while the computer system is shut down. Furthermore, the service engineer may require special equipment to perform this update. It is desirable to be able to update the resident control microcode in a peripheral device, without requiring a special operating system routine, requiring that the computer system be taken out of service or requiring a service engineer be dispatched to the computer system site with special equipment.

Application programs, those programs run by users under the control of the operating system, are permitted access to peripheral devices to exchange data with the peripheral devices. The operating system provides operating system routines, legitimately accessible to an application program, for providing such access. In response to a call by an application program to such an operating system routine, the operating system will send a specific peripheral device control command, or sequence of such commands, to the peripheral device to perform the requested access. For example, in response to a call to an operating system routine to write designated data to a designated logical block (or sequential logical blocks) on a SCSI disk drive, a write-verify disk drive control command would be generated by the computer system and transmitted to the attached disk drive in a known SCSI format. The write-verify command includes: a command portion identifying this command as a write-verify command, a first data portion representing the starting logical block on the disk drive into which data is to be written, and a second data portion representing the designated write data; In response to this command, the disk drive writes the designated write data to the designated logical block(s) on the disk drive, then immediately afterwards reads the data from the same logical block(s) and compares it to the write data to ensure that the data was written accurately.

In accordance with principles of the present invention, a peripheral device capable of replacing resident control microcode with new microcode by download by an application program includes a non-volatile memory containing the resident microcode. Further circuitry is responsive to the application program for receiving peripheral device commands. A resident processor, which is coupled to the non-volatile memory and the receiving circuitry, is responsive to the resident microcode, and includes a detector for a received initiator peripheral device command. When an initiator command is detected, a waiting state is entered in which the peripheral device is held ready to receive new microcode. The resident processor also includes a detector for a transfer peripheral device command, which includes the new microcode, received while the peripheral device is in the waiting state. Further circuitry is coupled to the non-volatile memory and is responsive to the resident processor, for transferring the new microcode from the receiving circuitry into the non-volatile memory and restarting the operation of the peripheral device when a transfer peripheral device command is detected.

In accordance with another aspect of the present invention, a method for operating such a peripheral device to replace resident microcode with new microcode by download comprises the following steps. First, the peripheral device responds to the receipt of an initiator command by entering a waiting state ready to receive new microcode. Then, if the peripheral device is in the waiting state, it responds to a transfer command, which includes the new microcode, by replacing the resident microcode with the new microcode and restarting the operation of the peripheral device.

In accordance with another aspect of the present invention, an application program for replacing resident microcode in such a peripheral device with new microcode by download comprises the following steps. First, a request is made to send an initiator command to the peripheral device. Then, a request is made to send a transfer command, including the new microcode, to the peripheral device.

Peripheral devices according to the present invention may have their resident microcode updated by any operator of the computer system to which they are attached, simply by running an appropriate application program, regardless of who the manufacturers of the computer system and the peripheral device are, because no special operating system routine is necessary. In addition, this method is simple and effective, and does not require either special equipment, or that the computer system be shut down for extended periods of time, either of which is costly.

In the drawing:

FIG. 1 is a block diagram illustrating a computer system including a disk drive in accordance with the present invention;

FIG. 2 is a diagram illustrating a SCSI disk control command useful in understanding the operation of the system of FIG. 1;

FIG. 3 is a flow diagram illustrating the operation of the resident processor in the disk drive of FIG. 1;

FIG. 4 is a diagram, partially in block form, and partially in functional block form, useful in understanding the operation of the resident processor in the disk drive in FIG. 1;

FIG. 5 is a flow diagram illustrating the operation of an application program which may be used to transfer new microcode to a disk drive according to the present invention, as illustrated in FIG. 1.

In the following detailed description, a computer system coupled to a peripheral device in the form of a magnetic disk drive will be used to illustrate the principles of the present invention. It should be understood that any peripheral device similar to the illustrated disk drive may include, and be operated according to, the present invention.

FIG. 1 is a block diagram illustrating a computer system including a disk drive 10 in accordance with the present invention. In FIG. 1, a host processor 20 (which may include a central processor unit, memory and control circuits, not shown) is coupled to a user interface 30 and a SCSI interface adapter 40 via a computer system bus 50 in a known manner. The user interface 30 couples a plurality of user terminals 32 to the system bus 50 in a known manner. The SCSI interface adapter 40 couples the system bus 50 to a SCSI bus 60, also in a known manner. The computer system illustrated in FIG. 1 may include other elements, such as other input/output devices, network interface adapters and/or communications devices such as modems (none of which are shown) all coupled to the system bus 50 in a known manner.

In the illustrated embodiment, the disk drive 10 may be any of model numbers ST3620N, ST31200N, ST12400N, ST32550N or ST35500N magnetic disk drives, all manufactured by Seagate Technologies, Inc. The disk drive 10 includes a SCSI bus interface circuit 102 which couples the SCSI bus 60 to a disk drive internal bus 104. Within the disk drive 10, a resident processor 106 is coupled to a non-volatile memory 108, into which the control microcode is written, and a resident read/write memory (RAM) 110 via the internal bus 104 in a known manner. In the illustrated embodiment, the resident processor is a model 80C196, manufactured by Intel Corporation. The resident bus 104 is also coupled to an electromechanical magnetic disk drive storage mechanism, through a drive controller 112. The electromechanical disk drive storage mechanism includes a plurality of magnetic storage platters 114 spun by a motor (not shown) coupled to a motor control output terminal M of the drive controller 112. A corresponding plurality of read/write heads 116 are coupled to a data input/output terminal D of the drive controller 112, and a head locator mechanism 118 is coupled to a head control output terminal H of the drive controller 112, all of which operate in a known manner.

In operation, the host processor 20 executes programs, such as operating systems and application programs which access the disk drive 10 via the SCSI interface adapter 40 and communicate with user terminals 32 via the user interface 30 in a known manner. Application programs may request access to the disk drive 10 to read data from, or write data to, the disk drive 10 via respective calls to appropriate operating system routines. In response to such requests, the respective operating system routines executing on the host processor 20 control the SCSI interface 40 to generate an appropriate disk drive control command (or sequence of commands), and transmit that disk drive control command to the SCSI bus 60, all in a known manner. Each such disk control command contains a command portion to identify the desired action, and an optional data portion, or several such portions, each containing information such as a logical block on the disk drive platters for the data, and data to be written to the disk drive.

The bus interface circuit 102 of disk drive 10 recognizes a disk control command on the SCSI bus 60, transfers the complete command from the SCSI bus 60 to a buffer in the resident RAM 110, and informs the resident processor 106 that it has received a command. The resident processor 106, under the control of the control microcode stored in the non-volatile memory 108, retrieves the disk drive command stored in the resident RAM 110, controls the electromechanical disk drive mechanism via the drive controller 112 to properly execute the command, and, if necessary, composes a response in the resident RAM 110. For example, in response to a read request, the response contains the requested data. When the command is completed, the resident processor 106 controls the bus interface 102 to return the response in the resident RAM 110 to the SCSI interface 40 via the SCSI bus 60. The SCSI interface 40 receives the response, and transfers it to the memory (not shown) in the host processor 20 for further processing. The operating system routine executing on the host processor 20 processes the received response and prepares an appropriate response to the application program which requested the disk access.

For example, if the requested access is a request to write data to the disk drive 10, the application program requests that a buffer be allocated to it in the memory (not shown) of the host processor 20, fills the allocated buffer with the data it is desired to write to the disk drive 10, then calls a disk write operating system routine passing to it the location of the buffer in the host processor memory, and a logical block on the disk drive at which it is desired to store the data. The disk write operating system routine controls the SCSI interface 40 to send a write-verify SCSI disk control command to the disk drive 10, via the SCSI bus 60. This command includes a command portion, identifying the disk control command as a write-verify command; a first data portion, identifying the logical block, or the first of consecutive sequential logical blocks, on the disk drive platters 114, which is to receive the data; and a second data portion, containing the data to be written. The SCSI interface 40 compiles and transmits a command packet containing, among other things, the command portion (write-verify command) and first data portion (logical block) of the disk control command over the SCSI bus 60. Then, e.g. using known DMA techniques, the SCSI interface 40 transmits successive data packets containing the write data from the allocated buffer in the host processor memory, over the system bus 50, to the SCSI bus 60 as the second data portion.

FIG. 2 is a diagram illustrating a portion of a known SCSI disk control command useful in understanding the operation of the system of FIG. 1. In FIG. 2, a command packet (CMD PKT), containing ten bytes, and a single following data packet (DATA PKT), containing 520 bytes is illustrated. Each byte is illustrated as a horizontal rectangle, containing eight bits. These bytes are transmitted on the SCSI bus 60 in order from the topmost byte to the bottommost byte. In the command packet (CMD PKT), the first byte (byte 0) contains the command portion, which for a write-verify command is a byte containing the hexadecimal value "2E". In the next byte (byte 1), bits 7, 6 and 5 in combination, contain data to indicate which device on the SCSI bus 60 is to respond to this command (LOGICAL UNIT NUMBER), bit 4 is a cache control data bit (DPO), bit 1 is a verification control bit (BYTCHK), and bit 0 is a relative address control bit (RELADR), with bits 2 and 3 being reserved (RSVRD). The operation of these bits is well known, and not germane to the present invention, so they will not be described in detail here. Bytes 2 through 5, in combination, contain 32 bits of data representing the logical block on the disk at which data is to be written (i.e. the first data portion). Byte 6 is reserved. Bytes 7 and 8, in combination contain 16 bits of data representing the length of the second data portion associated with this command packet (CMD PKT). Byte 9 is a control byte indicating the end of the command packet (CMD PKT). The following data packet (DATA PKT) includes an initial 512 bytes (bytes 0 through 511) of write data, followed by 8 bytes (bytes 512 through 519) of cyclic redundancy check (CRC) code data, used for error detection purposes. If more than 512 bytes of data are to be written, additional data packets will immediately follow the first one.

Referring again to FIG. 1, the bus interface 102, operating in a known manner, recognizes the disk control command packet on the SCSI bus 60, and if the logical unit number corresponds to that of the bus interface 102, transfers the complete disk control command, including the command packet and all the associated data packets, to a buffer in the resident RAM 110, e.g. using known DMA techniques, then notifies the resident processor 106 of the receipt of the command e.g. via an interrupt signal. As each successive data packet (DATA PKT) is received by the bus interface 102, the appended CRC code is checked, in a known manner, to assure the accuracy of the received data, and the CRC bytes are stripped off the data packet, leaving only the write data in the buffer in the resident RAM 110. If an error is detected in the received data, execution of the disk control command is terminated and the host processor 20 is notified via the SCSI interface 40. Otherwise the disk control command is executed.

The resident processor 106 operates in a known manner, according to a control program stored in the control microcode in the non-volatile memory 108, to execute the disk control command. In response to this control program, the resident processor 106 retrieves the command portion (byte 0 in the command packet CMD PKT of FIG. 2) of the disk control command in resident RAM 110 and identifies that command as a write-verify command. To properly execute the write-verify command, the resident processor conditions the drive controller 112 to turn on the motor via a signal at its motor control output terminal M, and to position the read/write heads 116 to the location on the platters 114 corresponding to the logical block specified in the first data portion (bytes 2 through 5 in the command packet CMD PKT of FIG. 2) of the command via a signal at the head control output terminal H.

When the drive controller 112 informs the resident processor that the motor is on and up-to-speed, and that the heads are at the correct position, the resident processor 106 conditions the drive controller 112 to access the resident RAM 110 to retrieve the data in the second data portion of the command (the write data from the data packets) from the resident RAM 110, and supply it to the read/write heads 116 via the data input/output terminal D thence to be written onto the disk drive platters 114. When the drive controller 112 indicates that the data has been written to the disk drive platters 114, the resident processor 106 conditions the drive controller 112 to read data from the same location on the disk drive platters 114 into which the write data was just written via the read/write heads 116 and compare it to the data still stored in the resident RAM 110 to verify that the data was properly written. If the data read from the disk platters 114 is different from the received write data, a write error is detected. If a write error is detected, then this write-verify cycle is repeated a predetermined number of times in an attempt to correctly write the data. Either the data will be correctly written, in which case a confirmation response message will be generated, or not, in which case a write error response message will be generated and stored in the resident RAM 110.

In either event, the resident processor 106 will finally condition the bus interface circuit 102 to place the response message previously stored in the resident RAM 110 onto the SCSI bus 60, and then conditions the drive controller 112, at least eventually, to remove power from the motor, and enter a quiescent state. The SCSI bus interface 40 receives the response message, places it in the memory of the host processor 20 and informs the operating system routine which requested the write access, e.g. via an interrupt signal. The received response is then returned to the requesting application program, which can proceed in the case of a confirmation response, or take some corrective action in the case of a write error response. Other access requests from application programs are processed in similar, also well known, manners.

In accordance with the present invention, the control microcode in the non-volatile memory 108 controls the resident processor 106 to detect a first disk control command, called the initiator command in the remainder of this application, in response to which the disk drive is placed in a state waiting to receive new control microcode. When in this waiting state, a second disk control command, called the transfer command in the remainder of this application, is detected which contains the new control microcode for the disk drive 10. When the new control microcode has been received, and its accuracy has been verified, it is stored in the non-volatile memory 108, and the disk drive restarted using the new microcode.

The command portion of the initiator command must be selected to be one that would be transmitted to the disk drive 10 in response to a disk access operating system routine legitimately called by an application program. For example, in the illustrated embodiment, a SCSI write-verify disk control command portion ("2E"), whose operation is described above, forms the command portion of the initiator command. In order to minimize interference with normal disk write requests, both the logical block on the disk drive (first data portion), and the write data (second data portion) of the initiator command have predetermined values, described below, selected so that they would practically never occur in a normal application program.

In a standard computer system, some data related to the operation of the disk drive is stored in fixed predetermined logical blocks on the disk drive itself. For example, in the illustrated embodiment, the first 256 logical blocks of the disk drive are assumed to contain such disk drive information. Application programs would generally have no reason to directly access these logical blocks. Thus, the logical block for the initiator command is selected from among these logical blocks. Specifically, in the illustrated embodiment, logical block 96 (or in hexadecimal "60") is selected to be the predetermined logical block. In addition, the write data for the initiator command is selected such that it would be rarely occur. Specifically, in the illustrated embodiment, the write data is selected to be "EMC.sup.2 " (or in EBCDIC encoded hexadecimal: "C5D4C3EA"). It is highly unlikely, to the point of impossibility, that this particular data would ever be written to this particular block on the disk drive 10 via a write-verify command. Thus, a write-verify command ("2E") to write the data "EMC.sup.2 " to logical block 96 is selected as the initiator command. Similarly, a second write-verify command to logical block 96, where the write data is the new microcode, is selected as the transfer command.

FIG. 3 is a flow diagram 200 illustrating a portion of the operation of the disk drive 10 (of FIG. 1) according to the present invention and FIG. 4 is a diagram, partially in block form, and partially in functional block form, useful in understanding the portion of the operation of the resident processor illustrated in FIG. 3. FIG. 3 illustrates the flow of data through the disk drive 10, and the functions performed on the data by the various elements illustrated in FIG. 4. In FIG. 4, those blocks corresponding to actual hardware elements in disk drive 10 have the same reference numbers as in FIG. 1. The other elements illustrated in FIG. 4 are meant to illustrate data processing functions, and do not correspond to actual hardware elements in the illustrated embodiment. Arrows between elements or FIG. 4 illustrate flow of data from one element or data processing function to another, and do not necessarily indicate physical electrical connections. FIG. 4 will be discussed in conjunction with FIG. 3 in the discussion below.

Referring to FIG. 4, as described above, the bus interface 102 recognizes a disk control command on the SCSI bus 60, and transfers the complete command, including the command packet and all the data packets (of FIG. 2) to a buffer 111 in the resident RAM 110. The buffer 111, thus, contains the command portion (C), the logical block (L) and the write data (D) at known respective locations in the buffer. The combination of the bus interface 102 and the resident RAM 110, illustrated by a dashed line 120, acts as a receiver for disk control commands. The resident processor 106 is illustrated as functional elements, to be described in more detail below, enclosed in a dashed line. The resident processor 106 receives microcode instructions from the non-volatile memory 108, as indicated by the broad arrow in FIG. 4. The resident processor 106 controls the transfer of data from the location in the buffer 111 in resident RAM 110 containing the write data D to the non-volatile memory 108. Although data transfers in FIG. 4 are illustrated by separate connecting lines, it should be understood that all transfers of data are made over the internal bus 104 (of FIG. 1) by any of the known transfer mechanisms used in computer systems, such as DMA or processor controlled transfers.

The portion of the operation of the resident processor 106 of disk drive 10 illustrated in FIG. 3 relates specifically to the detection, reception and storage of new microcode. This process begins in step 202, in which power-on processing is performed and any required initializations are made. In step 204, normal operation of disk drive 10 is commenced. As described above, during normal operation 204, commands may be received to read data from or write data to the disk drive or perform other operations (not described). Processing of only one of these commands, the write-verify command, is illustrated in detail in FIG. 3.

In step 206, the command portion of a newly received disk control command is compared to the predetermined command portion, for an initiator command, i.e. a write-verify command (hexadecimal "2E") in the illustrated embodiment. This is illustrated in FIG. 4 by a command comparator 141 having a first input terminal coupled to the command portion C of the buffer 111 in resident RAM 110, a second input terminal coupled to a register 142 containing the value of the write-verify command, and an output terminal. If the command portion of the newly received disk control command is not the predetermined command portion for an initiator command, then normal operation continues in step 204 to process this disk control command in a known manner. If, however, the command portion is a write-verify command, then in step 212, the logical block in first data portion of the write-verify disk control command is compared to the predetermined logical block for an initiator command, i.e. 96 in the illustrated embodiment. This is illustrated in FIG. 4 by a logical block comparator 143 having a first input terminal coupled to the logical block portion L of the buffer 111 in resident RAM 110, a second input terminal coupled to a register 144 containing the value of the predetermined logical block, and an output terminal.

If the logical block in the write-verify disk control command is not the predetermined logical block for an initiator command, then normal write-verify command processing is performed in step 216 in a known manner, as described in detail above, and when the normal processing of the write-verify command has been completed in step 216, then normal operation of the disk drive 10 is resumed in step 204. If, however, the logical block is the predetermined logical block for an initiator command, then in step 214, the write data in the second data portion of the write-verify disk control command is compared to the predetermined write data for an initiator command, i.e. "EMC.sup.2 " in the illustrated embodiment. This is illustrated in FIG. 4 by a write data comparator 145 having a first input terminal coupled to the write data portion D of the buffer 111 in resident RAM 110, a second input terminal coupled to a register 146 containing the value of the predetermined write data, and an output terminal.

If the write data in the write-verify disk control command is not the predetermined write data for an initiator command, then normal write-verify command processing is performed in step 216, as described above. If, however, the write data is the predetermined write data for the initiator command, then an initiator command has been detected. That is, the command portion, the logical block and the write data all have the predetermined values for an initiator command. This is illustrated in FIG. 4 by an AND gate 147 having respective input terminals coupled to the output terminals of the command comparator 141, the logical block comparator 143 and write data comparator 145, and an output terminal. A signal at the output terminal of AND gate 147 indicates that an initiator command has been detected. In executing steps 206, 212 and 214, enclosed by a dashed line 215, the resident processor 106, under the control of the resident microcode in non-volatile memory 108, operates as a detector of received initiator disk drive commands. This is illustrated in FIG. 4 by an initiator command detector block 140, containing the respective comparators (141,143,145), registers (142,144,146) and AND gate 147.

When the initiator command is detected, no transfer of data is performed to the disk drive platters 114. Instead, the disk drive enters a state ready to receive new microcode. In step 218, the resident processor 106, under the control of the resident microcode in non-volatile memory 108, clears a buffer in the resident RAM 110 of sufficient size to hold the new microcode when an initiator command is detected. In the illustrated embodiment, a buffer sufficient to hold 256 kilobytes (256 k) is cleared in the resident RAM 110. Then, in step 220, the bus interface 102 is configured by the resident processor 106 to store the next disk control command received into this newly cleared buffer in the resident RAM 110, and the disk drive 10 waits for a transfer command containing the new microcode. This is illustrated in FIG. 4 by a control circuit 160, responsive to initiator command detector 140. When the transfer command is received, it is stored in the newly cleared buffer under the control of the bus interface 102, which then notifies the resident processor 106 that the transfer command has been received.

In step 222, the command portion of the newly received disk control command is compared to the predetermined command portion of a transfer command, i.e. a write-verify command (hexadecimal "2E"). This is illustrated in FIG. 4 by a command comparator 151 having a first input terminal coupled to the command portion C of the buffer 111 in resident RAM 110, a second input terminal coupled to a register 152 containing the value of the write-verify command, and an output terminal. If the command portion of the newly received disk control command is not the predetermined command portion for a transfer command, then a microcode load error has occurred. In step 226, a microcode load error response message is prepared and stored in the resident RAM 110 by the resident processor 110, which then conditions the bus interface 102 to return that response message to the SCSI interface adapter 40 via the SCSI bus 60, as described above. Then normal operation resumes in step 204. If, however, the command portion is the predetermined command portion for a transfer command, then in step 224, the logical block in the first data portion of the write-verify disk control command is compared to the predetermined logical block for a transfer command, i.e. 96 in the illustrated embodiment. This is illustrated in FIG. 4 by a logical block comparator 153 having a first input terminal coupled to the logical block portion L of the buffer 111 in resident RAM 110, a second input terminal coupled to a register 154 containing the value of the predetermined logical block, and an output terminal.

If the logical block in the write-verify disk control command is not the predetermined logical block for a transfer command, then a microcode load error has occurred. It is handled in step 226, as described above, and normal operation is resumed in step 204. If, however, the logical block is the predetermined logical block for the transfer command, then a transfer command has been detected and the write data in the second data portion of the write-verify command is the new microcode. That is, the command portion and the logical block both have the predetermined values for a transfer command. This is illustrated in FIG. 4 by and AND gate 157 having respective input terminals coupled to the output terminals of the command comparator 151 and the logical block comparator 153 and an output terminal. A signal at the output terminal of AND gate 157 indicates that a transfer command has been detected. In executing steps 222 and 224, enclosed by a dashed line 225, the resident processor 106, under the control of the resident microcode in non-volatile memory 108, operates as a detector of received transfer disk drive commands. This is illustrated in FIG. 4 by a transfer command detector block 150, containing the respective comparators (151,153), registers (152,154) and AND gate 157. Also in FIG. 4, the control circuit 160 is responsive to the transfer command detector 150. If an initiator command was previously detected by initiator command detector 140, then a transfer command is detected by transfer command detector 150, then new microcode is contained in the data portion D of the buffer 111 in resident RAM 110.

In step 234, the resident processor 106, verifies the accuracy of the microcode in the buffer of the resident RAM 110 by testing the amount of write data received, and by the use of an error detection code included with the microcode. In the illustrated embodiment, the write data portion must contain 256 k bytes of data. In addition, in the illustrated embodiment, the error detection code is a checksum appended to the microcode, in a known manner. If either amount of write data is incorrect or the checksum indicates that the newly received microcode is not accurate, then an error has occurred. This is illustrated in FIG. 4 by an error detecting code (EDC) block 190 coupled between the data portion D of the buffer 111 in resident RAM 110 and the control circuit 160. The EDC block 190 analyzes the data in the data portion D of the buffer 111 of the resident RAM 110 by verifying its size and by calculating a checksum over the data in a known manner. If an error is detected, a signal is supplied to the control circuit 160. The error is handled in step 226 as described above, and normal operation is resumed in step 204. If the amount of write data is correct and the checksum indicates that the newly received microcode is accurate, then in step 236, the new microcode is transferred from resident RAM 110 to the non-volatile memory 108, in a known manner. This is illustrated in FIG. 4 by transfer circuitry 170 coupled between the data portion D of the buffer 111 in resident RAM 110 and the non-volatile memory 108. When control circuitry 160 has received respective signals indicating a valid initiator command, a valid transfer command and that the data is accurate, then the transfer circuitry 170 is activated, to transfer the new microcode from the data portion D of the buffer 111 in resident RAM 110 to the non-volatile memory 108. In step 238, the resident processor 106 restarts using the new microcode, and when all necessary initializations have been performed, normal operation is again initiated in step 204.

FIG. 5 is a flow diagram 300 illustrating the operation of an application program which may be used to transfer new microcode to a disk drive 10 (of FIG. 1) according to the present invention. In FIG. 5, only the portion of the application program actually involved in transferring new microcode to a disk drive 10 is illustrated. The application program begins in step 302 during which any required initializations are performed, and the state of the computer system is adjusted to permit proper loading of new microcode to the disk drive 10. For example, it is preferable to initially execute a disk status inquiry to verify that the disk drive 10 has an appropriate serial number and a current version of resident microcode which will correctly detect and process initiator and transfer commands. Then, it may be necessary for the system administrator to temporarily halt system activity, to prevent attempts to access a disk drive whose microcode is being updated. (This is not the same as shutting down the computer system and/or stopping execution of the operating system, but instead is a temporary halt of system activity using an existing operating system routine.)

In step 304, a buffer is allocated for the write data in the memory (not shown) of the host processor 20 (of FIG. 1). In step 306, the predetermined data for the initiator command, e.g. "EMC.sup.2 " in the illustrated embodiment, is stored in the allocated buffer. In step 308 a logical block variable is set to the predetermined logical block for the initiator command, e.g. 96 in the illustrated embodiment. In step 310, the disk write operating system routine is called with the logical block variable set to 96, and the data in the buffer being "EMC.sup.2 ". This is detected as an initiator command in the disk drive 10, in the manner described in detail above. In step 312, the new microcode, having a size of 256 k, and an appended checksum, is moved into the buffer. In step 314, the disk write operating system routine is called again. The logical block variable is still 96, and the write data is the new microcode. This is detected as a transfer command in the disk drive 10, in the manner described above. After the transfer command is transmitted, the disk drive must be given time to check the newly transferred microcode for accuracy, to transfer it from the resident RAM 110 to the non-volatile memory 108, and to restart operation of the resident processor 106 under the control of the new microcode. In step 316, the host processor 20 waits for a predetermined period of time. In the illustrated embodiment, the predetermined period of time is 60 seconds. At the end of this time, the disk drive is polled to determine that it is ready for normal operation, and the application program ends in step 318 by sending a message to the system administrator indicating that the new microcode has been downloaded. The system administrator may then restart system activity, and the system is available for processing.

It is also possible to update the microcode of more than one disk drive attached to the computer system at the same time. In such a situation, in step 302, a disk status inquiry is executed for each such disk drive to verify that each of the disk drives has an appropriate serial number and a version of microcode which will correctly recognize and process initiator and transfer commands. Then, the system administrator may temporarily stop system activity. The process illustrated in steps 304 to 316 is repeated for each disk drive whose microcode is to be updated. When all such disk drives have had their microcode updated, then the system administrator may restart system activity, in step 318, and the system is available for processing.

Although the invention has been described above in the context of a SCSI magnetic disk drive, one skilled in the art of peripheral device design will understand that any peripheral device (e.g. tape drives or optical disk drives), using any command protocol (e.g. ESDI, IDE or proprietary), which include a resident processor operating according to resident microcode stored in a non-volatile memory may, in accordance with principles of the present invention, have its control microcode updated by download using an application program executed by any operator, without requiring a special operating system routine, shutting down the operating system of the computer system or an on-site visit by a service engineer using special equipment.