01003a.pdf

(970 KB) Pobierz
AN1003
USB Mass Storage Device Using a PIC
®
MCU
Author:
Gurinder Singh
Microchip Technology Inc.
• Files created using FAT16, FAT32 or NTFS file
format supported (see
“References”).
• SD and MMC cards supported (see
“References”).
• Uses the Windows operating system storage
driver,
usbstor.sys.
The Windows Server 2003,
Windows XP, Windows 2000 and Windows Me
operating systems provide native support for USB
Mass Storage Class devices. Therefore, MSD is
compatible with these operating systems.
Version 1.0 of the MSD has the following limitations
(later revisions will have additional features):
• Does not support the Windows 98 operating
system (see
Appendix A: “Frequently Asked
Questions”
for details).
• Does not support the FAT12 file system. In
general, small capacity SD cards (i.e., <= 16 MB)
can only be formatted in a FAT12 file system.
• If the SD card is removed, the USB cable must be
disconnected and reconnected after the card has
been reinserted.
• The SD card must be present at power-up.
Note:
The implementation and use of the FAT file
system, SD card specifications, MMC card
specifications and other third party tools
may require a license from various entities,
including, but not limited to Microsoft
®
Corporation, SD Card Association and
MMCA. It is your responsibility to obtain
more information regarding any applicable
licensing obligations. Some third party web
sites have been listed in
“References”
for
your convenience.
INTRODUCTION
In recent years, there has been immense growth in
Universal Serial Bus (USB) based applications,
primarily due to the Plug and Play nature of USB.
This application note describes the design and
implementation of a USB Mass Storage Device (MSD)
using a Secure Digital card, which should prove useful
to developers of USB mass storage solutions. This
application may be used as a stand-alone MSD or as a
Secure Digital/Multimedia Card (SD/MMC) reader/
writer interface.
This design consists of the following components:
•
•
•
•
USB V2.0 compliant PIC18F4550 microcontroller
PICDEM™ FS USB Demonstration Board
PICtail™ Board for SD™ and MMC Cards
Windows
®
operating system compatible
(Me, 2000, XP and Windows Server™ 2003)
Figure 1 shows the hardware configuration of the
MSD. The PICtail™ Board for SD™ and MMC Cards
(check the Microchip web site for availability) is
connected into a socket on the PICDEM™ FS USB
Demonstration Board. For additional details, refer to
the PICDEM FS USB Demonstration Board User’s
Guide (see
“References”).
The MSD design has the following features:
• USB V2.0 full-speed compliant.
• No custom drivers required (Windows operating
system built-in driver,
usbstor.sys,
is used).
FIGURE 1:
MSD HARDWARE CONFIGURATION
©
2005 Microchip Technology Inc.
DS01003A-page 1
AN1003
USB
A device endpoint is defined in the USB V2.0
specification as “a
uniquely addressable portion of USB
device that is the source or sink of information in a
communication flow between the host and device”
(see
“References”).
The unique address required for each
endpoint consists of an endpoint number (which may
range from 0 to 15) and direction (IN or OUT). The
endpoint direction is from the host’s perspective; IN is
towards the host and OUT is away from the host. An
endpoint configured to do control transfers must
transfer data in both directions, so a control endpoint
actually consists of a pair of IN and OUT endpoints that
share an endpoint number. All USB devices must have
Endpoint 0 configured as a control endpoint.
USB V2.0 supports four types of data transfers:
Control, Bulk, Interrupt and Isochronous.
Control
transfer is used to configure a device at the
time of plug-in and can be used for other device-
specific purposes, including control of other pipes on
the device.
Bulk
data transfers are used when the data is generated
or consumed in relatively large, bursty quantities.
Interrupt
data transfers are used for timely, but
reliable, delivery of data. For example, characters or
coordinates with human perceptible echo or feedback
response characteristics.
Isochronous
data transfers occupy a pre-negotiated
amount of USB bandwidth with pre-negotiated delivery
latency (also called streaming real-time transfers).
For any given device configuration, an endpoint sup-
ports only one of the types of transfers described
above. In this application, apart from Endpoint 0, we
configure Endpoint 1 IN and OUT as bulk endpoints.
To meet the needs of various applications using USB,
three speeds of operation have been designed in the
USB V2.0 specification: Low-Speed (LS, 1.5 Mbps),
Full-Speed (FS, 12 Mbps) and High-Speed (HS,
480 Mbps).
See
“References”
for detailed information on USB,
including references to the USB specification and USB
related publications.
The PIC18F4550 used in this application is USB V2.0
compliant and can support LS and FS data transfers.
For more information on the PIC18F4550, refer to the
the device data sheet (see
“References”).
Configuration Descriptor
Enumeration
Before the applications can communicate with the
device, the host needs to learn about the device and
assign a device driver. Enumeration is defined as the
initial exchange of information that accomplishes this.
During the enumeration process, the device moves
through the following device states as defined by the
USB V2.0 specification: Powered, Default, Address
and Configured. Two other USB device states are:
Attached and Suspend. Exact details of the enumera-
tion process are beyond the scope of this document;
however, the commands and structures used in the
device configuration are briefly described.
Descriptors are data structures that enable the host to
learn about a device. During enumeration, the host
requests descriptors, starting from high-level device
descriptors to low-level endpoint descriptors, in the
sequence shown in Figure 2. The structure, description
and values of device, configuration and interface
descriptors are detailed in
Appendix C: “USB
Descriptor Formats”.
A code example of descriptor
structures is provided in
Appendix D: “USB
Descriptor Structures”.
Details of bulk-only endpoint
descriptors can be found in
Appendix F: “Bulk
Endpoint Descriptors”.
FIGURE 2:
STANDARD USB
DESCRIPTORS
Device Descriptor
Interface Descriptor
Endpoint Descriptor
DS01003A-page 2
©
2005 Microchip Technology Inc.
AN1003
ENUMERATION PROCESS
The following summarizes the steps involved in the
enumeration of a USB device and explains how the
device goes from Powered to Default, Address and the
Configured state during the enumeration process.
1.
User plugs a USB device into a USB port. The
hub provides power to the port and the device is
in the Powered state.
The hub detects the device.
The hub uses an interrupt pipe to report the
event to the host.
Host sends
Get_Port_Status
request to
obtain more information about the device.
Hub detects whether device is Low-Speed or
Full-Speed operation and sends the information
to the host in response to
Get_Port_Status.
Host sends a
Set_Port_Feature
request,
asking the hub to reset the port.
Hub resets the device.
Host learns if a Full-Speed device supports
High-Speed operation (using Chirp K signal).
Host verifies if the device has exited the Reset
state using
Get_Port_Status.
At this point, the device is in the Default state
(device is ready to respond to control transfers
over the default pipe at Endpoint 0, default
address is 00h and the device can draw up to
100 mA from the bus).
Host sends
Get_Descriptor
to learn the
maximum packet size (Note: eighth byte of the
device descriptor is
bMaxPacketSize).
The host assigns an address by sending a
Set_Address
request. Device is now in the
Address state.
Host sends
Get_Descriptor
to learn more
about the device. The host responds by sending
the descriptor followed by all other subordinate
descriptors.
Host assigns and loads a device driver.
Host’s device driver selects a configuration by
sending a
Set_Configuration
request. The
device is now in the Configured state.
Host assigns drivers for interfaces in composite
devices.
If the hub detects an overcurrent, or if the host
requests the hub to remove power, the device
will be unpowered by the USB bus. In this case,
the device and host cannot communicate and
the device is in the Attached state.
If the device does not see any activity on the bus
for 3 ms, it goes into the Suspend state. The
device consumes minimal bus power in this
state.
Control Transfer
Control transfer enables the host and the device to
exchange information about device configuration and
other control messages. Control transfers are ensured
to have 10 percent of the bandwidth at Low-Speed and
Full-Speed operation and 20 percent at High-Speed
operation. A control transfer consists of a Setup stage,
an optional Data stage and a Status stage.
Appendix E: “Standard USB Device Requests”
summarizes the 11 USB standard control transfer
requests, along with a description of each request. All
USB devices must respond to these requests (even
though the response may be just a STALL). Note that
apart from the standard requests, a class may define
requests for devices in its class. A class-specific
request may be required or optional. For example,
Mass Storage Devices may implement the
Get Max LUN
(Logical Unit Number) request that is
used by the host to find out the number of logical units
the device supports. The class-specific requests for
the Mass Storage Devices are discussed in
“Mass
Storage Class”.
2.
3.
4.
5.
6.
7.
8.
9.
10.
Mass Storage Class
Bulk transfers are useful for transferring data when
time is not a critical factor. Only High-Speed and Full-
Speed devices can do bulk transfers. A bulk transfer
can send large amounts of data without overloading the
bus because it waits for the availability of the bus. The
Mass Storage Class supports two transport protocols
that determine which transfer type the device and host
use to send command, data and status information.
These two types of transport protocols are:
• Bulk-Only Transport (BOT)
• Control/Bulk/Interrupt (CBI) Transport
BOT is a data transport protocol that uses Bulk
transport, whereas CBI transport uses Control transfer,
Bulk transport and Interrupt transfer. CBI is further
subdivided into a data transport protocol that uses
Interrupt transfer and one that does not use Interrupt
transfer. In this application, BOT is used as the data
transport protocol.
11.
12.
13.
14.
15.
16.
17.
18.
©
2005 Microchip Technology Inc.
DS01003A-page 3
AN1003
The Mass Storage Class specification (see
“References”)
defines two class-specific requests,
Get
Max LUN
and
Mass Storage Reset,
that must be
implemented by a Mass Storage Device. Bulk-Only
Mass Storage Reset (bmRequestType
= 00100001b
and
bRequest = 11111111b)
is used to reset the
Mass Storage Device and its associated interface.
Get
Max LUN
(bmRequestType
= 10100001b
and
bRequest
=
11111110b)
request is used to
determine the number of logical units supported by the
device. The value of Max LUN can vary between 0 and
15 (1-16 logical devices). Note that the LUN starts from
0. The device may share multiple logical units that
share the common device characteristics. The host
should not send the Command Block Wrapper (CBW)
to a non-existing LUN.
The interface descriptor fields for configuring an
interface as a Mass Storage Device implementing the
BOT are shown in
Appendix C: “USB Descriptor
Formats”.
Note that
bInterfaceClass
= 08h
implies Mass Storage Class. Subclass code,
bInterfaceSubClass
= 06h, indicates that SCSI
Primary Command-2 (SPC-2) definitions (see
“Ref-
erences”)
are supported by the device and the
bInterfaceProtocol
= 50h indicates the BOT
implementation.
A device implementing BOT shall support at least three
endpoints: Control, Bulk-In and Bulk-Out. The USB
V2.0 specification defines a control endpoint
(Endpoint 0) as the default endpoint that does not
require a descriptor. The Bulk-In endpoint is used for
transferring data and status from the device to the host,
and the Bulk-Out endpoint is used for transferring
commands and data from the host to the device. The
endpoint descriptor values for configuring a Bulk-In and
Bulk-Out endpoint are shown in
Appendix F: “Bulk
Endpoint Descriptors”.
Appendix G: “CBW and CSW”
shows the format of a
CBW packet. In the CBW, the
dCBWSignature
value,
“43425355h” (little-endian), identifies a CBW packet.
dCBWTag
is the command block tag that is echoed
back in CSW to associate the CSW with the
corresponding CBW.
dCBWDataTransferLength
indicates the number of bytes the host expects to trans-
fer on a Bulk-In or Bulk-Out endpoint (as indicated by
the
Direction
bit). Only bit 7 of
bmCBWFlags
is used
to indicate the direction of data flow, with a ‘1’ signifying
Data-In (i.e., from device to host). The field,
bCBWLUN,
specifies the device LUN to which the command block
is being sent. The field,
bCBWCB,
defines the valid
length of the command block. The
CBWCB
is the
command block to be executed by the device.
The size of a CSW is 13 bytes in length. A
dCSWSignature
value of “54425355h” (little-endian)
identifies a CSW packet. The field,
dCSWTag,
echoes
the
dCSWTag
value from the associated CBW. For
Data-Out,
dCSWDataResidue
is the difference
between the data expected and the actual amount of
data processed by the device. For Data-In, it is the dif-
ference between the data expected and the actual
amount of relevant data sent by the device. The value
of
dCSWDataResidue
is always less than or equal to
the value of
dCBWDataTransferLength.
The value
of
bCSWStatus
indicates the success or failure of the
command. The
bCSWStatus
value of 00h indicates
command success, 01h indicates command failure,
whereas 02h indicates phase error.
FIGURE 3:
COMMAND/DATA/STATUS
FLOW IN BULK-ONLY
TRANSPORT
Ready
Bulk-Only Transport (BOT)
Like Control transfer, BOT also consists of a Command
stage, an optional Data stage and a Status stage. The
Data stage may or may not be present for all command
requests. Figure 3 shows the flow of Command trans-
port, Data-In, Data-Out and Status transport for BOT.
The CBW is a short packet of exactly 31 bytes in length.
The CBW and all subsequent data and Command Sta-
tus Wrapper (CSW) start on a new packet boundary. It
is important to note that all CBW transfers are ordered
little-endian with LSB (byte 0) first.
Command
Transport
(CBW)
Data-Out
(from host)
Data-In
(to host)
Status
Transport
(CSW)
DS01003A-page 4
©
2005 Microchip Technology Inc.
AN1003
Secure Digital (SD) Card
A Secure Digital card is the most common storage
media used in portable devices, such as PDAs, Digital
Cameras and MP3 Players, among others. SD cards
can be purchased with storage sizes ranging from
16 MB to 2 GB. Both SD cards and the MMC support
the SPI™ transfer protocol and have an almost identi-
cal electrical interface. While the form factor and the
shape of the SD card and the MMC are identical, SD
cards can be operated up to four times faster, have a
write-protect switch and may include cryptographic
security for protection of copyrighted data. Due to these
features, SD cards are more popular than MMC and
are the focus of this design. However, MMC have been
tested and found to be fully functional with the MSD
design.
The SD card can be operated in SD Bus mode or SPI
mode. In this application, the SD card is connected to
the Serial Peripheral Interface (SPI) bus of the
PIC18F4550 and operated in the SPI mode. In the SPI
mode, only one data line is used for data transmission
in each direction. The data transfer rate in this mode is
therefore the same as the SD Bus mode with one data
line (up to 25 Kbits per second).
Apart from the Power and Ground, the SPI bus consists
of Chip Select (CS), Serial Data Input (SDI), Serial Data
Output (SDO) and Serial Clock (SCLK) signals. The SD
card and MMC sample data input on the rising clock
edge and set data output on the falling clock edge. On
power-up, an SD card wakes up in the SD Bus mode.
Therefore, an initialization routine is required to operate
the SD card in SPI mode. This can be achieved by
asserting the CS signal (logic low) during the reception
of the Reset command, CMD0. Unlike the SD Bus
mode, in SPI mode, the selected card always responds
to the command. In case of a data retrieval problem,
the card responds with an error response instead of a
time-out as in the SD Bus mode. See
“References”
for
information on the SD card specification.
COMMUNICATION OVERVIEW
This section provides a general overview of the com-
munication between the SD card and the Personal
Computer (PC) application and system hardware.
Figure 4 shows the functional block diagram of the
entire system. A device driver is defined as “any
code
that handles communication details for a hardware
device that interfaces to a CPU”.
In the layered driver
model used in USB communications, each layer
handles one part of the communication process. In this
application, the MSD is enumerated as a Mass Storage
Device implementing BOT. Therefore, the host uses
the USB storage device driver (usbstor.sys) as the
functional driver. The host loads
Disk.sys,
PartMgr.sys
and
VolSnap.sys
as filter drivers to
communicate between the end application and the
device driver (usbstor.sys). The root hub driver
(usbhub.sys) manages the port initialization and, in
general, manages the communications between
device drivers and the bus class driver. The bus class
driver (usbd.sys) manages bus power, enumeration,
USB transactions and communications between the
root hub driver and the host controller driver.
On the MSD application side, the Serial Interface
Engine (SIE) of the PIC18F4550 handles the low-level
USB communications. USB data moves between the
microcontroller core and the SIE through a memory
space known as the USB RAM. The PIC18F4550
provides the capability to configure and control up to
16 bidirectional endpoints. In this application, two
bidirectional endpoints are used. Endpoint 0 is required
for all USB devices for control transfers and does not
require configuration. The mass storage application
configures Endpoint 1 IN and OUT as bulk endpoints
for Bulk-Only Transport. It also communicates with the
SD card’s SPI bus to read the data from and write the
data to the SD card.
©
2005 Microchip Technology Inc.
DS01003A-page 5

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika:

Zgłoś jeśli naruszono regulamin