S3U USB Mass Storage Device Test Utility

 

Changes:

20 Apr 2006 – initial development had hard-coded the ‘logical unit’ of the SD slot of the 13-in-1 reader to 2.  New version allows user to select a logical unit number of 0 to 3.

 

Download Page

Introduction

S3U is a simple utility for testing USB mass storage devices such as a flash memory reader.  Tests include stuck-at data bit faults and sequential read and write speeds.  Note the device that under test will need to be re-formatted once tested.

 

Other Requirements

LibUsb-Win32 filter driver is used to provide USB access.  While setup of LibUsb-Win32  is straight-forward, using it requires more than a basic level of computer skills.  The process involves:

  1. Installing the Libusb-win32 filter driver.  The installation executable must be located and run.  A copy of the filter driver has been included in this package.
  2. Normally, the USB flash memory device is recognized by the Windows operating system as a Mass Storage Device and as a disk drive.  From the Device Manager Control Panel (Control -> Performance and -> System ->Hardware->Device Manager->Disk Drives ), they should be disabled to prevent conflict between the operating system attempting to poll the storage device and this utilities tests.  If not disabled, the test utility may occasionally report failures, but no damage is done.  Note that some card readers will present themselves as several storage devices (to support simultaneous access to different media such as a Compact Flash and SD Card.  They must all bedisabled to prevent USB messages from the XP operating system from interfering with the S3U USB messages.

The storage device must be enabled to revert your system back to state where the card reader can be used as part of a filesystem.

  1. Running the Test Utility.  This utility is not installed and registered.  The executable needs to be located and run.
  2. Determining the Vendor and Product Identification for the device under test.  Provided there are not too many USB devices, this is not difficult.  Just by scanning the devices on the USB busses, it is likely that the VID and PID can be determined from the list produced by the scan.  The S3U test tools needs to be updated with the VID and PID in order to test the appropriate device.  If more there is more than one device with the same Vendor and Product Identification number, the first one on from the USB scan list will be tested.

 

Results

Using an ACROX 12-in-1 card reader (based on Genesys GL816E controller?) on a Gateway MX6420, here are the results for two SD cards:

 

Sandisk 256MByte AR0534004059B

Lexar 512MByte 3050421 3401-512H A4205M

Theory of operation 

Once the S3U executable is started, a graphical user interface appears.  The Vendor and Product Identification information is entered by selecting the Configuration option under the Options Menu on the top taskbar.

 

If the identification codes are not known, select the Scan USB item under the Debug Menu on the top taskbar.  Provided there are not many devices on the bus, the codes corresponding to the flash memory under test should be easy to identify.  The USB bus can be rescanned as many times as desired.

 

Once the Vendor and Product Identification codes are entered, select the Capacity and Inquiry items from the Debug Menu on the top taskbar.

 

For the memory test, the number of blocks to be tested is taken from the results of the Capacity command.  The Capacity command issues the READ CAPACITY command to the USB mass storage device.

 

Once the number of blocks is known, the test algorithm looks something like:

 

Start with block 0

While ( blocks to be tested)

      Set next report time to be after report interval blocks

      While ( current write block < next report time )

            Write a fixed pattern to a set of 32 blocks

            Get Acknowledgement message

            Increment write block

      While ( current read block < next report time )

            Read a set of 32 blocks

            Get Acknowledgement message

            Increment read block

      Report message rate

Report test status

 

The current report interval is set to 8192 blocks.  Because of the USB handshaking required to transmit a set of blocks to the USB device, there are trade-offs between achieving a maximum thruput rate and being responsive to errors which may occur.

 

Future versions will allow for varying the report and block set sizes.

 

Limitations

  1. Testing for stuck-at faults on data bits is  reassuring, but is usually not the best use of time for two reasons:
    1. Because NAND flash based memory cells have a relatively high failure rate, techniques such as CRC and Error Correction Codes are used to detect and correct errors as they occur. 
    2. NAND flash based systems usually integrate some process of wear-leveling and a logical to physical address translation system hidden from the user.  That is, the block address addresses which are part of the mass storage device interface may correspond to a different physical block of memory each time a write is performed to that block address.  And even if a data bit error occurred in a block during one pass of the memory test, the block might be taken out of service by the flash system’s memory manager or if it is not a good memory manager, recycled to another memory location.

However, if there are doubts about the quality of the flash system’s memory manager, this tool can help uncover faults here.

  1. A better test would be to test for address line faults.  These types of faults can make the same set of memory blocks appear in multiple address locations.  When testing memory on a block by block basis, using the same repeating patterns will not show an error – the same memory block just gets tested several times.