Microchip Technology AN1003 User manual

深圳市英锐恩科技有限公司
Add:深圳市福田区福华路嘉汇新城汇商中心 27 楼2701 http://www.Enroo-Tech.com
Tel:[phone], Fax: [phone] http://www.Enroo.com
圣邦微电子(SG MICRO CORP)
PICDEM_HPC AN1003产品用户参考手册
深圳市英锐恩科技有限公司
ENROO-TECH（SHENZHEN）CO.,LTD
中国·深圳市福田区福华路嘉汇新城汇商中心27楼2701
Enroo-Tech Technologies CO., Limited
Light-Tech International Limited
香港新界荃灣沙咀道 29-35 號科技中心 5樓5室
联系电话：86-755-82543411,83167411,83283911,61357155, 88845951
联系传真：86-755-82543511
联系邮件：[e-mail]
公司网站：http://www.enroo.com http://www.enroo-tech.com
英锐恩科技时刻为您提供技术支持;提供开发应用协助;提供成熟方案;提供免费样品;提供详细
资料,提供销售服务。
单片机集成方案全方位解决服务商
优质智能电子产品“芯”方案解决商

©2005 Microchip Technology Inc. DS01003A-page 1
AN1003
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).
• 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.
FIGURE 1: MSD HARDWARE CONFIGURATION
Author: Gurinder Singh
Microchip Technology Inc.
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.
USB Mass Storage Device Using a PIC®MCU
深圳市英锐恩科技有限公司
www.enroo-tech.com

AN1003
DS01003A-page 2 ©2005 Microchip Technology Inc.
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”).
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
Configuration Descriptor
Interface Descriptor
Endpoint Descriptor
深圳市英锐恩科技有限公司
www.enroo-tech.com

©2005 Microchip Technology Inc. DS01003A-page 3
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.
2. The hub detects the device.
3. The hub uses an interrupt pipe to report the
event to the host.
4. Host sends Get_Port_Status request to
obtain more information about the device.
5. Hub detects whether device is Low-Speed or
Full-Speed operation and sends the information
to the host in response to Get_Port_Status.
6. Host sends a Set_Port_Feature request,
asking the hub to reset the port.
7. Hub resets the device.
8. Host learns if a Full-Speed device supports
High-Speed operation (using Chirp K signal).
9. Host verifies if the device has exited the Reset
state using Get_Port_Status.
10. 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).
11. Host sends Get_Descriptor to learn the
maximum packet size (Note: eighth byte of the
device descriptor is bMaxPacketSize).
12. The host assigns an address by sending a
Set_Address request. Device is now in the
Address state.
13. Host sends Get_Descriptor to learn more
about the device. The host responds by sending
the descriptor followed by all other subordinate
descriptors.
14. Host assigns and loads a device driver.
15. Host’s device driver selects a configuration by
sending a Set_Configuration request. The
device is now in the Configured state.
16. Host assigns drivers for interfaces in composite
devices.
17. 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.
18. 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”.
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.
深圳市英锐恩科技有限公司
www.enroo-tech.com

AN1003
DS01003A-page 4 ©2005 Microchip Technology Inc.
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”.
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.
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
Command
Data-In
(to host)
Data-Out
(from host)
Transport
(CBW)
Status
Transport
(CSW)
深圳市英锐恩科技有限公司
www.enroo-tech.com

©2005 Microchip Technology Inc. DS01003A-page 5
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.
深圳市英锐恩科技有限公司
www.enroo-tech.com

AN1003
DS01003A-page 6 ©2005 Microchip Technology Inc.
Hardware
The PICDEM FS USB Demonstration Board is used as
the platform for developing the USB MSD application.
The PICtail™ Board for SD™ and MMC Cards is
connected on the expansion headers, J6 and J7, on the
PICDEM FS USB Demonstration Board. The USB V2.0
compliant PIC18F4550 microcontroller forms the heart
of the PICDEM FS USB Demonstration Board. The
PIC18F4550 has an on-chip USB voltage regulator,
transceivers and pull-up resistors to minimize the
number of external components and enable a low-cost
design. On a side note, the PICDEM FS USB
Demonstration Board also features a potentiometer,
simulating analog input for the controller and a digital
temperature sensor. While not being used in the USB
SD card mass storage application, these features may
be useful in developing other USB applications. More
details of the PICDEM FS USB Demonstration Board
can be found in the PICDEM FS USB Demonstration
Board User’s Guide (see “References”).
FIGURE 4: PC, MSD COMMUNICATION BLOCK DIAGRAM
PC Application
(e.g., file explorer)
Win32 Subsystem
Function
Drivers
(usbstor.sys)
Bus Drivers (usbd.sys)
Win32®API Calls
Hardware (Root Hub)
USB Hub Driver (usbhub.sys)
Disk Drivers
(disk.sys,
PartMgr.sys)
Storage Volume
Driver
(VolSnap.sys)
SPI™
Bus
USB Port
USB Serial Interface Engine (SIE)
SD Card Interface
(sdcard.c, sdcard.h)
USB Endpoint 0
Control
Transfer
(usbdrv.c,
usb9.c,
usbctrltrf.c)
USB Endpoint 1
Bulk Transfer
(msd.c, msd.h)
PIC18F4550
EP0 USB Control, EP1 SCSI Commands
PICtail™ Board for
SD™ and MMC Cards
深圳市英锐恩科技有限公司
www.enroo-tech.com

©2005 Microchip Technology Inc. DS01003A-page 7
AN1003
The SD card operates in the 2.7-3.6V range, whereas the
PIC18F4550 on the PICDEM FS USB Demonstration
Board requires a 5V VDD. The voltage regulation from 5V
to 3V is achieved using Microchip’s TC1186-3.3VCT713.
Appendix J: “Schematic” shows the schematic for the
PICtail™ Board for SD™ and MMC Cards (Part No.
AC164122). Pin 7 (RA5) of the PIC18F4550 is connected
to the SHDN (Shutdown input) pin of the TC1186 via
jumper JP4 (position 2-3). This enables the user to turn
off the SD card power using firmware (setting RA5 turns
the power on). Alternately, by changing the jumper JP4
setting (position 1-2), the user may turn the SD card
power on permanently. The PICtail™ Board for SD™
and MMC Cards also implements two MC74VHCT125A
devices as signal level translators for translating 5V DC
signals on the microcontroller side to 3.3V DC signals on
the SD card side and vice versa. The MC74VHCT125A
is a high-speed CMOS quad buffer fabricated with silicon
gate CMOS technology. Since it has a full 5.0V CMOS
level output swing, this device is ideal for signal level
translation between 3.0V and 5.0V levels. For 5V to 3.3V
signal translation, a supply voltage of 3.3V is applied to
U1 and corresponding OE pins are enabled (active-low).
Similarly, 3.3V to 5V translation is achieved by applying a
5V supply to U2 and enabling the corresponding OE
pins. Further details on the MC74VHCT125A can be
found in its respective data sheet (see “References”).
The PICtail™ Board for SD™ and MMC Cards also
features a power LED (D1), an SD card activity LED
(D2) and test points for monitoring the SPI bus. LED D1
indicates that power is available at the output of the
TC1186. LED D2 indicates SD card activity (based on
Chip Select signal, CS). The Serial Data Input (SDI),
Serial Clock (SCK), Serial Data Output (SDO), Chip
Select (CS) and Ground (GND) signals of the SPI bus
can be monitored on the test points. The PICtail™
Board for SD™ and MMC Cards is designed to operate
with a multitude of demonstration boards, including all
demonstration boards having PICtail signals, Explorer
16 development board having card edge connectors
and demonstration boards with non-standard PICtail
signals. The following jumper settings must be used for
operating the PICtail™ Board for SD™ and MMC
Cards with different demonstration boards.
1. If the demonstration board has standard PICtail
signals, connect JP1-JP2 and JP5 on the PICtail
side (default setting).
2. If the demonstration board provides card edge
signals, connect JP2-JP3 and JP5 on the card
edge side.
3. If the demonstration board does not provide
standard PICtail signals, open J3, jump signals
from J5 and J11 to appropriate signals on J2.
SCSI Commands
After the successful enumeration of the target USB
device, the host initiates commands according to the
bInterfaceSubClass specified in the interface
descriptor during the enumeration process.
The USB MSD application specifies bInterface-
SubClass = 06h, indicating that the device will support
SCSI Primary Commands-2 (SPC-2) or later. A
bInterfaceProtocol value of 0x50 in the interface
descriptor indicates that the BOT protocol is being
used. As shown in Figure 3, a BOT transfer begins with
a CBW. The device indicates the successful transport
of a CBW by accepting (ACKing) the CBW. If the host
detects a STALL of the Bulk-Out endpoint during Com-
mand transport, the host shall respond with a Reset
recovery. The host shall attempt to transfer an exact
number of bytes to or from the device as specified by
the dCBWDataTransferLength and the Direction
bit. The device shall send each CSW to the host via the
Bulk-In endpoint.
In this section, we briefly describe the SCSI commands
that are supported in the MSD implementation. The
reader may refer to SCSI Primary Commands-3 (SPC-3)
and SCSI Block Commands-2 (SBC-2) specifications for
further details (see “References”). The first byte of the
command block, CBWCB, is always the operation code or
opcode in short.
•INQUIRY (Opcode 12h)
The INQUIRY command requests that the informa-
tion regarding the logical unit and SCSI target device
be sent to the application client (host). The SPC-3
specification requires that the INQUIRY data should
be returned even though the device server is not
ready for other commands. Moreover, the standard
INQUIRY data should be available without incurring
any media access delays. The standard INQUIRY
data is at least 36 bytes.
•READ CAPACITY (Opcode 25h)
The READ CAPACITY command requests that the
device server transfer bytes of parameter data
describing the capacity and medium format to the
Data-In buffer. The response to the READ CAPACITY
command is 4 bytes of returned Logical Block
Address and 4 bytes of block length in bytes.
Returned Logical Block Address (LBA) is the
LBA of the last logical block on the direct access
block device. If the number of logical blocks exceeds
the maximum value that can be specified in the
returned Logical Block Address field, the
device shall set the returned Logical Block
Address field to FFFFFFFFh.
Note: The user application may not require the
signal translation if the PIC microcontroller
is operated at 3V.
深圳市英锐恩科技有限公司
www.enroo-tech.com

AN1003
DS01003A-page 8 ©2005 Microchip Technology Inc.
•READ (10) (Opcode 28h)
The READ (10) command specifies that the device
server read the specified logical block(s) and transfer
them to the Data-In buffer. The READ (10) com-
mand is a 10-byte CBWCB with the eighth and ninth
bytes specifying the TRANSFER LENGTH (see
Appendix I: “SCSI Command and Data Format”).
The TRANSFER LENGTH field specifies the number
of contiguous logical blocks of data that shall be read
and transferred to the Data-In buffer, starting with the
logical block specified by the Logical Block
Address field (bytes 3-6). A TRANSFER LENGTH
field set to zero specifies that no logical blocks shall
be read.
•WRITE (10) (Opcode 2Ah)
The WRITE (10) command requests that the device
server transfer the specified logical blocks from the
Data-Out buffer and write them. The CBWCB format
for the WRITE (10) command is the same as the
READ (10) command with TRANSFER LENGTH
specifying the number of contiguous logical blocks of
data that shall be transferred from the Data-Out
buffer and written, starting with the logical block
specified by the Logical Block Address field. A
TRANSFER LENGTH field set to zero specifies that no
logical blocks shall be written.
•REQUEST SENSE (6) (Opcode 03h)
The REQUEST SENSE (6) command requests that
the device server transfer the sense data to the
application client. Appendix H: “SCSI Command
Set” shows the fixed format sense data response.
The contents of the RESPONSE CODE field indicate
the error type and format of the sense data. The
RESPONSE CODE 70h signifies the current error,
RESPONSE CODE 71h signifies the deferred error in
the fixed format sense data and code values, 72h
and 73h, indicate the current and deferred error code
in the descriptor format sense data. The SENSE
KEY, ADDITIONAL SENSE CODE (ASC) and
ADDITIONAL SENSE CODE QUALIFIER (ASCQ)
fields provide a hierarchy of information. The SENSE
KEY field indicates the generic information describing
an error or exception condition, ASC indicates further
information related to the error reported in the SENSE
KEY field, whereas the ASCQ field indicates the
detailed information related to the ADDITIONAL
SENSE CODE. Refer to Table 27 and Table 28 of the
SPC-3 specification (see “References”) for a list of
SENSE KEY error codes and ASC and ASCQ error
code assignments. This application implements the
fixed format, current error code sense data response
(defined in ~\system\usb\class\msd\msd.h).
•MODE SENSE (6) (Opcode 1Ah)
The MODE SENSE (6) command provides a means
for a device server to report parameters to an appli-
cation client. It is a complementary command to the
MODE SELECT (6) command. The mode parameter
header that is used by the MODE SENSE (6) and the
MODE SELECT (6) command is shown in Appen-
dix H: “SCSI Command Set”.The MEDIUM TYPE
and DEVICE SPECIFIC PARAMETER fields are
unique for each device type. In this application, the
MEDIUM TYPE field is set to 00h, indicating a direct
access block device. This value is the same as the
value of the PERIPHERAL DEVICE TYPE field in the
standard INQUIRY data.
•PREVENT ALLOW MEDIUM REMOVAL
(Opcode 1Eh)
The PREVENT ALLOW MEDIUM REMOVAL command
requests that the logical unit enable or disable the
removal of the medium. The prevention of medium
removal shall begin when an application client issues
a PREVENT ALLOW MEDIUM REMOVAL command
with a PREVENT field (fifth byte, bits 0-1 of CBWCB) of
01b or 11b (i.e., medium removal prevented). Since
in an SD card, there is no way to prevent card
removal, the firmware decodes the command and
prepares to notify the host PC that the operation has
been successfully completed. If the medium is inac-
cessible, the command is specified as Fail
(bCSWStatus = 0x01) with the SENSE KEY set to
Not Ready.
•TEST UNIT READY (Opcode 00h)
The TEST UNIT READY command provides a means
to check if the logical unit is ready. This is not a request
for self-check. If the logical unit is able to accept an
appropriate medium access command, without return-
ing a Check Condition status, this command shall
return a Good status. Otherwise, the command is
terminated with the Check Condition status and the
SENSE KEY is set to reflect the error condition.
•VERIFY (10) (Opcode 2Fh)
The VERIFY (10) command requests that the
device server verify the specified logical block(s) on
the medium. If the BYTCHK bit is set to ‘0’, the device
shall perform medium verification with no data com-
parison and not transfer any data from the Data-Out
buffer. If the BYTCHK bit is set to ‘1’, the device server
shall perform a byte-by-byte comparison of user data
read from the medium and user data transferred from
the Data-Out buffer. The firmware decodes the
command and then prepares to notify the host PC
that the command has been successfully completed.
If the medium is inaccessible, the command is
specified as Fail, with the SENSE KEY set to Not
Ready.
深圳市英锐恩科技有限公司
www.enroo-tech.com

©2005 Microchip Technology Inc. DS01003A-page 9
AN1003
•START/STOP (Opcode 1Bh)
The START/STOP command requests that the
device server change the power condition of the log-
ical unit, or load, or eject the medium. This includes
specifying that the device server enable or disable
the direct access block device for medium access
operations by controlling power conditions and tim-
ers. The POWER CONDITION field (fifth byte, bit 7-4)
is used to specify that the logical unit be placed into
a power condition or to adjust a timer. If the value of
this field is not equal to 0h, the START (fifth byte,
bit 0) and LOEJ (Load Eject, fifth byte, bit 1) bits are
ignored. If the POWER CONDITION field is Active
(1h), Idle (2h) or Standby (3h), then the logical unit
shall transition to the specified power. If POWER
CONDITION = 0h (START_VALID), then the START,
LOEJ = (0,0) signifies that the logical unit shall
transition to the stopped power condition; START,
LOEJ = (0,1) signifies the logical unit shall unload
the medium; START, LOEJ = (1,0) signifies that
the logical unit shall transition to the active power
condition. If START, LOEJ = (1,1), then the
logical unit shall load the medium.
UNSUPPORTED COMMANDS
If the command opcode field in the CBWCB is not
supported, the SENSE KEY is set to Illegal Request,
indicating that there was an illegal parameter in the
CDB with ASC and ACSQ codes set corresponding to an
invalid command opcode.
MASS STORAGE DEVICE (MSD)
FIRMWARE
This firmware implements a USB-based Mass Storage
Device using an SD card. When plugged into the USB
port, the firmware enumerates the SD card as a remov-
able disk drive and allows the user to exercise all
standard features of a disk drive. The user can write,
read, edit and delete files on the MSD just like any other
removable disk media. This application also allows the
user to format the SD card in any of the following FAT file
formats: FAT16, FAT32 or NTFS (Windows drivers han-
dle the format, firmware is only required to implement
the SCSI commands). The firmware calculates the
capacity of the SD card based on the Card Specific Data
(CSD) register read from the SD card. This information
is conveyed to the PC host in response to the READ
CAPACITY command. The exact size of the disk can be
seen in the disk properties on the PC. Further details on
firmware and SCSI command implementation can be
found in “SCSI Commands”.
The project framework is organized under a single root
directory with each subdirectory containing files for
each category or class of source code. If the SD card is
not found, or not initialized, the 4 LEDs (D1, D2, D3 and
D4) on the demonstration board are turned on
permanently.
Using the PICtail™ Board for SD™ and
MMC Cards
First, connect the demonstration board to the MPLAB®
ICD 2 and program the device. The following steps are
required to run the MSD application:
1. Connect the PICtail™ Board for SD™ and MMC
Cards to the PICDEM FS USB Demonstration
Board as shown in Figure 1.
2. Insert the SD card in the reader slot, making
sure that write-protect is disabled on the SD
card.
3. Apply power to the demonstration board.
4. Observe the LEDs (D1, D2, D3 and D4) on the
demonstration board. If all of the LEDs are ON,
this indicates an SD card initialization failure.
5. If no errors have occurred, connect a USB cable
from the PC to the USB connector on the
demonstration board.
6. Observe under Control Panel > System >
Hardware > Device Manager (for Windows XP
system) that USB Mass Storage Device gets
enumerated under Universal Serial Bus
controllers. Verify that the Microchp Mass
Storage USB Device is enumerated under Disk
drive and Generic volume is enumerated
under Storage volumes, as shown in Figure 5.
7. Look for a removable drive under My
Computer.
8. Use the removable drive icon to access the SD
card as a MSD.
9. Before removing the USB cable from the demo
board, click the “Safely Remove Hardware”
icon in the Windows task bar.
The four LEDs on the PICDEM FS USB Demonstration
Board have been implemented as follows:
1. LED D1 turns ON after successfully responding
to the INQUIRY command.
2. LED D2 toggles ON after each successful TEST
UNIT READY command execution.
3. LED D3 blinks during read operation (turns ON
while a read from the SD card is taking place).
4. LED D4 blinks during write operation (turns ON
while a write to the SD card is taking place).
深圳市英锐恩科技有限公司
www.enroo-tech.com