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:
- 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.
- 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.
- Running
the Test Utility. This utility is
not installed and registered. The
executable needs to be located and run.
- 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
- Testing
for stuck-at faults on data bits is
reassuring, but is usually not the best use of time for two
reasons:
- 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.
- 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.
- 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.