USB High Speed EHCI (2.0) Interface Stress Test (Compact 2013)
3/26/2014
The USB Stress Test runs common USB scenarios on the platform that is being tested, but at a higher rate of frequency and with larger payloads, in order to stress the system and reveal possible defects that escape more generic test suites. The stress test generates payloads by using the random seed parameter from Tux.exe, enabling a reproducible set of transfers. Additionally, the stress test emulates common functions. The tests enable the debugging of issues at the bus level before connecting to real devices.
Test Prerequisites
Your device must meet the following requirements before you run this test.
The USB Stress Test requires two platform devices. One device acts as the USB host under test, while the second acts as a USB function device. The USB function device that has been tested is a CEPC with a NetChip NET2280 USB function PCI card, but can be any platform supporting USB function that has the appropriate drivers supplied.
The following table shows the hardware required for the USB Stress Test.
Requirement |
Description |
|---|---|
USB Host Device Under Test |
Host platform under test containing either a host controller card or an on-board host controller. |
USB Function Device |
This test has been verified using a CEPC with a NetChip NET2280 USB function card. However, you can use another platform (or another instance of the same platform) as the USB function device, if the required USB function drivers are available. |
USB cable |
Required for setting up the test. |
USB "Clicker" |
Optional device for automated connection and disconnection testing. |
The following table shows the software that is required on the USB HOST device for the USB Stress Test.
Requirement |
Description |
|---|---|
Tux.exe |
Tux test harness, required to run the test. |
Kato.dll |
Kato logging engine, required for logging the test data. |
Ktux.exe |
Kernel mode test utility. |
Usbstress.dll |
Test module containing tests. |
USB host controller driver |
USB support required (EHCI/OHCI/UHCI). |
XXX_clicker.dll |
Optional test module for Clicker support, must meet the API Conformity Requirements stated below. |
The Clicker API is specified in the clicker.h header file in the \Test\BaseOS\Drivers\USB\Common folder. The following example shows the four key functions that you must define for your Clicker hardware.
* typedef BOOL(*LPUN_CLICKER_INIT)(TCHAR *); //exported as ClickerInit
* typedef BOOL(*LPUN_CLICKER_DEINIT)(void); //exported as ClickerDeInit
* typedef BOOL(*LPUN_CLICKER_CONNECT)(void); //exported as ClickerConnect
* typedef BOOL(*LPUN_CLICKER_DISCONNECT)(void); //exported as ClickerDisconnect
The following table shows the software that is required on the USB FUNCTION device for the USB Stress Test.
Requirement |
Description |
|---|---|
Lufldrv.exe |
Tool that loads the loopback driver. |
LpBkCfg1.dll |
Configures a USB function controller with six endpoints in addition to endpoint zero. |
LpBkCfg2.dll |
Configures a USB function controller with four endpoints in addition to endpoint zero. |
USB Function driver |
USB Function Controller driver support. |
The lufldrv.exe executable as well as the loopback configuration files can be found at the following default installation path: C:\Program Files\Windows Embedded Compact Test Kit\tests\target\<CPU>\.
Subtests
The table below lists the subtests included in this test.
SubTest ID |
Description |
|---|---|
1 |
This test case is the USB Stress Test. |
Setting Up the Test
See "Running the Test" for setup instructions.
Running the Test
Setting up the USB Stress Test requires downloading images to both the function and host devices, executing command lines on each, and when prompted, connecting the host to the function with a USB cable. Do not connect the USB cable until prompted by the test.
1. Download a runtime image to the USB function device (ex. CEPC with NET2280 card).
2. After the function device boots, at the Target Control Command Prompt, enter "s lufldrv" ("s lufldrv -f" for full-speed testing). See the table below for common testing scenarios. Using "gi mod", verify that LpBkCfg1.dll (or the appropriate loopback driver module) is loaded.
3. Download a runtime image to the USB host device (platform under test with USB host controller).
4. After the test platform boots, at the Target Control Command Prompt, enter "s tux -o -n -d usbstress".
5. When prompted by the host device, connect the host and function devices using a USB cable. Within several seconds, the main body of the test begins.
Note:
After all the tests have finished, if you want to run additional stress tests, you do not have to disconnect the USB cable. Instead, just type the test command, and the tests will run.
The same basic procedure is used for a variety of different configurations (high-speed/full-speed/composite, etc). The following table shows which commands to execute for the most common test scenarios.
|
FUNCTION-SIDE COMMAND |
HOST-SIDE COMMAND |
|---|---|---|
High Speed [EHCI(2.0)] |
s lufldrv.exe |
s tux -o -n -d usbstress |
High Speed [EHCI(2.0)], composite config |
s lufldrv.exe -c |
s tux -o -n -d usbstress |
Full Speed [OHCI(1.1)/UHCI(1.0)] |
s lufldrv.exe -f |
s tux -o -n -d usbstress |
Full Speed [OHCI(1.1)/UHCI(1.0)], composite config |
s lufldrv.exe -f -c |
s tux -o -n -d usbstress |
Note: To enable testing against a composite function, ensure that the USB function device image is built with the following SYSGEN set: SYSGEN_USBFN_COMPOSITE=1.
It is possible to alter the functionality of the test using command-line parameters.
Command-line parameters on the FUNCTION-side modify the loopback configuration. Sample usage: "s lufldrv -f".
Parameter |
Description |
|---|---|
-1 |
Specifies that lufldrv.exe loads the Loop-back Configuration #1 driver, LpBkCfg1.dll. |
-2 |
Specifies that lufldrv.exe loads the Loop-back Configuration #2 driver, LpBkCfg2.dll. |
-3 |
Specifies that lufldrv.exe loads the LpBkCfgNew.dll you created. For more information, see the "Running the Test" section of the "USB High Speed EHCI (2.0) Interface Regular Packet Size Test" |
-f |
Specifies that the test causes the USB function device to operate at full-speed instead of the default high-speed. |
Command-line parameters on the host-side modify the functionality of the stress test. Parameters are passed to the test via the tux test harness. Sample usage: "s tux -o -n -d usbstress -c "-s -t 20".
Parameter |
Description |
|---|---|
-r |
Specifies that the test simulates typical RNDIS client behavior: several various-sized control packet transmissions, in addition to larger data transfers on bulk pipes, all using an interrupt pipe for transfer completion notification. |
-s |
Specifies that the test simulates typical serial client behavior: polling on an interrupt pipe for a transfer request, followed by data transfer using bulk pipes. |
-m |
Specifies that the test simulates typical mass storage behavior: control transfer used to queue larger bulk data transfer. This parameter works whether or not the hardware uses an interrupt pipe for signaling. |
-v |
Specifies typical video capture device behavior: isochronous transfers of fixed size, using high bandwidth and frequency in order to stress the system. |
-o |
Specifies that the test overloads the client by issuing transfers of all types on all available pipes. This is the default behavior if you omit the -r, -s, -m, -v, and -o parameters. Recommended to run alone as it will cover all clients mentioned above as well. |
-t [minutes] |
Specifies the test duration in minutes. |
-l [clickerdll] [probability] [params] |
[clickerdll] specifies the optional clicker DLL name. [probability] specifies the chance that the test causes a disconnect during any individual 1KB transfer. [params] specifies a semicolon-delimited list of parameters passed to the Clicker_Init function of the clicker DLL. For example, "-l click.dll 80 COM1;" loads Click.dll as the clicker DLL, specifies an 80% connection/disconnection probability, and passes COM1; to the Clicker_Init function. |
Verifying the Test
When the test completes, ensure that the result is "PASSED".
Troubleshooting the Test
* Observe the debug output for failures. If source code is available, attempt to pinpoint the source of the error.
* On some platforms, you may encounter a limitation with regard to the amount of physical memory allocated for your host controller. This may cause memory problems when you run these tests. To correct this situation, increase the value for gcTotalAvailablePhysicalMemory in the appropriate system.c file that corresponds to your host-controller driver.