--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/Adaptation/GUID-C8217A7B-D741-5452-B95B-57B8978AD152.dita	Fri Oct 15 14:32:18 2010 +0100
@@ -0,0 +1,301 @@
+<?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>
\ No newline at end of file