<?xml version="1.0" encoding="utf-8"?>
<!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->
<!-- This component and the accompanying materials are made available under the terms of the License 
"Eclipse Public License v1.0" which accompanies this distribution, 
and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->
<!-- Initial Contributors:
    Nokia Corporation - initial contribution.
Contributors: 
-->
<!DOCTYPE concept
  PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">
<concept id="GUID-C8217A7B-D741-5452-B95B-57B8978AD152" xml:lang="en"><title>Validation</title><shortdesc>Symbian platform provides test code that you can run to
validate a USB client port. This topic describes the USB client test
code.</shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>
<section id="GUID-9769035E-68E8-59E2-85EA-3F6129AD27D3"><title>Requirements</title> <p>For testing the port, you will need: </p> <ul>
<li id="GUID-0FFD84ED-C745-551E-BDB7-DD145609928E"><p>A Symbian platform
text shell ROM image for the device that also contains the USB drivers
(the LDD and the PDD), and the unit test applications <xref href="GUID-C8217A7B-D741-5452-B95B-57B8978AD152.dita#GUID-C8217A7B-D741-5452-B95B-57B8978AD152/GUID-62006D61-5222-5C83-86EC-54CECD4FED18">T_USB</xref> and <xref href="GUID-C8217A7B-D741-5452-B95B-57B8978AD152.dita#GUID-C8217A7B-D741-5452-B95B-57B8978AD152/GUID-78E25906-2FF3-572E-B24D-2F064B9DBD89">T_USBAPI</xref>. On a slow CPU you may need to use release (UREL)
versions of the driver binaries to avoid exceeding the time-out limits
of the USB protocol. </p> </li>
<li id="GUID-8E195CED-52E6-53A2-9313-4CF4C0951AB5"><p>A computer running
either MS Windows 98 or above to run the Symbian host-side
test program USBRFLCT, or MS Windows 2000 to run, in addition, the <xref href="GUID-C8217A7B-D741-5452-B95B-57B8978AD152.dita#GUID-C8217A7B-D741-5452-B95B-57B8978AD152/GUID-E8A9B4BD-E60F-5A08-A588-527347239118">USB Command Verifier (USBCV)</xref> R1.2.1 compliance test program.
On MS Windows XP you will also be able to run the USBCV R1.3 compliance
test program. </p> </li>
<li id="GUID-798B9CED-B0AB-505A-9098-40441F8B79C2"><p>A USB driver
disk (or some other location accessible to the PC) containing the <filepath>.inf</filepath> file that matches the device to be tested, and the
driver binary file that will be installed for the device. Note that
for <xref href="GUID-C8217A7B-D741-5452-B95B-57B8978AD152.dita#GUID-C8217A7B-D741-5452-B95B-57B8978AD152/GUID-AC6E3928-C027-56E5-985E-6B7699216FDE">USBRFLCT</xref>, both items are included in the binary program distribution. </p> </li>
</ul> <p>In addition, a USB analyser, like the ones made by <i>LeCroy</i> formerly CATC, is invaluable for this kind of work. Without this
equipment it may be impossible to be sure that the port has been fully
successful. </p> </section>
<section id="GUID-D77DF810-212A-5C12-B039-4FC785BA01B9"><title>Test
steps</title> <p>These are the recommended steps for testing the port: </p> <ul>
<li id="GUID-53C8E7F5-F98F-571B-98D2-FCF2F8E75039"><p>Run <xref href="GUID-C8217A7B-D741-5452-B95B-57B8978AD152.dita#GUID-C8217A7B-D741-5452-B95B-57B8978AD152/GUID-78E25906-2FF3-572E-B24D-2F064B9DBD89">T_USBAPI</xref> on the unconnected USB device and get it to pass. </p> </li>
<li id="GUID-F2B15A4A-AB54-50E8-A5A0-5F4D5B67258D"><p>Use a USB cable
to connect the device under test to a PC and start <xref href="GUID-C8217A7B-D741-5452-B95B-57B8978AD152.dita#GUID-C8217A7B-D741-5452-B95B-57B8978AD152/GUID-62006D61-5222-5C83-86EC-54CECD4FED18">T_USB</xref> on the device (use T_USB menu options '0','1','1' and
'1'). See if the device successfully delivers all the information
(descriptors) that the host asks for. If so, a dialogue box pops up
on the PC, saying “New hardware found” and offering certain options.
Point the OS to the location of the <filepath>.inf</filepath> files
and the driver files (the USB driver disk) and have it pick and install
the correct driver. Afterwards you should see the new USB device in
the Windows Device Manager under the category <i>Symbian platform
controlled USB devices</i> as <i>USBRFLCT - Device</i>. If things
don’t work as expected at this early stage, the USB analyser will
prove invaluable. </p> </li>
<li id="GUID-A4E3EB99-B189-54C3-A4FD-BF7F8F65E2DA"><p>Try and run <xref href="GUID-C8217A7B-D741-5452-B95B-57B8978AD152.dita#GUID-C8217A7B-D741-5452-B95B-57B8978AD152/GUID-AC6E3928-C027-56E5-985E-6B7699216FDE">USBRFLCT</xref> and <xref href="GUID-C8217A7B-D741-5452-B95B-57B8978AD152.dita#GUID-C8217A7B-D741-5452-B95B-57B8978AD152/GUID-AC6E3928-C027-56E5-985E-6B7699216FDE">T_USB</xref> together. First start T_USB on the device, choose the
four numbered program options (but this time the first menu option
must not be '0'), and then start USBRFLCT on the PC. The program pair
should run indefinitely, in any mode. If the program halts after a
while then this almost certainly indicates either a hardware problem
associated with the USB device controller or an incorrect handling
of the controller in the PSL. If the halt occurs after a long time,
then this could point to a resource problem, such as a memory leak.
This test will verify that at least one bulk IN endpoint and one bulk
OUT endpoint are working correctly, and that data can be transferred
over the USB link. </p> </li>
<li id="GUID-B88EBB38-3ACE-5F51-802D-360EA919DE5A"><p>Run the USB
Implementers Forum's <xref href="GUID-C8217A7B-D741-5452-B95B-57B8978AD152.dita#GUID-C8217A7B-D741-5452-B95B-57B8978AD152/GUID-E8A9B4BD-E60F-5A08-A588-527347239118">USBCV</xref> compliance test suite and go through the “Chapter 9
Tests”. You will first need to start <xref href="GUID-C8217A7B-D741-5452-B95B-57B8978AD152.dita#GUID-C8217A7B-D741-5452-B95B-57B8978AD152/GUID-62006D61-5222-5C83-86EC-54CECD4FED18">T_USB</xref> on the device end, as <xref href="GUID-C8217A7B-D741-5452-B95B-57B8978AD152.dita#GUID-C8217A7B-D741-5452-B95B-57B8978AD152/GUID-E8A9B4BD-E60F-5A08-A588-527347239118">USBCV</xref> needs a successfully enumerated device as a target (choose
'0' as the first T_USB option). These tests should all pass. It is
important to run <xref href="GUID-C8217A7B-D741-5452-B95B-57B8978AD152.dita#GUID-C8217A7B-D741-5452-B95B-57B8978AD152/GUID-E8A9B4BD-E60F-5A08-A588-527347239118">USBCV</xref> to verify that endpoint-0 is behaving correctly, and
that the device is compliant with the USB Specification 2.0. </p> </li>
</ul> </section>
<section id="GUID-A5CA6D74-1204-5C9C-9396-D51A8E58A952"><title>The
USBIO driver</title> <p>The host (PC) side test program: <xref href="GUID-C8217A7B-D741-5452-B95B-57B8978AD152.dita#GUID-C8217A7B-D741-5452-B95B-57B8978AD152/GUID-3F7462D9-EF86-5CC9-AEC5-EB755049B7CF">USBRFLCT</xref> uses the services of a USB client driver, <filepath>USBIO.SYS</filepath>. This driver is loaded by the OS as part of
the enumeration once the USB device on test is connected to the PC. </p> <p>The generic USB device driver USBIO is a product developed and
marketed by the German company <i>Thesycon</i> [USBIO Software Development
Kit for Windows; see <xref href="http://www.thesycon.de/usbio/eng/usbio.htm" scope="external">http://www.thesycon.de/usbio/eng/usbio.htm</xref>]. </p> <p>The driver
provides Win32 applications with direct access to USB devices which
are otherwise only accessible from kernel-mode. It can be used with
any kind of USB device, enabling application developers to control
devices without having to develop a kernel-mode WDM driver. Symbian
owns a licence to the driver and its development package, and is entitled
to ship renamed copies of the driver binary to licensees and partners
as part of its own development kits, usually adopting the name of
the application that uses it. </p> </section>
<section id="GUID-78E25906-2FF3-572E-B24D-2F064B9DBD89"><title>T_USBAPI</title> <p>This is a device-side only, stand-alone test program. It is used
to verify the proper working of some basic USB API functionality.
For T_USBAPI to run, the device doesn’t need to be USB-connected to
a PC although if it is then some additional tests are performed. Tests
run by T_USBAPI include: </p> <ul>
<li id="GUID-ED9F5656-C992-54D4-B625-66B427966AF1"><p>loading the
USB LDD and opening a channel </p> </li>
<li id="GUID-314942D9-4A66-52D1-AD07-DE193D639647"><p>searching for
suitable endpoints and setting up an interface </p> </li>
<li id="GUID-33DF3016-49D1-5591-A103-5931237FF760"><p>searching for
suitable endpoints and creating an 'alternate setting' for that interface
(if supported). </p> </li>
<li id="GUID-A76EDCE6-3629-5516-8920-B62962EC6FD4"><p>querying and
allocating endpoint resources (DMA and double buffering) </p> </li>
<li id="GUID-30E05336-A92E-5614-B365-90D4BCF3AF64"><p>powering up
the UDC and connecting it to the bus. </p> </li>
<li id="GUID-A75AEAEA-7328-517C-807B-59ECD051FB1B"><p>manipulating
(modifying) USB descriptors (Device, Device_Qualifier, Configuration,
Other_Speed_Configuration, Interface, Endpoint, String) </p> </li>
<li id="GUID-9D7AAEA0-5E85-56D0-8A11-52C2089A2C60"><p>testing the
USB OTG API extensions </p> </li>
<li id="GUID-3601CC5C-752E-5E29-ADA5-3590976F5B43"><p>requesting and
releasing <i>Device Control</i>  </p> </li>
<li id="GUID-D6BB7C90-9B9F-5111-83F6-5FC3E15FDBF3"><p>some static
state notification tests (alternate device status, endpoint status). </p> </li>
<li id="GUID-46858A91-D4DB-5A62-B791-66615745BDC9"><p>setting and
clearing endpoint Halt condition (where supported in unconfigured
state) </p> </li>
<li id="GUID-F8A0D0C3-CEF9-5226-9F04-2DB232F66CD7"><p>closing the
channel and freeing the LDD </p> </li>
</ul> <p>Most of these tests verify the functioning of the platform-independent
code (i.e. platform-independent layer + LDD). However, some of this
code relies on platform-specific layer functionality, such as the
stall state and the maximum packet size of endpoints. Therefore, a
working, or a partially working platform-specific layer is required
for T_USBAPI to pass. </p> <p>When called normally, T_USBAPI runs
once and then exits. It can also run endlessly in a loop, provided
it is not failing, by adding the parameter <i>soak</i> to the command
line. Once the program is running in endless mode, it can be stopped
at any time by pressing the <userinput>Esc</userinput> key, in which
case the program finishes the current set of tests and then exits.
This loop mode can be useful for the detection of memory leaks in
the USB stack, although the main functionality exercised lies in the
platform-independent layer and the LDD, not in the platform-specific
layer. </p> <p>T_USBAPI is a standalone program which can be safely
run on a UDEB image. Choose to display error messages and warnings
specific to the USB components using the appropriate kernel debug
flags (<codeph>KPANIC</codeph>, <codeph>KUSBPSL</codeph> and <codeph>KUSB</codeph>). The following example shows the E32 shell commands
to set <codeph>KPANIC</codeph>, <codeph>KUSBPSL</codeph> and <codeph>KUSB</codeph> in that order: </p> <p><userinput>C:\&gt;trace 80000000</userinput> </p> <p><userinput>C:\&gt;trace 3 1</userinput> </p> <p>"trace 3 1"
means "set (bit 1|bit 0) at index 1" (<codeph>KUSBPSL=33</codeph>, <codeph>KUSB=32</codeph>) </p> </section>
<section id="GUID-AC6E3928-C027-56E5-985E-6B7699216FDE"><title>USBRFLCT
and T_USB</title> <p>These are the host and device side parts, respectively,
of a reflector-like USB test program. They are normally used together,
but T_USB can also be used to create a simple USB device to allow
USBCV to execute. </p> <p> <note>Since this program suite is subject to continual development    
      and improvement, in order for them to work properly together,
both parts must           always come from the same Symbian platform
delivery. </note>  </p> <p>To ensure proper internetworking, <xref href="GUID-C8217A7B-D741-5452-B95B-57B8978AD152.dita#GUID-C8217A7B-D741-5452-B95B-57B8978AD152/GUID-3F7462D9-EF86-5CC9-AEC5-EB755049B7CF">USBRFLCT</xref> and <xref href="GUID-C8217A7B-D741-5452-B95B-57B8978AD152.dita#GUID-C8217A7B-D741-5452-B95B-57B8978AD152/GUID-62006D61-5222-5C83-86EC-54CECD4FED18">T_USB</xref> exchange their version numbers after startup, and either
program will quit if the other does not provide a suitable minimum
version number. </p> <p id="GUID-3F7462D9-EF86-5CC9-AEC5-EB755049B7CF"><b>USBRFLCT</b> </p> <p>This is the host-side part of a reflector-like USB test program.
This is normally used together with <xref href="GUID-C8217A7B-D741-5452-B95B-57B8978AD152.dita#GUID-C8217A7B-D741-5452-B95B-57B8978AD152/GUID-62006D61-5222-5C83-86EC-54CECD4FED18">T_USB</xref>, the device-side part. </p> <p>The directory <filepath>...\e32test\win32\usbrflct\</filepath> contains its source code. </p> <p>The directory <filepath>...\e32test\win32\usbrflct_distribution\</filepath> contains a binary distribution of the program, including the <filepath>USBRFLCT.SYS</filepath> driver and a <filepath>USBRFLCT.INF</filepath> file for the installation of the driver. </p> <p>The syntax for
invoking this is: </p> <codeblock id="GUID-823D06EF-4C96-53E3-8740-F8D996AA2372" xml:space="preserve">usbrflct [options]</codeblock> <p>where <codeph>options</codeph> can be <i>one</i> of the following: </p> <table id="GUID-D5A56CC6-6B60-52C6-8387-85935E1B5747">
<tgroup cols="2"><colspec colname="col0"/><colspec colname="col1"/>
<tbody>
<row>
<entry><p>/[r|t] </p> </entry>
<entry><p>receive|transmit only; default is to loop with statistics
printed every 1024th iteration </p> </entry>
</row>
<row>
<entry><p>/l </p> </entry>
<entry><p>loop mode with statistics printed for every iteration </p> </entry>
</row>
<row>
<entry><p>/v </p> </entry>
<entry><p>verbose driver &amp; program output </p> </entry>
</row>
<row>
<entry><p>/[h|?] </p> </entry>
<entry><p>displays this help text </p> </entry>
</row>
</tbody>
</tgroup>
</table> <p>Three modes of operation are available: </p> <ul>
<li id="GUID-3AA40354-D26E-5DA0-A69F-B3766D84AEC1"><p>Loop mode. </p> <p>Data chunks are read from the USB device and then immediately
written back to it. Successive data chunks are read, each being one
byte larger than the one before, starting with size 0 until a specified
maximum size has been reached. This maximum size value is specified
on the device using <xref href="GUID-C8217A7B-D741-5452-B95B-57B8978AD152.dita#GUID-C8217A7B-D741-5452-B95B-57B8978AD152/GUID-62006D61-5222-5C83-86EC-54CECD4FED18">T_USB</xref>. After the maximum size has been reached, the size of
the data chunk is reset back to its starting value. </p> <p>A preamble
packet is sent by the device before each data chunk, containing the
size of the chunk that is to follow. This kind of protocol is necessary,
because the host side driver has to specify the exact number of bytes
that it needs to read from the device. </p> <p>Every 1024th loop,
the program displays statistics about the test run. For example, the
total number of bytes transferred, and the current average data throughput
in bytes/sec. </p> </li>
<li id="GUID-4F50A5A8-E52C-54ED-BE12-4F751A4B5223"><p>Receive-only
mode. </p> <p>In this mode, a single preamble packet containing the
size of the data chunks that are to follow is sent from the device.
The host-side program subsequently, and continuously, reads data chunks
of that size from the device. This mode can be used to determine the
raw transfer performance of the USB connection in the device upstream
direction. </p> </li>
<li id="GUID-757B0CD8-CB5E-5BF1-86B1-8626F73604E3"><p>Transmit-only
mode. </p> <p>In this mode, no preamble packet is sent. Instead, maximum
(constant) sized data chunks are sent. This mode can be used to determine
the raw transfer performance of the USB connection in the device downstream
direction. </p> </li>
<li id="GUID-13B049DB-1955-5D3E-8404-C375ABEE2F06"><p>Verbose mode. </p> <p>In this mode, the driver and program output are both displayed.
Use this to track down problems that occur when trying to get <xref href="GUID-C8217A7B-D741-5452-B95B-57B8978AD152.dita#GUID-C8217A7B-D741-5452-B95B-57B8978AD152/GUID-3F7462D9-EF86-5CC9-AEC5-EB755049B7CF">USBRFLCT</xref> and <xref href="GUID-C8217A7B-D741-5452-B95B-57B8978AD152.dita#GUID-C8217A7B-D741-5452-B95B-57B8978AD152/GUID-62006D61-5222-5C83-86EC-54CECD4FED18">T_USB</xref> to work together. This may help in the following circumstances: </p> <ul>
<li id="GUID-11167D82-09B9-5D60-B1F6-AB14B633D56D"><p>the first time
you test a port of the platform specific layer </p> </li>
<li id="GUID-67F387AE-42B2-5EA6-8A76-B212D82EE2B9"><p>after installation
changes on the PC </p> </li>
</ul> <p>The error messages are particularly helpful, a list of error
codes together with explanations for the USBRFLCT.SYS driver can be
found in the USBIO Reference Manual. These codes are also available
on <i>Thesycon</i>'s website at <xref href="http://www.thesycon.de/usbio/usbioman.pdf" scope="external">http://www.thesycon.de/usbio/usbioman.pdf</xref>. Do not use this
mode during loop or throughput testing to avoid program slowdown which
could affect these tests. </p> </li>
</ul> <p id="GUID-62006D61-5222-5C83-86EC-54CECD4FED18"><b>T_USB</b> </p> <p>This is the device-side part of a reflector-like USB test program.
This is normally used together with <xref href="GUID-C8217A7B-D741-5452-B95B-57B8978AD152.dita#GUID-C8217A7B-D741-5452-B95B-57B8978AD152/GUID-3F7462D9-EF86-5CC9-AEC5-EB755049B7CF">USBRFLCT</xref>, the host-side part. </p> <p>The source for this
program can be found in: </p> <ul>
<li id="GUID-468F6A61-75FE-509A-BCEE-B979F8D5E5C8"><p> <filepath>...\e32test\device\t_usb.h</filepath>  </p> </li>
<li id="GUID-84E8F05C-51C9-5CB1-94AB-0FB63AA9C15B"><p> <filepath>...\e32test\device\t_usb.cpp</filepath>  </p> </li>
<li id="GUID-8A286F35-65EE-5FAC-B4B4-A014E0698308"><p> <filepath>...\e32test\device\t_usbco2.cpp</filepath>  </p> </li>
</ul> <p>After starting the program, you are prompted to choose a
maximum size for a single transfer. </p> <p> <b>Note: </b> The maximum
transfer size is not the same as the maximum packet size. </p> <p>The prompt appears as follows: </p> <p><userinput>++++Choose max
transfer size++++</userinput> </p> <p><userinput>'0' - Set up USB
device for USBCV</userinput> </p> <p><userinput>'1' - 32 bytes</userinput> </p> <p><userinput>'2' - 1024 bytes</userinput> </p> <p><userinput>'3' - 64 kbytes</userinput> </p> <p><userinput>'4' - 1 Mbyte</userinput> </p> <p>Once you have chosen the maximum transfer size you are prompted
to choose a bandwidth priority for the interface that will be created
and used for the tests. All options except '0' are used when <xref href="GUID-C8217A7B-D741-5452-B95B-57B8978AD152.dita#GUID-C8217A7B-D741-5452-B95B-57B8978AD152/GUID-62006D61-5222-5C83-86EC-54CECD4FED18">T_USB</xref> is run together with <xref href="GUID-C8217A7B-D741-5452-B95B-57B8978AD152.dita#GUID-C8217A7B-D741-5452-B95B-57B8978AD152/GUID-3F7462D9-EF86-5CC9-AEC5-EB755049B7CF">USBRFLCT</xref>. The program carries out dynamic version number checking
of the two programs to ensure compatibility . Option '0' sets up a
static USB device that can be used to perform other tests, including
compliance testing with <xref href="GUID-C8217A7B-D741-5452-B95B-57B8978AD152.dita#GUID-C8217A7B-D741-5452-B95B-57B8978AD152/GUID-E8A9B4BD-E60F-5A08-A588-527347239118">USBCV</xref>. This option also circumvents dynamic version checking.
Most of the other menu options have no meaning in this mode. </p> <p>Choose a bandwidth priority from the following menu for the interface
specifically created for the tests. All tests will be carried out
over this interface. </p> <p><userinput>++++ Choose Bandwidth Priority
++++</userinput> </p> <p><userinput>'1' - Economical buffering - default</userinput> </p> <p><userinput>'2' - More memory than default buffering - Plus1</userinput> </p> <p><userinput>'3' - More memory than Plus1 buffering - Plus2</userinput> </p> <p><userinput>'4' - Maximum memory for buffering</userinput> </p> <p>Choose endpoint options from the following two configuration
menus: </p> <p><userinput>++++ Choose Endpoint I/O Transfer Mode ++++</userinput> </p> <p><userinput>'1' - Interrupt Mode</userinput> </p> <p><userinput>'2' - DMA Mode (recommended)</userinput> </p> <p> </p> <p><userinput>++++ Choose Endpoint FIFO Mode ++++</userinput> </p> <p><userinput>'1' - Normal Buffering Mode</userinput> </p> <p><userinput>'2' -
Double Buffering Mode (recommended)</userinput> </p> <p>A message
prompts the user to start the host side test program USBRFLCT. </p>  <p>Once host enumeration
and <xref href="GUID-C8217A7B-D741-5452-B95B-57B8978AD152.dita#GUID-C8217A7B-D741-5452-B95B-57B8978AD152/GUID-3F7462D9-EF86-5CC9-AEC5-EB755049B7CF">USBRFLCT</xref> configuration completes, the program's main menu
is displayed as follows: </p> <p><userinput>++++ Select Program Option
++++</userinput> </p> <p><userinput>'L'oop test</userinput> </p> <p><userinput> Loop test with data 'C'ompare</userinput> </p> <p><userinput>'R'eceive-only test (we receive, host transmits)</userinput> </p> <p><userinput>'T'ransmit-only test</userinput> </p> <p><userinput> Receive and 'P'ut (write) to File</userinput> </p> <p><userinput> Transmit and 'G'et (read) from File</userinput> </p> <p><userinput> Signal Remote - 'W'akeup to the host</userinput> </p> <p><userinput>'S'top current transfer</userinput> </p> <p><userinput> Re'E'numerate
device</userinput> </p> <p><userinput>'Q'uit</userinput> </p> <p>Choose
one of the six main test modes. The selected mode should correspond
with the mode in which the host-side program is running. For example,
device-side <codeph>Receive</codeph> matches host-side <codeph>Transmit</codeph>. </p> <p>The Loop test with <codeph>Compare</codeph> is just like
the normal <codeph>Loop</codeph>, except that the received data is
compared with the data that was previously sent, allowing any transmission
errors to be detected. The purpose of the non-comparing mode is performance
(throughput) assessment of the USB link, in this mode the slow down
of the application introduced by the byte-by-byte checking of the
compare operation is not desirable. Note: The non-comparing mode does
do some checking, specifically it compares the received transfer number
(4 bytes at the start of each buffer) against the expected value. </p> <p>The standard 'Receive-only' test mode <userinput>R</userinput> immediately discards the data received, similarly the standard 'Transmit-only'
mode <userinput>T</userinput> creates random data on the fly to send
to the device. These tests are useful for checking the maximum throughput
of the link, however they do not reflect normal usage. In a real world
scenario, transmitted data would be read from a file and received
data would be written to a file. </p> <p>There are two further tests
which include file I/O. These are: </p> <ul>
<li id="GUID-079843BA-A985-5E00-AD1C-44E965EADF17"><p>'Receive' mode <userinput>P</userinput>, where data received from the link is written to a
newly created file. </p> </li>
</ul> <ul>
<li id="GUID-895EBD5E-1008-56C7-8AC2-68F534338893"><p>'Transmit' mode <userinput>G</userinput>, where data is read from a newly created file and sent
across the link. </p> </li>
</ul> <p>In both cases you must first enter a source or destination
from the list of available drives. </p> <p> <userinput>S</userinput> stops an ongoing transfer at any time </p> <p> <userinput>W</userinput> issues a Remote Wake-up signal to the host; this is needed, for
example, when running <xref href="GUID-C8217A7B-D741-5452-B95B-57B8978AD152.dita#GUID-C8217A7B-D741-5452-B95B-57B8978AD152/GUID-E8A9B4BD-E60F-5A08-A588-527347239118">USBCV</xref>. </p> <p> <userinput>E</userinput> re-enumerates the
USB device by first disconnecting it from, and then reconnecting it
to the bus. </p> <p> <userinput>ESC</userinput> or <userinput>Q</userinput> quits the program after tearing down the device configuration and
freeing all used resources. </p> </section>
<section id="GUID-8F2961A1-03B6-5642-82A7-3D2504436D0E"><title>USBIOAPP</title> <p> <i>Thesycon</i> provide this Win32 GUI application. Like <xref href="GUID-C8217A7B-D741-5452-B95B-57B8978AD152.dita#GUID-C8217A7B-D741-5452-B95B-57B8978AD152/GUID-3F7462D9-EF86-5CC9-AEC5-EB755049B7CF">USBRFLCT</xref> it works on top of the <filepath>USBRFLCT.SYS</filepath> driver (otherwise known as <filepath>USBIOAPP.EXE</filepath>). The
source code for this program is part of the USBIO development kit.
You can find the compiled executable <filepath>USBIOAPP.EXE</filepath> in the same directory as <xref href="GUID-C8217A7B-D741-5452-B95B-57B8978AD152.dita#GUID-C8217A7B-D741-5452-B95B-57B8978AD152/GUID-3F7462D9-EF86-5CC9-AEC5-EB755049B7CF">USBRFLCT</xref> and the host side drivers: <filepath>...\e32test\win32\usbflct_distribution\</filepath>. </p> <p>Use <xref href="GUID-C8217A7B-D741-5452-B95B-57B8978AD152.dita#GUID-C8217A7B-D741-5452-B95B-57B8978AD152/GUID-8F2961A1-03B6-5642-82A7-3D2504436D0E">USBIOAPP</xref> to exercise and test the low-level functionality
of an attached USB device. In this case, the Symbian platform device
running the USB device stack which includes the port of the platform-specific
layer. </p> <p>The following steps describe an example test: </p> <ul>
<li id="GUID-AAC49CFA-A077-52B6-8811-F18145B78787"><p>Connect the
Symbian platform USB device to a PC on which the <xref href="GUID-C8217A7B-D741-5452-B95B-57B8978AD152.dita#GUID-C8217A7B-D741-5452-B95B-57B8978AD152/GUID-3F7462D9-EF86-5CC9-AEC5-EB755049B7CF">USBRFLCT</xref> driver has been installed. </p> </li>
<li id="GUID-FEEDB45F-36D9-5AB6-9F3D-C36DB85AAC5A"><p>Start <xref href="GUID-C8217A7B-D741-5452-B95B-57B8978AD152.dita#GUID-C8217A7B-D741-5452-B95B-57B8978AD152/GUID-62006D61-5222-5C83-86EC-54CECD4FED18">T_USB</xref> on the device to create a USB device (use option '0'
for the transfer size). </p> </li>
<li id="GUID-CD6A4F22-1B47-5E50-A684-124616A6B0C7"><p>Launch <xref href="GUID-C8217A7B-D741-5452-B95B-57B8978AD152.dita#GUID-C8217A7B-D741-5452-B95B-57B8978AD152/GUID-8F2961A1-03B6-5642-82A7-3D2504436D0E">USBIOAPP</xref> on the PC. </p> </li>
<li id="GUID-3DC6299D-FBE4-542B-A9CE-2C6D05BCD9B5"><p>Press the <userinput>Scan for USBIO devices</userinput> button. The device should be detected
by <xref href="GUID-C8217A7B-D741-5452-B95B-57B8978AD152.dita#GUID-C8217A7B-D741-5452-B95B-57B8978AD152/GUID-8F2961A1-03B6-5642-82A7-3D2504436D0E">USBIOAPP</xref>. </p> </li>
<li id="GUID-CAC741CF-76EF-5418-94F6-923BF1F1E2A0"><p>Test and exercise
the USB device using the different options provided by the <xref href="GUID-C8217A7B-D741-5452-B95B-57B8978AD152.dita#GUID-C8217A7B-D741-5452-B95B-57B8978AD152/GUID-8F2961A1-03B6-5642-82A7-3D2504436D0E">USBIOAPP</xref> program. </p> </li>
</ul> <p>Further details can be found in the USBIO manual, which contains
a chapter on the <xref href="GUID-C8217A7B-D741-5452-B95B-57B8978AD152.dita#GUID-C8217A7B-D741-5452-B95B-57B8978AD152/GUID-8F2961A1-03B6-5642-82A7-3D2504436D0E">USBIOAPP</xref>. See <xref href="http://www.thesycon.de/usbio/usbioman.pdf" scope="external">http://www.thesycon.de/usbio/usbioman.pdf</xref> </p> </section>
<section id="GUID-E8A9B4BD-E60F-5A08-A588-527347239118"><title>USB
Command Verifier (USBCV)</title> <p>This test program is written and
maintained by the USB Implementers Forum, Inc, (also referred to as
the “USB Forum” or “USB IF”). It can be used to check compatibility
of the USB device with the USB specification (currently version 2.0).
It contains a collection of different test suites, but the only tests
that are of interest regarding the platform-specific layer port are
the “Chapter 9 Tests”. Even though most of the "Chapter 9" request
processing is done by the platform-independent layer, the tests can
help to uncover potential problems with endpoint-0 controlling platform-specific
layer code. The tests will also show whether or not the platform-specific
layer and the platform-independent layer work together without problems. </p> <p>This program runs on Windows 2000 and Windows XP (English Version)
only. At the time of writing, the version of the package is R1.2.1,
and can be obtained from <xref href="http://www.usb.org/developers/tools/USBCV121.msi" scope="external">http://www.usb.org/developers/tools/USBCV121.msi</xref>. </p> </section>
<section id="GUID-DA56677C-28D2-5CC2-BBA6-9CCF02C64FBF"><title>USBMSAPP
(USB Mass Storage Application)</title> <p>This is not a dedicated
test program, but it can be used to check that the USB driver stack
is operating correctly. Since it is not a test program USBMSAPP is
not normally included in ROMs with any of the <filepath>...\e32tests\f32tests\alltests
rom.bat</filepath> options. The source can be found <filepath>...\e32ustils\usbmsapp\</filepath>. If you want to include it, use the command line macro below. </p> <p> <b>Note: </b> Add this macro to <filepath>\e32\rombuild</filepath>: </p> <p><userinput>rom --variant=h4hrp --inst=armv5 --build=urel
--type=alltests --symbol --define=ROMOPT_USBMSAPP --name=H4HRPARMV5.IMG</userinput> </p> <p>Start the program from the command prompt with a drive letter
as a parameter: </p> <p><userinput>C:\&gt; usbmsapp d:</userinput> </p> <p>This mounts the specified drive with the Mass Storage file system
('MSFS'). Check that you can see it as a Read/Write disk drive on
the USB host computer. The drive name on the host computer will be
the first free drive letter available. </p> <p> <b>Note: </b> You
can only mount drives marked as 'removable' as USB Mass Storage devices.
The C: drive cannot be marked as 'removable'. Internal drives made
available for USB Mass Storage must be marked as 'removable' for reasons
of platform security. </p> </section>
</conbody></concept>