Test and Validation of uC-USB-Device

This page gives details about the various tests done on the µC/USB-Device stack.

Before being released, the µC/USB-Device stack undergoes a series of test, to make sure that it respects the USB 2.0 specification. This page describes the tests that the Core, Classes and USB Device Drivers must pass before they are each released and a small description of every test.

List of Tests

Description

USB 2.0 Command Verifier

The USB 2.0 Command Verifier (USBCV) is a tool created by the USB Implementer Forum (USB-IF) to test the compliance of a given device to the USB 2.0 Specification. A USB device must successfully pass all of these tests in order to obtain the USB certification.

Chapter 9

This series of test exercises the control endpoints transfers paths and the control transfers sequence (Setup, Data, Status). It also makes sure that the device handles correctly the standard requests and that the standard descriptors obtained are correctly built.

Class-Specific Tests

USBCV also implements tests for some of the USB classes available with µC/USB-Device.Theses classes are: HID Class, MSC and PHDC.

For the HID class, USBCV tests the validity of the sent and received descriptors and the 'Set Idle' Class Request.

For MSC, the descriptors, the class requests and the protocol are tested. USBCV also performs a series of test cases, including error recovery, valid and invalid data transfers, faulty transfer sequence, etc and monitors the device's response to these test cases. That is, it makes sure that the device succeeds where it should and fails and recovers when required.

In the case of PHDC, USBCV will test the validity of the descriptors and the class and standard requests. It will also test the reliability and latency of the transfers, as specified in the PHDC specification. USBCV will also execute tests related to the protocol, making sure that the device answers correctly to the various requests and stalls whenever required.

Classes Demo Application

Audio Class

The audio class is tested with two different demo applications. The simplest one is a microphone-only example that transmits a pre-selected waveform to the host PC. This exercises the class requests, including the Set Sampling Frequency, Set Volume, Mute/Un-mute and the Start/Stop Streaming Interface. It also tests the isochronous transmit path and the queuing mechanism. The other demo application is a loopback that simply echoes back to the host PC what it just received from it. It tests both isochronous transfer paths (transmit and receive) and the queuing mechanism. It also tests the descriptors and standard requests related to the Audio class.

CDC-ACM

The CDC-ACM test is a terminal-based application that echoes characters back to the host PC. Using a serial terminal on the host PC, it is possible to exchange data with the device. This tests the correct handling of various class/subclass requests and the Bulk synchronous transfer IN and OUT path.

HID Class

The HID class can be tested by two different applications. The first one is a simple mouse emulator. It sends data to the host PC as if it was a simple mouse moving back and forth every 1ms. This test allows to make sure the interrupt asynchronous IN path works correctly and that the descriptors, reports and class requests are in compliance with the HID class specification. The other HID demo application is composed of two tasks: one 'read' and one 'write' task. It allows the device to exchange data with the host PC as a custom HID device would. It exercises the synchronous interrupt IN and OUT transfer paths.

MSC

The MSC demo application consists in a RAM-based USB key. It acts exactly as a USB flash drive would, except that its content is volatile and will not be kept if it loses power. This allows to test the bulk transfers paths (IN and OUT), the composition of the descriptors, the compliance with the MSC protocol and the class requests. It also allows to test the interaction between a MSC device and various host operating systems.

PHDC

The PHDC demo application is a basic console application displaying various statistics of the platform (CPU Usage and Timer, for example). It tests the descriptors, the various class requests and the bulk IN and OUT and interrupt IN transfers paths. It also allows to experiment with the various QoS available.

Vendor Class

The Vendor class demo application exchanges data between the host PC and the device by following a known protocol. This exercises the bulk IN and OUT synchronous and asynchronous transfers paths and the correct handling of large transfers. It can also be used to test vendor class requests.

Other Tests

Audio Typical Usage Test

If an audio codec and its associated driver are available, they will be tested by the following typical applications: microphone-only, speaker-only and headset (microphone and speaker). Class requests supported by the audio codec and its driver will also be tested.

MSC Storage Test

This test is the same than the RAM-based one, except another storage medium is used.

Control Endpoint Transfer Test

This custom test sends and receives data by the default control endpoint. It can execute larger transfers than what is expected during a typical enumeration, testing the case when several transactions are required for a single transfer. Also, since control OUT transfers are infrequent during enumeration and basic usage, this tests them more thoroughly.

Zero-Length Packet Test

This custom test verifies the correct handling of zero-length packets when execute transfers of unknown size. For example, if the device expects up to 3000 bytes and that it only receives 1024 bytes, which is a multiple of the maximum packet size (8, 16, 32, 64 or 512 (high-speed only) bytes), the host needs to send a zero-length packet to indicate that the transfer is completed and the device must be able to accept and interpret correctly this zero-length packet.