Purpose of the USB-MSD stack

The USB-MSD stack enables you to use your embedded target device as a USB mass storage device. Without the need to develop a kernel mode driver for the host operating system, you can simply plug-in your device and use it just like an ordinary disk drive. This is possible because the mass storage class is one of the standard device classes, defined by the USB Implementers Forum. Virtually every major operating system on the market supports these device classes out of the box.

No custom kernel mode drivers necessary

Since nearly every major OS already provides kernel mode drivers for USB mass storage devices, there is no need to implement your own. Your target device will be recognized as a mass storage device and can be accessed directly.

Plug and Play

Let’s say your target system is a digital camera. Using our USB-MSD stack, you can access videos or photos taken by this camera conveniently with your file system explorer. All you have to do is to connect the camera to the host. That’s all.

Download the trial version for the Atmel AT91SAM7. This version allows you to use an AT91SAM7S chip like a USB mass storage device. The data files (*.bin) of this zip archive are micro controller specific:

AT91SAM7S256_USB_MSD.bin requires an AT91SAM7S256
AT91SAM7S128_USB_MSD.bin requires an AT91SAM7S128
AT91SAM7S64_USB_MSD.bin requires an AT91SAM7S64

Choose the appropriate data file and program the device (for example using a SAM-BA).

Requirements

Target system

Hardware

Your target system must have a USB controller. The memory requirements are approximately 10kB ROM and approx. 1kB of RAM (Only used for buffering—systems with less RAM can also be used). Additionally memory for data storage is required of course, typically either on-board flash memory (parallel or serial) or an external flash memory card is required.

Software

A real-time kernel is required only if your application uses multiple tasks. In case of using the USB-MSD stack as the only task, an RTOS is not needed. The USB-MSD stack requires the USB-Bulk stack which is included.

Development environment

An ANSI-compliant C compiler is required. If your compiler has some limitations, please let us know and we will inform you if they will cause problems when compiling the software. Any compiler for 16/32/64-bit CPUs or DSPs that we know of can be used. Most 8-bit compilers can be used as well.

A C++ compiler is not required, but can be used. The application program can there-fore also be programmed in C++ if desired.

How does it work?

Wide spread support for USB and USB device classes

Almost every major operating system which provides USB support, provides kernel mode drivers for the USB device classes as well. One of those classes is the mass storage class.

Use file system support from host OS

When you plug-in a device which uses the USB-MSD stack, it will be recognized as a mass storage device and can be used like an ordinary disk drive. If the device is unformatted when plugged-in, the host operating system will offer you to format the device. You can use any file system the host provides. Typically FAT is used, but other file systems such as NTFS are possible too. If you use one of those file systems, the host is able to read from and write to the device using the USB-MSD stack storage functions, which define unstructured read and write operations. Thus you don’t need to develop extra file system code if you only want to access the data on the target from the host side. This is typically the case for simple storage applications, such as USB memory sticks or ATA to USB bridges.

Only provide file system code on the target if necessary

If you want to access the target data from within the target application itself, you must provide the necessary file system program code on the target. In this case you may be interested in emFile, Segger’s file system for embedded applications.

FAQs

Do I need a real-time operating system (RTOS) to use the USB-MSD?

No, if your target application is a pure storage application. Yes, if your target has other things to do. You don’t need an RTOS if all you want to do is running the USB-MSD stack as the only task on the target device. If your target application is more than just a storage device and needs to perform other tasks simultaneously, you need an RTOS which handles the multi-tasking.

Do I need a file system to use the USB-MSD stack?

No, if you access the target data only from the host. Yes, if you want to access the target data from within the target itself. There is no extra file system code needed if you only want to access the data on the target from the host side. The host OS already provides several file systems. You have to provide file system program code on the target only if you want to access the data from within the target application itself.

Do I need a kernel mode driver on the host OS ?

No. Using our USB-MSD stack, your target device will be recognized as a mass storage device and the host OS provides the driver out of the box. Simply plug-in your device and use it.

Do I need a USB-Bulk stack?

The USB-MSD stack sits on top of the USB-Bulk stack. The bulk stack is needed to handle lower level USB communication and comes with the USB-MSD software.

Background Information

USB: short overview

The "Universal Serial Bus" (USB) is an external bus architecture for connecting peripherals to a host computer. It is an industry standard—maintained by the USB Implementers Forum—and because of its many advantages it enjoys a huge industry wide following. Over the years a number of USB-capable peripherals appeared on the market, e.g. printers, keyboards, mice, digital cameras etc. Among the top benefits of USB are:

Not only did these benefits lead to broad market acceptance, but this in turn added several advantages as well, such as low costs of USB cables and connectors or a wide range of USB stack implementations. Last but not least the major operating systems such as Microsoft Windows XP, Mac OS X or Linux provide excellent USB support.

Important USB Standard Versions

USB 1.1 (September 1998)

This standard version supports isochronous and asynchronous data transfers. It has dual speed data transfer of 1.5 Mb/s for low speed and 12 Mb/s for full speed devices. The maximum cable length between host and device is five meters. Up to 500 mA of electric current may be distributed to low power devices.

USB 2.0 (April 2000)

As all previous USB standards, USB 2.0 is fully forward and backward compatible. Existing cables and connectors may be reused. A new "high speed" transfer speed of 480 Mb/s (40 times faster than USB 1.1 at full speed) was added.

USB System Architecture

A USB system is composed of three parts, a host side, a device side and a physical bus. The physical bus is represented by the USB cable and connects host and device. The USB system architecture is asymmetric. Every single host can be connected to multiple devices in a tree-like fashion using special hub devices. You can connect up to 127 devices to a single host, but the count must include the hub devices as well.

USB Host

A USB host consists of a USB host controller hardware and a layered software stack. This host stack contains a host controller driver (HCD) which provides the functionality of the host controller hardware, the USB Driver (USBD) Layer which implements the high level functions used by USB device drivers in terms of the functionality provided by the HCD, and finally the USB Device drivers which establish connections to USB devices. The driver classes are also located here and provide generic access to certain types of devices such as printers or mass storage devices.

USB Host

Two divisions of devices exist: hubs and functions. Hubs provide the ability to provide additional USB attachment points. Functions provide capabilities to the host and are able to transmit or receive data or control information over the USB bus. Every peripheral USB device represents at least one function but may implement more than one function. A USB printer for instance may provide file system like access in addition to printing.

In this manual we treat the term USB device as synonymous with functions and won’t consider hubs.

Each USB device contains configuration information which describe its capabilities and resource requirements. Before it can be used, USB devices must be configured by the host. When a new device is connected for the first time, the host enumerates it, requests the configuration from the device and performs the actual configuration. In case of our USB-MSD software, your embedded device will appear as a USB Mass Storage device and the host OS provides the driver out of the box. This relieves you from the necessity to develop a custom driver to communicate with your target device.

Descriptors

A device reports its attributes via descriptors. Descriptors are data structures with a standard defined format. A USB device has one device descriptor which contains information applicable to the device and all of its configurations. It also contains the number of configurations the device supports. For each configuration a configuration descriptor contains configuration specific information. The configuration descriptor also contains the number of interfaces provided by the configuration. An interface groups the endpoints into logical units. Each interface descriptor contains information about the number of endpoints. Each endpoint has its own endpoint descriptor which states the endpoint’s address, transfer types etc.

As can be seen, the descriptors form a tree. The root is the device descriptor with n configuration descriptors as children, each of which has m interface descriptors which in turn have k endpoint descriptors each.

Transfer Types

The USB standard defines 4 transfer types: control, isochronous, interrupt and bulk. Control transfers are used in the setup phase. The application can basically select one of the other 3 transfer types. For most embedded applications, bulk is the best choice since it allows the highest possible data rates.

Control transfers

Typically used to configure a device when attached to the host. It may also be used for other device specific purposes, including control of other pipes on the device.

Isochronous transfers

Typically used for applications which need guaranteed speed. Isochronous transfer is fast but with possible data loss. A typical use is audio data which requires a constant data rate.

Interrupt transfers

Typically used by devices that need guaranteed quick responses (bounded latency).

Bulk transfers

Typically used by devices that generate or consume data in relatively large and bursty quantities. Bulk transfer has wide dynamic latitude in transmission constraints. It can use all remaining available bandwidth, but with no guarantees on bandwidth or latency. Since the USB bus is normally not very busy, there is typically 90% or more of the bandwidth available for USB transfers.

Setup phase / Enumeration

The host first needs to get information from the target, before the target can start communicating with the host. This information is gathered in the initial setup phase. The information is contained in the descriptors, which are in the configurable section of the USB-MSD stack. The most important part of target device identification are the product and vendor IDs. During the setup phase, the host also assigns an address to the client. This part of the setup is called enumeration.

Product / vendor IDs

A vendor ID can be obtained from the USB Implementers Forum, Inc. (www.usb.org). This is necessary only when you finish development of the product; during the development phase, you can use the vendor and product IDs supplied as samples.

MSD

Command Protocols

The USB-MSD stack supports the SCSI transparent command set (06h) only.

Transport Protocols

The USB-MSD stack supports bulk-only transport (50h) only.

References

For additional information see the following documents: