ATA Command Compliance Testing

STB Suite | The Industry Standard in Peripheral Testing.

Introduction

Command compliance testing is needed in order to verify proper or expected operation of ATA and SATA storage peripherals. This paper will discuss in particular ATA/SATA disk drive command testing. Testing for packet devices such as CD or DVD drives can be accomplished in the same manner by simply replacing the list of commands used in the test

Requirements

 Hardware Requirements

To run the example STB ATA and SATA command  you will need a computer system running Windows operating system. If you need to test 48-bit ATA or SATA commands you need to be sure that the operating system drivers support these operations.  The drivers in  Windows Server 2003 do support 48-bit operations, other OS’s will need testing to see if they support these commands.

You will also need an ATA or SATA controller which the operating system recognizes as a true ATA Task Register type of controller. Most add-in PCI SATA controllers are seen by Windows as if they are a SCSI host bus adapter rather than an ATA controller.

 

 

 

You can confirm how your operating system views your controller scheme by using Device Manager as shown below – note that the only drives that will be able to be tested for ATA or SATA command compliance mustbe attached to a controller that Windows sees as an IDE ATA/ATAPI controller

 

Note regarding 48-bit commands:

Also, be aware that at this time the Windows operating systems that do support 48-bit operations have a bug in ATA PASS THROUGH. After a 48-bit command completes, only the FIRST task file is returned (HOB=0), but not the second one (HOB=1). Thus, READ NATIVE MAX ADDRESS EXT can get the low LBA bits 0..23, but not the high LBA bits 24..47.

Once you have disk drives attached to the proper controller you can run the example STB ATA/SATA Command Compliance Test

User Requirements

It is essential that the user of this test be familiar with the ATA and SATA specifications. Documentation can be found at www.t13.org



Test Methodology

A command compliance test must be able to issue any type of ATA or SATA command – including illegal commands. It should give an option to issue data-safe or non-destructive commands or data-destructive commands at the users choice. In order to minimize system hangs it is important that all commands that are issued are able to abort if they have not completed within an expected time.

The test should allow sending any number of commands in sequence. All aspects of these commands must be definable by the user, such as the actual command byte values, the data direction and length (if any), the command length (28-bit or 48-bit commands), and the number of seconds to wait for completion before aborting the command via a timeout.

The test should issue any commands that the user defines, and should gather and display if the command completed normally or with an error. If an error is returned the ATA Task Registers should be displayed and logged for interpretation.

Normal and error status

The results of all commands are returned via the ATA Task Registers. By interpreting the values contained in these registers the test can decide whether a command completed successfully or whether and error occurred. In particular the ERROR and STATUS registers will show error or normal completion. A status value of 0x50  indicates successful completion, a value of 0x51 indicates an error.

Note:

The NOP command always returns an ERROR status. Other commands may as well – be sure to study the ATA and SATA command documentation.

>Exceptions

Certain commands will cause the drive to become idle or non-responsive. When a command is issued that results in the drive being left in an IDLE , STANDBY,or SLEEP state other command sequences may be needed to bring the drive back into an ACTIVE state.

Idle and Standby

A drive can be brought back to ACTIVE state from IDLE or STANDBY state by issuing a READ SECTOR command. The CHECK POWER MODE command can be issued to ascertain the current state of the drive.

Sleep

Once a SLEEP command has been executed by a disk drive it will no longer respond to any commands. In this case either a Bus Reset must be issued, or power to the drive must be cycled.

Security Freeze

A drive which has been placed in a SECURITY FREEZE state must be power cycled to un-freeze the drive. Until this has happened the drive will not respond to any SECURITY FEATURE commands.

Determining the drive’s capabilities and state

The IDENTIFY command can be issued to a drive in order to ascertain it’s capabilities. The data returned by this command will show all information about the drive, such as Model and Serial Number, what version of ATA commands are supported, SATA interface level and speed, whether 48-bit and Security and Power Management features are supported and enabled.

The STB Command Compliance will retrieve and interpret all drive IDENTIFY information.

The current Power State of the drive can be determined at any point in the test process by issuing the CHECK POWER MODE command and interpreting the results.

 

 

 

The STB ATA/SATA Command Compliance Test

 

This test is supplied as a stand-alone executable program which may simply be run. In addition the complete Microsoft Studio vs 6 C++ project is supplied so the user can fully customize the test to their unique requirements. As delivered, the Destructive Testing mode will attempt to preserve data integrity by always issuing a READ command before any WRITE commands, and subsequently using the read data to write back out to the same block. But take care not to run destructive testing on any drive containing important data.

Also – it is highly recommended that you do not run the compliance test on your system boot drive, or any drives with important data or system files.

 

The test application requires that the installed STB Developers Toolbox be version 80428 or above. To start the test simply double-click on the application. The main test dialog will be displayed as below:

 

 

Once you have selected a drive and clicked Scan the test will attempt to issue an IDENTIFY command to the drive. If the drive is an ATA or SATA drive, connected to the proper type of controller, the IDENTIFY information for the drive will be displayed, as below:

 

 

As the test progresses each command that is issued, and the results of the command are displayed in the Test Results window. If an error occurs it will be displayed in red

Click the Save to File button to store all drive IDENTIFY and test results information to an ascii text file.

Customizing the test source code

 

Opening the project

The STB ATA/SATA Command Compliance test is written in C++, using Microsoft Visual Studio vs 6.

It uses calls to the STB Developers Toolbox Library dll to communicate with the drive.

Open the project by double-clicking on the project file ATACompliance.dsw

The main body of the test code is located in the file ATAComplianceDlg.cpp

Adding your own commands

Go to the functions NonDestructiveCommands() and DestructiveCommands() to customize the commands that are issued during the test.

Defining ATA/SATA commands

The function BuildCommand() is used to define commands. The parameters passed to this function are:

int CATAComplianceDlg::BuildCommand(

int number // the index into the array of commands issued by the test

unsigned char b0 – b12 // the bytes that make up the ATA command, in order as defined in the  ATA  documentation – b0 = function, b1 = sector count…b6 = command, b7-b12 the 48-bit command bytes

int cdblength // either 7 for a 28-bit command or 13 for a 48-bit command

int datalength // if the command has a data phase – if no data phase this must be set to zero (0) to avoid driver hangs.

int datadirection // 1 = data in from drive, 0 = data out to drive

int timeout // number of seconds after which the command will be aborted if not complete

)

See the pre-defined command descriptions, and modify them to issue whatever command you need to test.

Upon clicking the Start Test button the function OnStart() will be called, and will in turn call either NonDestructiveCommands() or DestructiveCommands() to initialize the array of commands to be sent in the test.

Once the command arrays are filled in the program loops, issuing each command in turn.

Special command sequence issues

 

As described previously, there are certain sequences of commands which must be issued in order to bring a drive back to active state once it has been put into STANDBY or IDLE state. You will note as the command sequence is defined there will be a CHECK POWER MODE command and a READ SECTOR(s) command issued after each type of IDLE or STANDBY command.

After a SLEEP command has put the drive into SLEEP state a bus reset must be issued. This is handled as a special exception as the test loops through the command list. If the command name == “BUSRESET” DTB will be called to issue a bus reset to the selected drive/bus.

Commands issued during Non-Destructive test

Here is the command sequence issued for the Non-Destructive test

 

BuildCommand(commandcount++,”NOP”,0,0,0,0,0,0,0,0,0,0,0,0,0,7,0,0,5);

// nop will always fail according to spec

BuildCommand(commandcount++,”IDENTIFY”,0,0,0,0,0,0,0xEC,0,0,0,0,0,0,7,512,1,5);

BuildCommand(commandcount++,”DEVICE RESET”,0,0,0,0,0,0,0×08,0,0,0,0,0,0,7,0,0,5);

// devicereset usually fails

BuildCommand(commandcount++,”EXECUTE DEVICE DIAGNOSTIC”,0,0,0,0,0,0,0×90,0,0,0,0,0,0,7,0,1,5);

// read commands

// read dma commands will fail on SATA drives

 

BuildCommand(commandcount++,”READ SECTORS”,0,0×1,0,0,0,0x40,0x20,0,0,0,0,0,0,7,512,1,5);

BuildCommand(commandcount++,”READ VERIFY SECTORS”,0,0×1,0,0,0,0x40,0x40,0,0,0,0,0,0,7,512,1,5);

BuildCommand(commandcount++,”SET MULTIPLE MODE”,0,0×1,0,0,0,0x0,0xC6,0,0,0,0,0,0,7,0,1,5);

BuildCommand(commandcount++,”READ DMA”,0,0×1,0,0,0,0x40,0xC8,0,0,0,0,0,0,7,512,1,5);

BuildCommand(commandcount++,”READ DMA QUEUED”,0x01,0,0,0,0,0×40,0xC7,0,0,0,0,0,0,7,512,1,5);

BuildCommand(commandcount++,”READ MULTIPLE”,0,0×1,0,0,0,0x40,0xC4,0,0,0,0,0,0,7,512,1,5);

BuildCommand(commandcount++,”READ SECTORS EXT “,0,0×1,0,0,0,0x40,0x24,0,0,0,0,0,0,13,512,1,5);

BuildCommand(commandcount++,”READ VERIFY SECTORS EXT”,0,0×1,0,0,0,0x40,0x42,0,0,0,0,0,0,13,512,1,5);

BuildCommand(commandcount++,”READ DMA EXT”,0,0×1,0,0,0,0x40,0x25,0,0,0,0,0,0,13,512,1,5);

BuildCommand(commandcount++,”READ MULTIPLE EXT”,0,0×1,0,0,0,0x40,0x29,0,0,0,0,0,0,13,512,1,5);

BuildCommand(commandcount++,”READ DMA QUEUED EXT”,0x01,0,0,0,0,0×40,0x26,0,0,0,0,0,0,13,512,1,5);

 

 

//idle,standby, and sleep commands –

// with additional commands needed to wake drive back up to active state

BuildCommand(commandcount++,”CHECK POWER MODE”,0,0,0,0,0,0,0xE5,0,0,0,0,0,0,7,0,1,5);

// sector count == 0xff means drive is active,ready. Sector count == 0x0 means drive is idle,standby, offline

 

BuildCommand(commandcount++,”IDLE IMMEDIATE”,0,0,0,0,0,0,0xE1,0,0,0,0,0,0,7,0,1,20);

BuildCommand(commandcount++,”READ SECTORS”,0,0×1,0,0,0,0x40,0x20,0,0,0,0,0,0,7,512,1,20);

BuildCommand(commandcount++,”CHECK POWER MODE”,0,0,0,0,0,0,0xE5,0,0,0,0,0,0,7,0,1,5);

 

BuildCommand(commandcount++,”IDLE “,0,0,0,0,0,0,0xE3,0,0,0,0,0,0,7,0,1,20);

BuildCommand(commandcount++,”READ SECTORS”,0,0×1,0,0,0,0x40,0x20,0,0,0,0,0,0,7,512,1,20);

BuildCommand(commandcount++,”CHECK POWER MODE”,0,0,0,0,0,0,0xE5,0,0,0,0,0,0,7,0,1,5);

 

BuildCommand(commandcount++,”STANDBY IMMEDIATE “,0,0,0,0,0,0,0xE0,0,0,0,0,0,0,7,0,1,20);

BuildCommand(commandcount++,”READ SECTORS”,0,0×1,0,0,0,0x40,0x20,0,0,0,0,0,0,7,512,1,20);

BuildCommand(commandcount++,”CHECK POWER MODE”,0,0,0,0,0,0,0xE5,0,0,0,0,0,0,7,0,1,5);

 

BuildCommand(commandcount++,”STANDBY “,0,0,0,0,0,0,0xE2,0,0,0,0,0,0,7,0,1,20);

BuildCommand(commandcount++,”READ SECTORS”,0,0×1,0,0,0,0x40,0x20,0,0,0,0,0,0,7,512,1,20);

BuildCommand(commandcount++,”CHECK POWER MODE”,0,0,0,0,0,0,0xE5,0,0,0,0,0,0,7,0,1,5);

 

BuildCommand(commandcount++,”SLEEP”,0,0×1,0,0,0,0x40,0xE6,0,0,0,0,0,0,7,0,1,5);

BuildCommand(commandcount++,”BUSRESET”,0,0,0,0,0,0,0,0,0,0,0,0,0,7,0,0,5);

BuildCommand(commandcount++,”READ SECTORS”,0,0×1,0,0,0,0x40,0x20,0,0,0,0,0,0,7,512,1,20);

BuildCommand(commandcount++,”CHECK POWER MODE”,0,0,0,0,0,0,0xE5,0,0,0,0,0,0,7,0,1,5);

 

 

Using BAM to confirm testing

The STB Suite Bus Analyzer Module (BAM) is the perfect tool to confirm the results of the STB ATA/SATA Command Compliance Test.

 

Simply start BAM, insure that all ATA phase capture options are set, select the drive under test, and start the trace capture.

Here is an example BAM trace showing the Non-Destructive test commands:

First, select the proper capture phase options:

 

 

BAM trace capture:

 

 

 

The next step – automating ATA/SATA Command Compliance testing in the STB Suite Disk Manufacturing Module (DMM)

 

One of the powerful features of the STB Suite Disk Manufacturing Module (DMM) is the ability to call an external program as a test step. When DMM calls an external program by default it passes the address of the drive under test, plus it can also  pass any number of other command line parameters.

This means that the sample STB ATA/SATA Command Compliance Test could easily be rewritten to be a Windows command line application with no gui. During a test sequence DMM could run the compliance test for each drive under test. Another very powerful feature of DMM is the ability for any external program or process to signal back to DMM to either log information into each individual drive’s logfile, and also to control the further test process on that drive.

In other words, in a test sequence DMM could start running the ATA/SATA command compliance test, tell the test whether to run destructive or non-destructive ( or any other ) test options, and the compliance test could log all of its results back into the DMM log files, or, if an error occurs during the compliance test the DMM test sequence for that drive could be aborted.

A second Visual Studio C++ project is supplied which does exactly this. Giving you the ability to instantly build ATA/SATA command compliance testing into your DMM test sequences, with no more than a point- and-click operation. By supplying the complete program project and source code you can easily customize this process to include vendor unique operations, firmware downloads, retrieval and storage of ATA SMART logs – virtually any operation that can be accomplished by a powerful ATA pass through command function.

 

 

 

How easy is it to add this type of testing to a complex DMM drive test sequence? As simple as selecting External Program and pointing to the executable to run:

 

 

 

Do you want to pass other command line arguments to your command compliance test? Easy – go to DMM Test Setup Advanced Options and enter the arguments you want passed (in addition to the default device address arguments):

 

Summary

We have presented a discussion of test methodology to define a complete method of testing ATA and SATA Task Register command compliance.

We have covered issues that must be addressed to accomplish this testing in the Windows operating system environment.

We have described a sample stand-alone application that thoroughly tests ATA or SATA disk drives for any type of command compliance.

We have presented a method to include ATA/SATA disk drive command compliance testing within a larger Disk Manufacturing Module environment.

In addition we have supplied complete project and source files for both the stand-alone compliance test application and the no-gui command-line compliance test.

Further Information

For further information about implementing ATA/SATA, or SCSI/SAS/FC command compliance testing into your test environment please email any questions to support@scsitoolbox.com.

We also offer a service to our active Performa customers where we will do hands-on, “live” training via web conferencing. There is no charge for this training – you will be able to meet and discuss any technical issues with members of our development team .

We would be happy to arrange a web conference with your testing team – to set up a web meeting please call Jeremy Wolfe at 720-249-2641.