ETC HD6417705

To all our customers
Regarding the change of names mentioned in the document, such as Hitachi
Electric and Hitachi XX, to Renesas Technology Corp.
The semiconductor operations of Mitsubishi Electric and Hitachi were transferred to Renesas
Technology Corporation on April 1st 2003. These operations include microcomputer, logic, analog
and discrete devices, and memory chips other than DRAMs (flash memory, SRAMs etc.)
Accordingly, although Hitachi, Hitachi, Ltd., Hitachi Semiconductors, and other Hitachi brand
names are mentioned in the document, these names have in fact all been changed to Renesas
Technology Corp. Thank you for your understanding. Except for our corporate trademark, logo and
corporate statement, no changes whatsoever have been made to the contents of the document, and
these changes do not constitute any alteration to the contents of the document itself.
Renesas Technology Home Page: http://www.renesas.com
Renesas Technology Corp.
Customer Support Dept.
April 1, 2003
Cautions
Keep safety first in your circuit designs!
1. Renesas Technology Corporation puts the maximum effort into making semiconductor products better
and more reliable, but there is always the possibility that trouble may occur with them. Trouble with
semiconductors may lead to personal injury, fire or property damage.
Remember to give due consideration to safety when making your circuit designs, with appropriate
measures such as (i) placement of substitutive, auxiliary circuits, (ii) use of nonflammable material or
(iii) prevention against any malfunction or mishap.
Notes regarding these materials
1. These materials are intended as a reference to assist our customers in the selection of the Renesas
Technology Corporation product best suited to the customer's application; they do not convey any
license under any intellectual property rights, or any other rights, belonging to Renesas Technology
Corporation or a third party.
2. Renesas Technology Corporation assumes no responsibility for any damage, or infringement of any
third-party's rights, originating in the use of any product data, diagrams, charts, programs, algorithms, or
circuit application examples contained in these materials.
3. All information contained in these materials, including product data, diagrams, charts, programs and
algorithms represents information on products at the time of publication of these materials, and are
subject to change by Renesas Technology Corporation without notice due to product improvements or
other reasons. It is therefore recommended that customers contact Renesas Technology Corporation
or an authorized Renesas Technology Corporation product distributor for the latest product information
before purchasing a product listed herein.
The information described here may contain technical inaccuracies or typographical errors.
Renesas Technology Corporation assumes no responsibility for any damage, liability, or other loss
rising from these inaccuracies or errors.
Please also pay attention to information published by Renesas Technology Corporation by various
means, including the Renesas Technology Corporation Semiconductor home page
(http://www.renesas.com).
4. When using any or all of the information contained in these materials, including product data, diagrams,
charts, programs, and algorithms, please be sure to evaluate all information as a total system before
making a final decision on the applicability of the information and products. Renesas Technology
Corporation assumes no responsibility for any damage, liability or other loss resulting from the
information contained herein.
5. Renesas Technology Corporation semiconductors are not designed or manufactured for use in a device
or system that is used under circumstances in which human life is potentially at stake. Please contact
Renesas Technology Corporation or an authorized Renesas Technology Corporation product distributor
when considering the use of a product contained herein for any specific purposes, such as apparatus or
systems for transportation, vehicular, medical, aerospace, nuclear, or undersea repeater use.
6. The prior written approval of Renesas Technology Corporation is necessary to reprint or reproduce in
whole or in part these materials.
7. If these products or technologies are subject to the Japanese export control restrictions, they must be
exported under a license from the Japanese government and cannot be imported into a country other
than the approved destination.
Any diversion or reexport contrary to the export control laws and regulations of Japan and/or the
country of destination is prohibited.
8. Please contact Renesas Technology Corporation for further details on these materials or the products
contained therein.
TM
Hitachi SuperH RISC Engine
SH7705
USB Function Module
Mass Storage Class
(Bulk-Only Transport)
Application Note
ADE-502-083
Rev. 1.0
01/23/03
Hitachi, Ltd.
Cautions
1. Hitachi neither warrants nor grants licenses of any rights of Hitachi’s or any third party’s
patent, copyright, trademark, or other intellectual property rights for information contained in
this document. Hitachi bears no responsibility for problems that may arise with third party’s
rights, including intellectual property rights, in connection with use of the information
contained in this document.
2. Products and product specifications may be subject to change without notice. Confirm that you
have received the latest product standards or specifications before final design, purchase or
use.
3. Hitachi makes every attempt to ensure that its products are of high quality and reliability.
However, contact Hitachi’s sales office before using the product in an application that
demands especially high quality and reliability or where its failure or malfunction may directly
threaten human life or cause risk of bodily injury, such as aerospace, aeronautics, nuclear
power, combustion control, transportation, traffic, safety equipment or medical equipment for
life support.
4. Design your application so that the product is used within the ranges guaranteed by Hitachi
particularly for maximum rating, operating supply voltage range, heat radiation characteristics,
installation conditions and other characteristics. Hitachi bears no responsibility for failure or
damage when used beyond the guaranteed ranges. Even within the guaranteed ranges,
consider normally foreseeable failure rates or failure modes in semiconductor devices and
employ systemic measures such as fail-safes, so that the equipment incorporating Hitachi
product does not cause bodily injury, fire or other consequential damage due to operation of
the Hitachi product.
5. This product is not designed to be radiation resistant.
6. No one is permitted to reproduce or duplicate, in any form, the whole or part of this document
without written approval from Hitachi.
7. Contact Hitachi’s sales office for any questions regarding this document or Hitachi
semiconductor products.
Rev. 1.0, 01/03, page ii of vi
Preface
This application note describes the Mass Storage Class (Bulk-Only Transport) firmware that uses
the USB Function Module in the SH7705. This is provided to be used as a reference when the user
creates USB Function Module firmware.
This application note and the described software are application examples of the USB Function
Module, and their contents and operation are not guaranteed.
In addition to this application note, the manuals listed below are also available for reference when
developing applications.
[Related manuals]
• Universal Serial Bus Specification Revision 1.1
• Universal Serial Bus Mass Storage Class Specification Overview Revision 1.1
• Universal Serial Bus Mass Storage Class (Bulk-Only Transport) Revision 1.0
• SH7705 Hardware Manual
• SH7705 Solution Engine (MS7705SE01) Instruction Manual
• SH7705 E10A Emulator User’s Manual
[Caution] The sample programs described in this application note do not include firmware related
to interrupts, which is a USB transport type. When using the transfer type (see page 181 of the SH7705 Hardware Manual), the user needs to create the program for it.
Also, the hardware specifications of the SH7705 and SH7705 Solution Engine, which
will be necessary when developing the system described above, are described in this
application note, but more detailed information is available in the SH7705 Hardware
Manual and the SH7705 Solution Engine Instruction Manual.
Rev. 1.0, 01/03, page iii of vi
Rev. 1.0, 01/03, page iv of vi
Contents
Section 1 Overview........................................................................................... 1
Section 2 Overview of the USB Mass Storage Class (Bulk-Only Transport) .. 3
2.1
2.2
2.3
2.4
USB Mass Storage Class...................................................................................................3
Sub-Class Code .................................................................................................................4
Bulk-Only Transport ......................................................................................................... 4
2.3.1 Command Transport ............................................................................................5
2.3.2 Status Transport ...................................................................................................6
2.3.3 Data Transport .....................................................................................................7
2.3.4 Class Commands..................................................................................................8
SCSI Transparent Command Set Sub-Class Code ............................................................9
Section 3 Development Environment ............................................................... 11
3.1
3.2
3.3
3.4
3.5
Hardware Environment .....................................................................................................11
Software Environment ......................................................................................................13
3.2.1 Sample Program...................................................................................................13
3.2.2 Compiling and Linking ........................................................................................13
Loading and Executing the Program.................................................................................15
3.3.1 Loading the Program............................................................................................16
3.3.2 Executing the Program.........................................................................................17
Using the RAM Disk.........................................................................................................17
Changing the RAM Disk Setting ......................................................................................18
3.5.1 Selection of Removable/Fixed Disk.....................................................................18
3.5.2 Changing the Capacity of the RAM Disk ............................................................18
Section 4 Overview of the Sample Program..................................................... 19
4.1
4.2
4.3
4.4
4.5
4.6
4.7
State Transition Diagram ..................................................................................................19
USB Communication State ...............................................................................................20
4.2.1 Control Transfer...................................................................................................21
4.2.2 Bulk Transport .....................................................................................................21
File Structure.....................................................................................................................21
Purposes of Functions ....................................................................................................... 24
RAM Disk .........................................................................................................................29
Operation of SCSI Commands That Are Supported .........................................................30
Processing If an Error Occurs ...........................................................................................34
Section 5 Sample Program Operation............................................................... 45
5.1
5.2
Main Loop.........................................................................................................................45
Types of Interrupts ............................................................................................................46
Rev. 1.0, 09/02, Page v of vi
5.3
5.4
5.5
5.2.1 Method of Branching to Different Transfer Processes......................................... 47
Interrupt on Cable Connection (BRST) ............................................................................ 48
Control Transfers .............................................................................................................. 49
5.4.1 Setup Stage .......................................................................................................... 50
5.4.2 Data Stage ............................................................................................................ 52
5.4.3 Status Stage.......................................................................................................... 54
Bulk Transfers................................................................................................................... 56
5.5.1 Command Transport ............................................................................................ 57
5.5.2 Data Transport ..................................................................................................... 59
5.5.3 Status Transport ................................................................................................... 63
Section 6 Analyzer Data ....................................................................................71
Rev. 1.0, 09/02, page vi of vi
Section 1 Overview
This application note describes how to use the USB Function Module that is built into the
SH7705, and contains examples of firmware programs.
The features of the USB Function Module contained in the SH7705 are listed below.
• An internal UDC (USB Device Controller) conforming to USB 1.1
• Automatic processing of USB protocols
• Automatic processing of USB standard commands for endpoint 0 (some commands need to be
processed through the firmware)
• Full-speed (12 Mbps) transfer supported
• Various interrupt signals needed for USB transmission and reception are generated.
• Internal system clock based on clock oscillation CPG or external input (48 MHz) can be
selected.
• Low power consumption mode provided
• An internal bus transceiver
• Power mode: Self mode
Endpoint Configurations
Endpoint
Name
Transfer Type
Max. Packet
Size
FIFO Buffer
Capacity (bytes)
DMA
Transfer
EP0s
Setup
8 bytes
8 bytes

EP0i
Control In
8 bytes
8 bytes

EP0o
Control Out
8 bytes
8 bytes

Endpoint 1
EP1
Bulk-out
64 bytes
64 x 2 (128 bytes)
Possible
Endpoint 2
EP2
Bulk-in
64 bytes
64 x 2 (128 bytes)
Possible
Endpoint 3
EP3
Interrupt
8 bytes
8 bytes

Endpoint 0
Name
Rev. 1.0, 01/03, page 1 of 74
Figure 1.1 shows an example of a system configuration.
USB“ ‹ ƒ
Úƒ
zX
ƒg
PC
Host PC equipped with USB
W indows
2000
Windows
2000
W indows
M illMillennium
ennium EditEdition
ion
Windows
Mac
OS9
M ac
OS9
SH7705
Engine
SH7727Solution
Solution
Engine
1.1 ƒ ƒ
}
VX
ƒe
ƒ € \ —
¬ á
Figure 1.1 System Configuration Example
This system is configured of the SH7705 Solution Engine made by Hitachi ULSI Systems Co.,
Ltd. (hereafter referred to as the SH7705SE) and a PC containing Windows 2000/Windows
Millennium Edition or Mac OS9 operating system.
By connecting the host PC and the SH7705SE through USB, the SDRAM in the SH7705SE can
be accessed as a RAM disk, enabling data in the SDRAM of the SH7705SE to be stored in and
loaded from the host PC.
It is also possible to use the USB Mass Storage Class (Bulk-Only Transport) device driver that
comes as an accessory with the operating systems listed above.
This system offers the following features.
1. The sample program can be used to evaluate the USB module of the SH7705 quickly.
2. The sample program supports USB control transfer and bulk transport.
3. An E10A (PC card-type emulator) can be used, enabling efficient debugging.
4. Additional programs can be created to support interrupt transfer and isochronous transfer. *
Note: * Interrupt transfer program is not provided, and will need to be created by the user.
Rev. 1.0, 01/03, page 2 of 74
Section 2 Overview of the USB Mass Storage Class
(Bulk-Only Transport)
This section describes the USB Mass Storage Class (Bulk-Only Transport).
We hope that it will provide a convenient reference for use when developing USB storage-related
systems. For more detailed information on standards, please see the following:
• Universal Serial Bus Mass Storage Class Specification Overview Revision 1.1
• Universal Serial Bus Mass Storage Class Bulk-Only Transport Revision 1.0
2.1
USB Mass Storage Class
USB Mass Storage Class is a class of standards that apply to large-scale memory (storage) devices
that are connected to a host PC and handle reading and writing of data.
In order to let the host PC know that a function is in this class, a value of 0x08 must be entered in
the bInterface Class field of the Interface Descriptor. Also, the Serial Number should be known to
the host PC in the Mass Storage Class by using String Descriptor. The sample programs provided
here return 000000000000 in Unicode.
When transferring data between the host PC and the function, four transport methods defined by
the USB are used (control transfer, bulk transport, interrupt transfer, and isochronous transfer).
Protocol codes determine the transport method and how it is used.
There are two types of data transport protocols:
• USB Mass Storage Class Bulk-Only Transport
• USB Mass Storage Class Control/Bulk/Interrupt (CBI) Transport
As its name indicates, USB Mass Storage Class Bulk-Only Transport is a data transport protocol
that only uses bulk transport.
USB Mass Storage Class Control/Bulk/Interrupt (CBI) Transport is a data transport protocol that
uses control transfer, bulk transport, and interrupt transfer. CBI Transport is further subdivided
into a data transport protocol that uses interrupt transfer, and one that does not use interrupt
transfer.
The sample programs provided here use USB Mass Storage Class Bulk-Only Transport as the data
transport protocol.
Rev. 1.0, 01/03, page 3 of 74
When the host PC uses a device in order to load and save data, instructions (commands) are
provided by the host PC to the function. The function then executes those commands to load and
save data. The commands sent by the host PC to the function are defined in the form of sub-class
code.
2.2
Sub-Class Code
Sub-class codes are values that indicate the command format sent from the host PC to a function
by means of command transport. There are seven types of command formats, described in
table 2.1.
Table 2.1
Sub-Class Code
Command Standards
0x01
Reduced Block Commands (RBC), T10/1240-D
0x02
Attachment Packet Interface (ATAPI) for CD-ROMs. SFF-8020i,
Multi-Media Command Set 2 (MMC-2)
0x03
Attachment Packet Interface (ATAPI) for Tape. QIC-157
0x04
USB Mass Storage Class UFI Command Specification
0x05
Attachment Packet Interface (ATAPI) for Floppies. SFF-8070i
0x06
SCSI Primary Commands –2 (SPC-2), Revision 3 or later
In order to tell the host PC the command format supported by the device, a sub-class code value
must be entered in the bINterfaceSubClass field of the Interface Descriptor.
The sample programs used here use a sub-class code value of 0x06, which indicates the SCSI
Primary Commands.
2.3
Bulk-Only Transport
With Bulk-Only Transport, data is transferred between the host PC and a function using bulk data
transport only.
Bulk transport can be divided into two types, depending on the direction in which the data is sent.
If data is sent from the host controller to the function, bulk-out transport is used. If data is being
sent to the host controller from the function, bulk-in transport is used.
With Bulk-Only Transport, a combination of bulk-out transport and bulk-in transport determined
in advance is used to transfer data between the host and the function. Bulk-Only Transport always
uses the combination of bulk transports shown in figure 2.1. These bulk transports have different
meanings, but they are handled as stages (transports).
Rev. 1.0, 01/03, page 4 of 74
Start
Command
transport (CBW)
Data
transport
Bulk-out transport
Bulk-out
transport
Status
transport (CSW)
Bulk-in
transport
Bulk-in transport
End
Figure 2.1 Relationship between Transfer Methods and Transports
In order to tell the host PC that the Bulk-Only Transport protocol is being used, a value of 0x50
must be entered in the bInterfaceProtocol field of the Interface Descriptor.
2.3.1
Command Transport
In command transport, commands are sent from the host PC to the function using bulk-out
transport. This command packet is defined as the Command Block Wrapper (CBW), and BulkOnly Transport must always begin with the CBW.
The CBW is sent from the host PC as a 31-byte packet, using bulk-out transport.
It is sent using the format shown in table 2.2.
Table 2.2
7
6
5
00-03
dCBWSignature
04-07
dCBWTag
08-0B
dCBWDataTransferLength
0C
bmCBWFlags
0D
Reserved (0)
0E
Reserved (0)
0F-1E
CBWCB
4
3
2
1
0
bCBWLUN
bCBWCBLength
Rev. 1.0, 01/03, page 5 of 74
The fields are explained below.
dCBWSignature:
This field identifies the data packet as a CBW.
The value is 43425355h (little endian).
dCBWTag:
This is the command block tag. It is used to connect the CSW with
its corresponding CBW, and is specified by the host PC.
dCBWDataTransferLength: This is the length of the data planned for transport.
If this is 0, no data transport exists.
bmCBWFlags:
If bit 7 of this field is 0, data is transported using bulk-out transport,
and if it is 1, bulk-in transport is used. Bits 0 to 6 are fixed at 0.
bCBWLUN:
This is the Logical Unit Number of the device sending the command
block.
bCBWCBLength:
This indicates the number of valid bytes for the next CBWCB field.
CBWCB:
This field stores the command block to be executed by the function.
The command that the host PC wants to execute (the SCSI command
in this sample program) is entered in this field.
2.3.2
Status Transport
Status transport is used to send the results of command execution from the function to the host PC,
using bulk-in transport.
This status packet is defined by the Command Status Wrapper (CSW). Bulk-Only Transport must
always end with the CSW.
The CSW is sent to the host as a 13-byte packet, using bulk-in transport.
It is sent in the format shown in table 2.3.
Table 2.3
7
6
0-3
dCSWSignature
4-7
dCSWTag
8-B
dCSWDataResidue
C
bCSWStatus
Rev. 1.0, 01/03, page 6 of 74
5
4
3
2
1
0
The fields are explained below.
dCSWSignature:
This field identifies the data packet as the CSW.
The value is 53425355h (little endian).
dCSWTag:
This is the command block tag. It ties the CBW to the CSW, and the same
value is entered here as that of the dCBWTag field of the CBW.
dCSWDataResidue: This reports any differences in the value of the CBW
dCBWDataTransferLength and the actual amount of data processed by the
function.
bCSWStatus:
2.3.3
This indicates whether or not a command has been successfully executed. If
the command was executed successfully, the function sets 0x00 in this field.
Any value other than 0 indicates that the command was not executed
successfully. Error values are as follows: 0x01 indicates a failed command,
and 0x02 indicates a phase error.
Data Transport
Data transport is used to transfer data between the host PC and the function. For example, with the
Read/Write command (see section 4.6), the actual data of the various storage sectors is sent using
data transport.
Data transport is configured of multiple bus transactions.
Data transfers carried out using data transport use either bulk-out or bulk-in transport. The
bmCBWFlags field of the CBW data determines which type of transport is used.
Data transport (bulk-out transport):
This section explains how data is transferred when bulk-out data transport is used.
This status is set if bit 7 of the bmCBWFlags field of the CBW data is 0, and the
dCBWDataTransferLength field of the CBW data is not 0.
Here, the function receives the anticipated length of the data indicated by the
dCBWDataTransferLength field of the CBW data. The data transferred at this point is needed
when the SCSI command specified by the CBWCB field of the CBW data is executed.
Rev. 1.0, 01/03, page 7 of 74
Data transport (bulk-in transport):
This section explains how data is transferred when bulk-in data transport is used.
This status is set if bit 7 of the bmCBWFlags field of the CBW data is 1, and the
dCBWDataTransferLength field of the CBW data is not 0.
Here, the anticipated length of the data indicated by the dCBWDataTransferLength field of the
CBW data is sent to the host PC. The data transferred at this point is the result produced when the
SCSI command specified by the CBWCB field of the CBW data was executed.
2.3.4
Class Commands
Class commands are commands that are defined by the various USB classes. They use control
transfer.
When USB Mass Storage Class Bulk-Only Transport is used as the data transport protocol, there
are two types of commands that must be supported. The class commands are indicated in table 2.4.
Table 2.4
Class Commands
bRequest Field Value
Command
Meaning of Command
255 (0xFF)
Bulk-Only Mass Storage Reset
Resets the interface
254 (0xFE)
Get Max LUN
Checks the number of LUNs
supported
When the Bulk-Only Mass Storage Reset command is received, the function resets all of the
interfaces used in USB Mass Storage Class Bulk-Only Transport.
When the Get Max LUN command is received, the function returns the largest logical unit number
that can be used. In the sample system used here, there is one logic unit, so a value of 0 will be
returned to the host.
Rev. 1.0, 01/03, page 8 of 74
2.4
SCSI Transparent Command Set Sub-Class Code
The various commands must be processed in response to the sub-class commands in the CBW sent
to the function by the host PC.
In this sample program, the ten SCSI commands shown in table 2.5 are supported. If a command
is not supported, the CSW will be used to inform the host PC that the command failed.
Table 2.5
Supported Commands
Operation Code
Command Name
Command Operation
12
INQUIRY
Tells the host the drive information.
25
READ CAPACITY
Tells the host the media sector information.
28
READ(10)
Reads the specified sector volume data from a
specified sector.
2A
WRITE(10)
Writes the specified sector volume data to a specified
sector.
03
REQUEST SENSE
If an error occurred for the previous command, this
tells the host what kind of error occurred.
1A
MODE SENSE(6)
Tells the host the drive status.
1E
PREVENT ALLOW
MEDIUM
REMOVAL
Inhibits/enables installing and removing media.
00
TEST UNIT READY
Checks whether or not a medium can be used.
2F
VERIFY(10)
Confirms whether or not the data in a medium can be
accessed.
1B
STOP/START UNIT
Controls installing and removing media.
Rev. 1.0, 01/03, page 9 of 74
Rev. 1.0, 01/03, page 10 of 74
Section 3 Development Environment
This section looks at the development environment used to develop this system. The devices
(tools) listed below were used when developing the system.
• SH7705 Solution Engine (hereafter called the SH7705SE; type number: MS7705SE01)
manufactured by Hitachi ULSI Systems Co., Ltd.
• SH7705 E10A Emulator manufactured by Hitachi, Ltd.
• PC (Windows 95/98) equipped with a PCMCIA slot
• PC (Windows 2000/Windows Millennium Edition or Mac OS9) to serve as the USB host
• USB cable
• Hitachi Debugging Interface (hereafter called the HDI) manufactured by Hitachi, Ltd.
• Hitachi Embedded Workshop (hereafter called the HEW) manufactured by Hitachi, Ltd.
3.1
Hardware Environment
Figure 3.1 shows device connections.
USB
cable
USBƒ
P[
ƒu
ƒ
‹
USBƒ z
ƒX
ƒg
“ ‹Ú
PC
(Windows2000)
PC equipped with USB host
USBƒ ƒ
z (Windows2000/Me/XP)
ƒg
X
‚Æ
‚µ
‚Ž
Äg
—p
‚µA
SD-RAM ‚
ã Ì
ƒfƒ
[^
‚•
ðÛ
Ԧ A
“‚
ÇÝ‚
o·
This is used as the USB host,
to save and load data on the
SDRAM.
E10Aƒ cable
P[
ƒ u
ƒ‹
E10A
3.1 ƒ f
}
ƒƒ
oC
ƒ ‚
XÌ‘
ڌ
±‘
`Ô
E10A PC
(Windows95/98) E10A PC
HDI,HEW‚ —
ðp
‚(Windows95/98/Me)
¢
‚ƒ
Ć[
ƒ U
ƒ User
t
ƒ@ [
ƒfirmware
ƒE
€
ƒG
ƒA
Š”
J
‰Â
”developed
\
can
HDI:Hitachi
Debugging
Interface
using the HDI
and HEW.
HEW:Hitachi
Embedded
Workshop
HDI: Hitachi
Debugging
Interface
HEW: Hitachi Embedded Workshop
Figure 3.1 Device Connections
Rev. 1.0, 01/03, page 11 of 74
1. SH7705SE
Some DIP switch settings on the SH7705SE board must be changed from those at shipment.
Before turning on the power, ensure that the switches are set as follows. There is no need to
change any other DIP switches.
Table 3.1
DIP Switch Settings
Switch
At Time of Shipment
After Change
DIP Switch Function
SW3-1
ON
OFF
SW3-2
ON
ON (No change)
Select clock operating mode
(Mode 5)
SW3-3
ON
OFF
SW3-6
OFF
ON
Select endian
SW3-7
OFF
ON
Select E10A emulator mode
SW3-8
ON
OFF
Select E10A emulator mode
2. USB host PC
A PC with Windows 2000/Windows Millennium Edition or Mac OS9 installed, and with a
USB port, is used as the USB host. This system uses USB Mass Storage Class (Bulk-Only
Transport) device drivers installed as a standard part of the Windows 2000 system, and so
there is no need to install new drivers.
3. E10A PC
The E10A should be inserted into a PC card slot and connected to the SH7705SE via an
interface cable. After connection, start the HDI and perform emulation.
Rev. 1.0, 01/03, page 12 of 74
3.2
Software Environment
A sample program, as well as the compiler and linker used, are explained.
3.2.1
Sample Program
Files required for the sample program are all stored in the SH7705 folder. When this entire folder
with its contents is moved to a PC on which HEW and HDI have been installed, the sample
program can be used immediately. Files included in the folder are indicated in figure 3.2 below.
SH7705
CatBOTTypedef.h CatProType.h CatSCSITypedef.h CatTypedef.h
SetBOTInfo.h SetMacro.h
SetSCSIInfo.h SetSystemSwitch.h SetUsbInfo.h
SH7705.h
SysMemMap.h
StartUp.c
DoControl.c
DoBulk.c
DoInterrupt.c
DoRequestBOT_StorageClass.c
UsbMain.c
DoSCSICommand.c
sct.src AsmFunction.src
debugger.ABS debugger.MAP
BuildOfHew.bat
InkSet1.sub
debugger.MOT log.txt
DoRequest.c
DoBOTMSClass.c
dwfinf (folder)
7705E10A.hdc
Figure 3.2 Files Included in the Folder
3.2.2
Compiling and Linking
The sample program is compiled and linked using the following software.
Hitachi Embedded Workshop Version 1.0 (release 9) (hereafter HEW)
When HEW is installed in C:\Hew, the procedure for compiling and linking the program is as
follows.*
First, a folder named Tmp should be created below the C:\Hew folder for use in compiling
(figure 3.3).
C:\
\Hew
\Tmp
Figure 3.3 Creating a Working Folder
Rev. 1.0, 01/03, page 13 of 74
Next, the folder in which the sample program is stored (SH7705) should be copied to any arbitrary
drive. In addition to the sample program, this folder contains a batch file named BuildOfHew.bat.
This batch file sets the path, specifies compile options, specifies a log file indicating the compiling
and linking results, and performs other operations. When BuildOfHew.bat is executed, compiling
and linking are performed. As a result, an executable file named debugger.ABS is created within
the folder. At the same time, a map file named debugger.MAP and a log file named log.txt are
created. The map file indicates the program size and variable addresses. The compile results
(whether there are any errors etc.) are recorded in the log file (figure 3.4).
Note: * If HEW is installed to a folder other than C:\Hew, the compiler path setting and
settings for environment variables used by the compiler in BildOfHew.bat, as well as
the library settings in InkSet1.sub, must be changed. Here the compiler path setting
should be changed to the path of shc.exe, and the setting for the environment variable
shc_lib used by the compiler should be set to the folder of shc.exe; the shc_inc setting
should be changed to the folder of machine.h, and the setting of shc_tmp should
specify the work folder for the compiler. The library setting should specify the path of
shcpic.lib.
SH7705
Batch file
Execution results
debugger.ABS
BuildOfHew.bat
Execution
debugger.MOT
debugger.MAP
log.txt
Figure 3.4 Compile Results
Rev. 1.0, 01/03, page 14 of 74
3.3
Loading and Executing the Program
Figure 3.5 shows the memory map for the sample program.
01C0 0000
01C0 03B2
A1DF E000
A1DF FFFC
SH7705SE SRAM memory (area 0)
B and R areas
Stack area
947 bytes
About 8 kbytes
SH7705SE SRAM (area 3)
AC00 0000
AC00 00EB
PResetException area
236 bytes
Free space
AC00 0100
PGeneralExceptions area
AC00 013F
AC00 0400
AC00 045D
64 bytes
Free space
PTLBMissException area
94 bytes
Free space
AC00 0600
AC00 064B
PInterrupt area
76 bytes
Free space
AC00 1000
AC00 103F
PNonCash area
64 bytes
Free space
0C00 1200
0C00 2F5E
AC00 4000
P, C, and D areas*
7517 bytes
Free space
RAM_Disk area
AD00 4000
16 Mbytes
Free space
Notes:
The memory map differs according to the compiler version, compile conditions, firmware
upgrade, etc.
* Placed in the P3 cache write-back space. Consequently the addresses bits A31 to 29
are 110.
Figure 3.5 Memory Map
As shown in figure 3.5, this sample program allocates the PResetException, PGeneralExceptions,
PTLBMissException, PInterrupt, PNonCash, and P, C, and D areas on SDRAM, the R and B areas
on the SRAM. In order to use the E10A for break and other functions, the program must be placed
in RAM in this way. These memory allocations are specified by the InkSet1.sub file in the
SH7705 folder. When incorporating the program in ROM by writing it to flash memory or some
other media, this file must be modified.
Rev. 1.0, 01/03, page 15 of 74
3.3.1
Loading the Program
In order to load the sample program into the RAM of the SH7705SE, the following procedure is
used.
• Insert the E10A into the PC for use with the E10A, in which the HDI has been installed, and
connect the E10A to the SH7705SE via a user system interface cable.
• Turn on the power to the E10A PC, to start up the machine.
• Start up the HDI.
• Turn on the power to the SH7705SE.
• A dialog (figure 3.6) is displayed on the PC screen; turn the SH7705SE reset switch (SW1) on,
and after resetting the CPU, click the OK button, or press the Enter key.
• Select CommandLine in the View menu to open a window (figure 3.7), click the BatchFile
button on the upper left, and specify the 7705E10A.hdc file in the SH7705 folder. As a result
the access to the SDRAM is enabled and the program counter (PC) is set. To modify the
values, change the contents of the 7705E10A.hdc.
• Select LoadProgram… from the File menu; in the Load Program dialog box, specify
debugger.ABS in the SH7705 folder.
Through the above procedure, the sample program can be loaded into SDRAM of the SH7705SE.
Figure 3.6 Reset Request Dialog
Batch file
Figure 3.7 Command Line Input
Rev. 1.0, 01/03, page 16 of 74
3.3.2
Executing the Program
Select Go from the Run menu to execute the program.
3.4
Using the RAM Disk
The following describes an example in which Windows 2000 is used.
After the program has been run, the Series B connector of the USB cable is inserted into the
SH7705SE, and the Series A connector on the opposite side is connected to the USB host PC.
After the emulation used for control transfer and bulk transport has ended, the USB large-size
storage device is displayed under the USB controller in the device manager, and the Hitachi EX
RAM Disk USB device is displayed under the disk drive. As a result, the host PC recognizes the
SH7705SE as the storage device, and the local disk is mounted in the microcomputer.
Next, the local disk needs to be formatted.
Select Local Disk and click with the right button of the mouse to display a floating menu. Select
Format. A format selection window for the drive is displayed. Enter the necessary format settings.
Check to make sure FAT has been selected for the file system, and click on the Start button.
A format confirmation window is displayed. Click on the OK button.
When the formatting has been completed, a message window is displayed. Click on the OK
button.
The screen returns to the drive format selection window. Click on the Close button to exit the
procedure.
The SH7705SE can now be used as the RAM disk for USB connection.
Rev. 1.0, 01/03, page 17 of 74
3.5
Changing the RAM Disk Setting
Changing the settings of the RAM disk used in this sample program provided here is described
bellow.
3.5.1
Selection of Removable/Fixed Disk
In this sample program, the RAM disk is used as a removable disk.
Fixed disk can be used by commenting out #define REMOVABLE_DISK in SetSystemSwitch.h
and enabling commented out #undef REMOVABLE_DISK.
3.5.2
Changing the Capacity of the RAM Disk
This sample program uses 16 Mbytes of SDRAM as the RAM disk. To change the capacity of the
1
RAM disk the contents of SysMemMap.h need to be changed. First, specify the whole bytes* for
the RAM disk by DISK_ALL_BYTE. Then, specify the start and the end points of the area for the
2
RAM disk by SDRAM_DATA_S and SDRAM_DATA_E* respectively.
Notes: 1.
Specify 1.5 Mbytes or more. As some amount of area is used for such as the FAT
information the capacity recognized by the computer is smaller than actual one. In this
sample program, to configure FAT information up to 16 Mbytes and 2 Gbytes are
used for FAT12 and FAT 16 respectively. Other FAT system information needs to be
provided by the user.
2.
The area specified by SDRAM_DATA_S and SDRAM_DATA_E must be larger than
the area specified by DISK_ALL_BYTE.
Rev. 1.0, 01/03, page 18 of 74
Section 4 Overview of the Sample Program
In this section, features of the sample program and its structure are explained. This sample
program runs on the SH7705SE, which works as a RAM disk, and initiates USB transfers by
means of interrupts from the USB function module. Of the interrupts from modules in the
SH7705SE, there are two interrupts related to the USB function module: USBFI0 and USBFI1,
but in this sample program, only USBFI0 is used.
Features of this program are as follows.
• Control transfer can be performed.
• Bulk-out transfer can be used to receive data from the host controller.
• Bulk-in transfer can be used to send data to the host controller.
• It operates as a RAM disk that supports SCSI commands.
4.1
State Transition Diagram
Figure 4.1 shows a state transition diagram for this sample program. In this sample program, as
shown in figure 4.1, there are transitions between three states.
Immediately after the power supply has been turned on,
the system is in reset state. After the initial settings have been
completed, it returns to the stationary state.
Reset state
Initial settings completed
Interrupt generated
(USBFI0)
USB communication state
Stationary state
Control transfer
USB communication
completed
Bulk transport
Figure 4.1 State Transition Diagram
Rev. 1.0, 01/03, page 19 of 74
• Reset State
Upon power-on reset and manual reset, this state is entered. In the reset state, the SH7705
mainly performs initial settings.
• Stationary State
When initial settings are completed, a stationary state is entered in the main loop.
• USB Communication State
In the stationary state, when an interrupt from the USB module occurs, this state is entered. In
the USB communication state, data transfer is performed by a transfer method according to the
type of interrupt. The interrupts used in this sample program are indicated by interrupt flag
register 0 (USBIFR0), and there are eight interrupt types in all. When an interrupt factor
occurs, the corresponding bits in USBIFR0 are set.
4.2
USB Communication State
The USB communication state can be further divided into three states according to the transfer
type (see figure 4.2). When an interrupt occurs, first there is a transition to the USB
communication state, and then there is further branching to a transfer state according to the
interrupt type. The branching method is explained in section 5, Sample Program Operation.
USB communication state
Control transfer
Bulk transport
Ready
Ready
Setup stage
Command
transport (CBW)
Data stage
OUT direction
Data stage
IN direction
Status stage
Data out
Status transport (CSW)
Figure 4.2 USB Communication State
Rev. 1.0, 01/03, page 20 of 74
Data in
4.2.1
Control Transfer
Control transfer is used mainly for functions such as obtaining device information and specifying
device operating states. For this reason, when the function is connected to the host PC, control
transfer is the first transport to be carried out.
Transport processing for control transfer is carried out in a series of two or three stages. These
stages are a setup stage, a data stage, and a status stage.
4.2.2
Bulk Transport
Bulk transport has no time limitations, so it is used to send large volumes of data with no errors.
The data transport speed is not guaranteed, but the data contents are guaranteed. With USB Mass
Storage Class (Bulk-Only Transport), bulk transport is used to transfer storage data between the
host PC and the function.
Transport processing for USB Mass Storage Class (Bulk-Only Transport) is carried out in a series
of two or three stages. These stages are command transport (CBW), data transport, and status
transport (CSW).
4.3
File Structure
This sample program consists of nine source files and eleven header files. The overall file
structure is shown in table 4.1. Each function is arranged in one file by transfer method or function
type. Figure 4.3 shows the layered configuration of these files.
Rev. 1.0, 01/03, page 21 of 74
Table 4.1
File Structure
File Name
Principle Role
StartUp.c
Microcomputer default settings
UsbMain.c
Judging the causes of interrupts
Sending and receiving packets
DoRequest.c
Processing setup commands issued by the host
DoRequestBOT_StorageClass.c
Processing Mass Storage Class (Bulk-Only Transport) class
commands
DoControl.c
Executing control transfer
DoBulk.c
Executing bulk transport
DoBOTMSClass.c
Executing Mass Storage Class (Bulk-Only Transport)
DoSCSICommand.c
Analyzing and processing SCSI commands
AsmFunction.src
Making stack settings
SH7705.h
Defining SH7705 registers
SysMemMap.h
Defining SH7705SE memory map addresses
CatProType.h
Prototype declarations
CatTypedef.h
Defining the basic structures used in USB firmware
CatBOTTypedef.h
Defining structures used for Bulk-Only Transport
CatSCSITypedef.h
Defining structures used for SCSI, and defining macros for
configuring FAT information
SetUsbInfo.h
Default settings of variables needed to support USB
SetBOTInfo.h
Default settings of variables needed to support Bulk-Only
Transport
SetSCSIInfo.h
Default settings of variables needed to support SCSI
commands
SetSystemSwitch.h
System operation settings
SetMacro.h
Defining macros
Rev. 1.0, 01/03, page 22 of 74
Target data file
Interprets SCSI commands and carries out
RAM disk operations
Relevant files: DoSCSICommand.c
CatSCSITypedef.h
SetSCSIInfo.h
Operation:
Application
layer
Class file
Carries out Mass Storage Class (Bulk-Only
Transport) operations and supports class commands
Relevant files: DoBOTMSClass.c
CatBOTTypedef.h
SetBOTInfo.h
Operation:
USB
device
layer
Standard commands
Operation: Carries out
responses to standard commands
Relevant file: DoRequest.c
Vender commands
Class layer
Bulk transport
Operation: Carries out
responses to class commands
Relevant file:
DoRequestBOT_Storage
Class.c
Bulk transport
Operation:
Carries out
bulk transport
operations
Relevant file: DoBulk.c
Control transfer
Operation: Carries out control transfer operations
Relevant file: DoControl.c
USB common variables
Operation: Carries out reception of packet data, transmission of packet data, endian conversion, various types of
settings, and other necessary operations regardless of transport method
Relevant file: UsbMain.c
CatTypedef.h
SetUsbInfo.h
USB
bus
interface
USB hardware
Figure 4.3 Layered Configuration of the Storage Class (BOT) Firmware
Rev. 1.0, 01/03, page 23 of 74
4.4
Purposes of Functions
Table 4.2 list functions contained in each file and their purposes.
Table 4.2-1 StartUp.c
File in which
stored
StartUp.c
Function Name
Purpose
CallReseException
Performs the operation for the reset exception and
calls the following function
CallGeneralException
Calls the function for the general exception except for
the TLB miss
CallTLBMissException
Calls the function for the TLB miss
CallInterrupt
Calls the function for the interrupt request
SetPowerOnSection
Initializes module and memory, and shifts to the main
loop
_INITSCT
Copies variables that have default settings to the
RAM work area
InitMemory
Clears the RAM area used in bulk communication
InitSystem
Pull-up control of the USB bus
When a power-on reset or manual reset is carried out, the SetPowerOnSection of the StartUp.c file
is called. At this point, the SH7705 default settings are entered and the RAM area used for bulk
transport is cleared.
Rev. 1.0, 01/03, page 24 of 74
Table 4.2-2 UsbMain.c
File in Which
Stored
UsbMain.c
Function Name
Purpose
BranchOfInt
Discriminates interrupt factors, and calls function
according to interrupt
GetPacket
Writes data transferred from the host controller to RAM
GetPacket4
Writes data transferred from the host controller to RAM
in longwords (provided for ring-buffer, not used for the
Mass Storage Class)
GetPacket4S
Writes data transferred from the host controller to RAM
in longwords (not provided for ring-buffer, high-speed
version)
PutPacket
Writes data for transfer to the host controller to the USB
module
PutPacket4
Writes data for transfer to the host controller to the USB
module in longwords (provided for ring-buffer, not used
for the Mass Storage Class)
PutPacket4S
Writes data for transfer to the host controller to the USB
module in longwords (not provided for ring-buffer, highspeed version)
SetControlOutContents
Overwrites data with that sent from the host
SetUsbModule
Makes USB module initial settings
ActBusReset
Clears FIFO on receiving bus reset, etc.
ActBusVcc
Carries out USB cable connection interrupts (not used
in this sample application)
ConvRealn
Reads data of a specified byte length from a specified
address
ConvReflexn
Reads data of a specified byte length from specified
addresses, in reverse order
In UsbMain.c, interrupt factors are discriminated by the USB interrupt flag register, and functions
are called according to the interrupt type. Also, packets are sent and received between the host
controller and function modules.
Table 4.2-3 DoRequest.c
File in Which
Stored
DoRequest.c
Function Name
Purpose
DecStandardCommands
Decodes command issued by host controller, and
processes standard commands
DecVenderCommands
Processes vendor commands
Rev. 1.0, 01/03, page 25 of 74
During control transfer, commands sent from the host controller are decoded and processed. In this
sample program, a vendor ID of 045B (vendor: Hitachi) is used. When the customer develops a
product, the customer should obtain a vendor ID at the USB Implementers' Forum. Because
vendor commands are not used, DecVenderCommands does not perform any action. In order to
use a vendor command, the customer should develop a program.
Table 4.2-4 DoRequestBOT_StorageClass.c
File in Which
Stored
Function Name
Purpose
DoRequestBOT_
DecBOTClass
StorageClass.c
Commands
Processes USB Mass Storage Class (Bulk-Only Transport)
commands
This function carries out processing according to the Mass Storage Class (Bulk-Only Transport)
commands (Bulk-Only Mass Storage Reset and Get Max LUN).
The Bulk-Only Mass Storage Reset command resets all of the interfaces used in Bulk-Only
Transport.
The Get Max LUN command returns the largest logical unit number used by peripheral devices. In
this sample program, there is one logical unit, so a value of 0 is returned to the host.
Table 4.2-5 DoControl.c
File in Which
Stored
Function Name
Purpose
DoControl.c
ActControl
Controls the setup stage of control transfer
ActControlIn
Controls the data stage and status stage of control IN
transport (transport in which the data stage is in the IN
direction)
ActControlOut
Controls the data stage and status stage of control OUT
transport (transport in which the data stage is in the OUT
direction)
ActControlInOut
Allocates the data stage and the status stage of control
transfer to ActControlIn and ActControlOut
When a control transfer interrupt (SETUP TS) is generated, ActControl obtains the command, and
decoding is carried out by DecStandardCommands to discern the transfer direction of the
command. Next, when a control transfer interrupt (EP0o TS, EP0i TR, or EP0i TS) occurs,
ActControlIn or ActControlOut is called depending on the transfer direction of the command, and
the data stage and status stage are carried out by ActControlInOut.
Rev. 1.0, 01/03, page 26 of 74
Table 4.2-6 DoBulk.c
File in Which
Stored
Function Name
Purpose
DoBulk.c
ActBulkOut
Performs bulk-out transfer
ActBulkIn
Performs bulk-in transfer
ActBulkInReady
Performs preparations for bulk-in transfer
These functions carry out processing involving bulk transport. ActBulkInReady is not used in
Mass Storage Class (Bulk-Only Transport).
Table 4.2-7 DoBOTMSClass.c
File in Which
Stored
Function Name
DoBOTMSClass.c
Purpose
ActBulkOnly
Divides Bulk-Only Transport into separate stages
ActBulkOnlyCommand
Controls CBW for Bulk-Only Transport
ActBulkOnlyIn
Controls data transport and status transport (when
the data stage is in the IN direction)
ActBulkOnlyOut
Controls data transport and status transport (when
the data stage is in the OUT direction)
With DoBOTMSClass.c, control of the two or three stages of the Mass Storage Class (Bulk-Only
Transport) is carried out, and operation is carried out in accordance with the specifications.
Table 4.2-8 DoSCSICommand.c
File in Which
Stored
Function Name
Purpose
DoSCSI
DecBotCmd
Processes SCSI commands sent from the host using
Bulk-Only Transport
SetBotCmdErr
Handles SCSI command error
Command.c
The DoSCSICommand.c function is used to analyze SCSI commands sent from the host PC and
prepare for the next data transport or status transport.
Figure 4.4 shows the interrelationship between the functions explained in table 4.2. The upper-side
functions can call the lower-side functions. Also, multiple functions can call the same function. In
the stationary state, CallResetException calls other functions, and in the case of a transition to the
USB communication state which occurs on an interrupt, interrupt function CallInterrupt calls
BranchOfInt, and BranchOfInt calls other functions. Figure 4.4 shows the hierarchical relation of
functions; there is no order for function calling. For information on the order in which functions
are called, please refer to the flow charts of section 5, Sample Program Operation.
Rev. 1.0, 01/03, page 27 of 74
CallResetException
SetPowerOnSection
CallInterrupt
InitMemory
_INITSCT
InitSystem
SetUsbModule
BranchOfInt
ActControl
ActBusReset
ActControlInOut
ActControlOut
DecStandardCommands
ConvReflexn
GetPacket
DecBOTClassCommands
ActControlIn
SetControlOutContents
PutPacket
DecVenderCommands
ActBulkOnly
ActBulkOnlyOut
ActBulkOnlyCommand
ActBulkOut
DecBotCmd
ConvRealn
GetPacket
ConvReflexn
GetPacket4S
ActBulkOnlyIIn
ActBulkIn
PutPacket
ConvReflexn
PutPacket4S
SetBotCmdErr
Figure 4.4 Interrelationship between Functions
Rev. 1.0, 01/03, page 28 of 74
4.5
RAM Disk
In the sample program provided here, the SDRAM in the SH7705SE is selected as the disk device,
and the host PC is notified that the SH7705SE (function) is the disk.
As shown in figure 4.5, the disk device of the function has a master boot block and a partition boot
block. When the system is booted, an initialization routine is used to write the master boot block
and the partition boot block to the RAM disk area on the SDRAM.
Sector 0
Master boot block
Sector 20
Partition boot block
Figure 4.5 Disk Construction
SCSI commands are used to allow function access from the host PC (saving and loading data). In
order to work with SCSI commands, the user needs to understand the construction shown in
figure 4.5 and then write the operation.
Rev. 1.0, 01/03, page 29 of 74
4.6
Operation of SCSI Commands That Are Supported
Table 4.3 shows the SCSI commands that are supported by the sample program.
Table 4.3
SCSI Command Operations
Command Name
Transport
Name
INQUIRY
CBW
This decodes a command and recognizes it as an INQUIRY
command. It then prepares to send the INQUIRY information
(96 bytes) stored in the ROM.
Data
This sends the INQUIRY information to the host PC using bulkin transport.
CSW
This sends the results of executing a command to the PC. If
the data being sent is 96 bytes or less, the transmission will
end successfully.
CBW
This decodes the command and recognizes it as a READ
CAPACITY command. It then reads the number of bytes per
sector, which is stored in the partition boot block on the disk
device open on the SDRAM, and the value stored for the total
number of sectors on the disk, and prepares to send the READ
CAPACITY information (8 bytes).
READ
CAPACITY
Operation Content
When the medium is inaccessible (the lowest bit of
unit_state[0] is 1), this module recognizes there is no data to
transfer, and follows the procedure described in section 4.7,
Processing If an Error Occurs (4). It also specifies the value
returned by REQUEST SENSE as NOT READY.
Data
This sends the READ CAPACITY information to the host PC
using bulk-in transport.
When the medium is inaccessible, the same volume of data
(0x00) as that requested by the host PC is sent back.
CSW
This sends the results of the command execution to the host
PC.
When the medium is inaccessible, the command Fail (CSW
status 0x01) is sent back.
Rev. 1.0, 01/03, page 30 of 74
Command Name
Transport
Name
READ(10)
CBW
Operation Content
This decodes the command and recognizes it as the
READ(10) command. It then prepares to send the data for a
specified read sector volume from the Disk device open on the
SDRAM.
When the medium is inaccessible (the lowest bit of
unit_state[0] is 1), this module recognizes there is no data to
transfer, and follows the procedure described in section 4.7,
Processing If an Error Occurs (4). It also specifies the value
returned by REQUEST SENSE as NOT READY.
Data
This sends the data from the read sectors to the host PC using
bulk-in transport.
When the medium is inaccessible, the same volume of data
(0x00) as that requested by the host PC is sent back.
CSW
This sends the results of executing the READ(10) command to
the host PC.
When the medium is inaccessible, the command Fail (CSW
status 0x01) is sent back.
WRITE(10)
CBW
This decodes the command and recognizes it as the
WRITE(10) command. It then prepares to receive the data of
the specified sector volume from the specified write sector in
the disk device open on the SDRAM.
When the medium is inaccessible (the lowest bit of
unit_state[0] is 1), this module recognized there is no data to
transfer, and follows the procedure described in section 4.7,
Processing If an Error Occurs (9). It also specifies the value
returned by REQUEST SENSE as NOT READY.
Data
This receives the write sector data from the host PC using
bulk-out transport.
When the medium is inaccessible, the data sent from the host
PC is skipped.
CSW
This notifies the host PC that the operation has been
completed successfully.
When the medium is inaccessible, the command Fail (CSW
status 0x01) is sent back.
Rev. 1.0, 01/03, page 31 of 74
Command Name
REQUEST
SENSE
PREVENT
ALLOW MEDIUM
REMOVAL
Transport
Name
Operation Content
CBW
This decodes the command and recognizes it as the
REQUEST SENSE command. It then prepares to send the
returned value (the results of executing the previous SCSI
command).
Data
This sends the returned value to the host PC using bulk-in
transport.
CSW
This sends the results of the command execution to the host
PC. The transmission is completed successfully as long as the
data consists of 18 bytes or less.
CBW
This decodes the command and recognizes it as the
PREVENT ALLOW MEDIUM REMOVAL command. It then
prepares to notify the host PC that the operation has been
successfully completed.
When the medium is inaccessible (the lowest bit of
unit_state[0] is 1), the command is specified as Fail, and the
value returned by REQUEST SENSE is specified as NOT
READY.
Data
Data transport does not exist for this command.
CSW
This notifies the host PC that the operation has been
completed successfully.
When the medium is inaccessible, the command Fail (CSW
status 0x01) is sent back.
TEST UNIT
READY
CBW
This decodes the command and recognizes it as the TEST
UNIT READY command. It then prepares to notify the host PC
that the operation has been successfully completed.
When the medium is inaccessible (the lowest bit of
unit_state[0] is 1), the command is specified as Fail, and the
value returned by REQUEST SENSE is specified as NOT
READY.
Data
Data transport does not exist for this command.
CSW
This notifies the host PC that the operation has been
completed successfully.
When the medium is inaccessible, the command Fail (CSW
status 0x01) is sent back.
Rev. 1.0, 01/03, page 32 of 74
Command Name
Transport
Name
VERIFY(10)
CBW
Operation Content
This decodes the command and recognizes it as the
VERIFY(10) command. It then prepares to notify the host PC
that the operation has been successfully completed.
When the medium is inaccessible (the lowest bit of
unit_state[0] is 1), the command is specified as Fail, and the
value returned by REQUEST SENSE is specified as NOT
READY.
Data
Data transport does not exist for this command.
CSW
This notifies the host PC that the operation has been
completed successfully.
When the medium is inaccessible, the command Fail (CSW
status 0x01) is sent back.
STOP/START
UNIT
CBW
This decodes the command and recognizes it as the
STOP/START UNIT command. It then sets the lowest bit of the
global variable unit_state[0] to 1 when the removal or halt of
the medium was specified by the command. In other case, the
lowest bit of the global variable unit_state[0] is set to 0.
To recover from the inaccessible condition, the user must set
the lowest bit of unit_state[0] to 0.
MODE SENSE(6)
Commands that
are not supported
Data
Data transport does not exist for this command.
CSW
This notifies the host PC that the operation has been
completed successfully.
CBW
This decodes the command and recognizes it as the MODE
SENSE(6) command. It then prepares to send the MODE
SENSE information required.
Data
This sends the MODE SENSE information to the host PC
using bulk-in transport.
CSW
This sends the results of the command execution to the host
PC.
CBW
This decodes the command and, if it is an unsupported
command, specifies INVALID FIELD IN CDB for the returned
value of the REQUEST SENSE command. It then prepares to
transport the data.
Data
If the host PC has requested data using bulk-in transport, this
sends the same volume of data (0x00) as that requested by
the host PC. If the host PC has sent data using bulk-out
transport, the number of bytes received are counted. If there is
no data transport, no operation is carried out.
CSW
This sends back the command Fail (CSW status 0x01) to the
host PC.
Rev. 1.0, 01/03, page 33 of 74
4.7
Processing If an Error Occurs
The errors that may occur during a Mass Storage Class (Bulk-Only Transport) transmission
between the host PC and function and how the function operates when an error occurs are
described below.
The Bulk-Only Transport standard defines the following two types of errors:
• Invalid CBW
• Operation expected by the host PC and operation planned by the function (operation specified
by the SCSI command) do not match (10 cases)
The Bulk-Only Transport standard does not cover any other states.
There are 13 states for data transfer between the host PC and a function as shown in tables 4.4
and 4.5. Cases 1, 6, and 12 are normal transport states.
Table 4.4
Data Transport States between Host PC and Function.
What the Host PC Expects
What
the
function
plans
No data transport
No Data
Transport
Data Reception
from Function
Data Send to
Function
(1) Hn = Dn
(4) Hi > Dn
(9) Ho > Dn
(5) Hi > Di
Data send to host PC
(2) Hn < Di
(6) Hi = Di
(10) Ho < > Di
(7) Hi < Di
(11) Ho > Do
Data reception from host PC
(3) Hn < Do
(8) Hi < > Do
(12) Ho = Do
(13) Ho < Do
Rev. 1.0, 01/03, page 34 of 74
Table 4.5
Explanation of Data Transport States between Host PC and Function
Case No.
Relation between Host PC and Function
1
The host PC expects no data transport and the function plans no data transport.
2
The host PC expects no data transport but the function plans to send data to the host
PC.
3
The host PC expects no data transport but the function plans to receive data from the
host PC.
4
The host PC expects to receive data from the function but the function plans no data
transport to the host PC.
5
The amount of data the function sends to the host PC is less than the amount of data
the host PC expected to receive from the function.
6
The amount of data the function sends to the host PC is equal to the amount of data
the host PC expected to receive from the function.
7
The amount of data the function sends to the host PC is greater than the amount of
data the host PC expected to receive from the function.
8
The host PC expects to receive data from the function but the function plans to
receive data from the host PC.
9
The host PC expects to send data to the function but the function plans no data
transport to the host PC.
10
The host PC expects to send data to the function but the function plans to send data
to the host PC.
11
The amount of data the function receives from the host PC is less than the amount of
data the host PC expected to send to the function.
12
The amount of data the function receives from the host PC is equal to the amount of
data the host PC expected to the function.
13
The amount of data the function receives from the host PC is greater than the
amount of data the host PC expected to send to the function.
Rev. 1.0, 01/03, page 35 of 74
Table 4.6 shows sample error conditions that may be generated.
Table 4.6
Sample Error Conditions
Case No.
Relation between Host PC and Function
2
When a READ command is issued from the host PC, the amount of data to be
transported in the USB data transport is 0 while the amount of data specified by the
SCSI command is a value other than 0.
3
When a WRITE command is issued from the host PC, the amount of data to be
transported in the USB data transport is 0 while the amount of data specified by the
SCSI command is a value other than 0.
4
When a READ command is issued from the host PC, the amount of data to be
transported in the USB data transport is 0 while the amount of data specified by the
SCSI command is 0.
5
When a READ command is issued from the host PC, the amount of data specified by
the SCSI command is less than the amount of data to be transported in the USB data
transport.
7
When a READ command is issued from the host PC, the amount of data specified by
the SCSI command is greater than the amount of data to be transported in the USB
data transport.
8
Even though a WRITE command has been issued from the host PC, the host PC
requests for data in the USB data transport.
9
When a WRITE command is issued from the host PC, the amount of data to be
transported in the USB data transport is a value other than 0 while the amount of
data specified by the SCSI command is 0.
10
Even though a READ command has been issued from the host PC, the host PC
sends data in the USB data transport.
11
When a WRITE command is issued from the host PC, the amount of data specified
by the SCSI command is less than the amount of data to be transported in the USB
data transport.
13
When a WRITE command is issued from the host PC, the amount of data specified
by the SCSI command is greater than the amount of data to be transported in the
USB data transport.
Rev. 1.0, 01/03, page 36 of 74
Table 4.7 shows how a function operates when each error condition occurs.
Table 4.7
Function Operation for Each Error Condition
Case No.
Relation between Host PC and Function
2, 3
•
Set 0x02 as the CSW status.
4, 5
•
The function adds data to become equal to the data length set in
dCBWDataTransferLength and then sends data to the host PC.
•
Set the amount of data added in the data transport in dCBWDataResidue of
CSW.
•
Set 0x00 as the CSW status.
•
The function sends data to the host PC up to the data length set in
dCBWDataTransferLength.
•
Set 0x02 as the CSW status.
•
The function receives data from the host PC up to the data length set in
dCBWDataTransferLength.
•
Set the difference between the amount of data received in the data transport and
the amount of data processed by the function in dCBWDataResidue of CSW.
•
Set 0x01 as the CSW status.
•
The function receives data from the host PC up to the data length set in
dCBWDataTransferLength.
•
Set 0x02 as the CSW status.
7, 8
9, 11
10, 13
Rev. 1.0, 01/03, page 37 of 74
Figures 4.6 to 4.8 show the processing when a data transport error occurs.
Start
CBW is received
No
Is CBW data valid?
Command
transport
Yes
Amount of data planned by
host=0 while
Amount of data planned by
function !=0
EP2 is stalled
Yes
No
Case:2, 3
Data transport direction is
judged from CBWk
Bulk-out
0x02 is set in
bCSWStatus
Bulk-in
Data
transport
Bulk-in operation in
data transport
Bulk-out operation in
data transport
CSW is sent
Status
transport
End
Figure 4.6 Error Processing Flow in Data Transport (1)
Rev. 1.0, 01/03, page 38 of 74
Bulk-in operation
in data transport
Amount of data planned by host
=
Amount of data planned by function
No
Yes
Data us sent in
data transport
Amount of data planned by host
>
Amount of data planned by function
No
Yes
Case: 6
Set 0x00 in
bCSWStatus
0 is added until data is equal to
the data length required by
the host and then data is output
Data is sent until the
amount of data planned
by the host has been sent
Set the additional
amount of data in
dCSWDataResidue
Set the amount of data
not yet sent in
dCSWDataResidue
Case: 4, 5
Set 0x00 in
bCSWStatus
Case: 7, 8
Set 0x02 in
bCSWStatus
Status transport operation
Figure 4.7 Error Processing Flow in Data Transport (2)
Rev. 1.0, 01/03, page 39 of 74
Bulk-out operation
in data transport
Does the command to be executed
by the function match the transport
direction in data transport?
No
Yes
Amount of data planned by host
=
Amount of data planned by function
No
Yes
Data is received in
data transport
Amount of data planned by host
>
Amount of data planned by function
No
Yes
Data is received in
data transport
Set the overflowed
amount of data in
bCSWDataResidue
Case: 1, 12
Set 0x00 in
bCSWStatus
Case: 9, 11
Set 0x01 in
bCSWStatus
Data is received until the
amount of data planned by
the host has been received
Dummy read is performed
for the amount of data
planned by the host
Set the amount of data
not yet sent in
bCSWDataResidue
Case: 13
Set 0x02 in
bCSWStatus
Status transport
operation
Figure 4.8 Error Processing Flow in Data Transport (3)
Rev. 1.0, 01/03, page 40 of 74
Case: 10
Set 0x02 in
bCSWStatus
When a Mass Storage Class (Bulk-Only Transport) transmission is carried out, transport of the
CBW initiates a series of data transfers, and when the CSW is transported to the host PC, a series
of data transfers is processed. This status contains two items: dCSWStatus that indicates the
transport result, and dCSWDataResidue that indicates the number of error bytes.
In this sample program, the following two fields are used to create these two items.
• dCBWDataTransferLength field of CBW packet
• dCSWDataTransferResidue field of CSW packet
The dCBWDataTransferLength field of the CBW packet is used as the variable in which the
number of data bytes the host PC specifies to be handled in the data transport is entered.
The dCSWDataTrasferResidue field of the CSW packet is used as the variable in which the
number of data bytes the function handles in the data transport is entered.
When the CBW transport has been completed, the number of data bytes planned to be handled in
the data transport by the host PC and the function are stored in the dCBWDataTransferLength and
dCSWDataTransferResidue fields, respectively.
Data is transferred in the data transport according to the flowcharts.
If data transport between the host PC and function has been processed without errors, the values in
the dCBWDataTransferLength and dCSWDataTransferResidue fields are both subtracted by the
number of bytes that have been transferred for every data transfer in the data transport. For other
cases, the difference between the number of data bytes the host PC requires to be handled in the
data transport and the number of data bytes the function has handled in the data transport is stored
in the dCSWDataTransferResidue field of the CSW packet, and operation then moves to the status
transport.
Rev. 1.0, 01/03, page 41 of 74
Command
transport
Data
transport
CBW
IN/OUT
IN/OUT
Status
transport
...
IN/OUT
dCBWDataTransferLength
Amount of data planned by the host
dCSWDataResidue
Amount of data planned by the device
dCBWDataTransferLength
Amount of data planned by the host
Amount of data planned by the device
dCSWDataResidue
dCBWDataTransferLength
Amount of data planned by the host
dCSWDataResidue
Amount of data planned by the device
CSW
0 is returned because it is
equal to the amount of
data planned by the host
The amount of data
insufficient for that planned
by the host is returned
Insufficient
The amount of data
exceeding that planned
by the host is returned
Exceeding
Figure 4.9 Each Stage in Bulk-Only Transport
Rev. 1.0, 01/03, page 42 of 74
Section 5 Sample Program Operation
In this chapter, the operation of the sample program is explained, relating it to the operation of the
USB function module.
5.1
Main Loop
When the microcomputer is in the reset state, the internal state of the CPU and the registers of
internal peripheral modules are initialized. Next, reset interrupt function CallResetException is
called to process the reset exception and to call function SetPowerOnSection. Figure 5.1 is a flow
chart for the operation from the reset interrupt to the stationary state.
Microcomputer reset
CallResetException
Microcomputer
initial settings
SetPowerOnSection
RAM is cleared to 0
After initial settings, the program
enters the stationary state.
Variables are initialized
Stationary state
(infinite loop)
Figure 5.1 Main Loop
Rev. 1.0, 01/03, page 43 of 74
5.2
Types of Interrupts
As explained in section 4, the interrupts used in this sample program are indicated by the interrupt
flag register 0 (USBIFR0); there are a total of eight types of interrupts. When an interrupt source
occurs, the corresponding bits in the interrupt flag register are set to 1, and a USBFI0 interrupt
request is sent to the CPU. In the sample program, the interrupt flag registers are read as a result of
this interrupt request, and the corresponding USB communication is performed. Figure 5.2 shows
the interrupt flag registers and their relation to USB communication.
USB interrupt flag register 0 (USBIFR0)
Bit:
Bit name:
7
6
5
BRST
EP1
FULL
EP2
TR
3
4
2
EP2 SETUP EP0o
TS
EMPTY TS
Cable connection Bulk-Only Transport
1
0
EP0i
TR
EP0i
TS
Control transfer
USB interrupt flag register 1 (USBIFR1)
Bit:
7
Bit name:
6
5
4
3
2
1
0
VBUS
MIN
EP3
TR
EP3
TS
VBUSF
Not used
Not used* Not used
Note: This sample program does not support interrupt transfer, so EP3 interrupts are not used.
Figure 5.2 Types of Interrupt Flags
Rev. 1.0, 01/03, page 44 of 74
5.2.1
Method of Branching to Different Transfer Processes
In this sample program the transfer method is determined by the type of interrupt from the USB
module. Branching to the different transfer methods is executed by BranchOfInt in UsbMain.c.
Table 5.1 shows the relations between the types of interrupts and the functions called by
BranchOfInt.
Table 5.1
Interrupt Types and Functions Called on Branching
Register Name
USBIFR0
Bit
Bit Name
Name of Function Called
0
EP0i TS
ActControlInOut
1
EP0i TR
ActControlInOut
2
EP0o TS
ActControlInOut
3
SETUP TS
ActControl
4
EP2 EMPTY
ActBulkOnly
5
EP2 TR
ActBulkOnly
6
EP1 FULL
ActBulkOnly
7
BRST
ActBusReset
The EP0I TS and EP0o TS interrupts are used both for control-in and control-out transfer. Hence
in order to manage the direction and stage of control transfer, the sample program has three states:
TRANS_IN, TRANS_OUT, and WAIT. For details, refer to section 5.4, Control Transfers.
In the SH7705 hardware manual, operation of the USB function module when an interrupt occurs,
and a summary of operation on the application side, are described. From the next section, details
of application-side firmware are explained for each USB transfer method.
Rev. 1.0, 01/03, page 45 of 74
5.3
Interrupt on Cable Connection (BRST)
This interrupt occurs when the cable of the USB function module is connected to the host
controller. On the application side, after completion of initial microcomputer settings, an USB D+
PULLUP output port is employed to pull-up the USB data bus D+. By means of this pull-up, the
host controller can recognize that the device has been connected (figure 5.3).
Sample program
USB function module
SetPowerOnSection
Microcomputer
initial settings
Cable disconnected
VBUS = 0
UDC core reset
USB cable connected
Write 0 to pull-up
enable bit of USBDMA
setting register.
Set USB1_pwr_en pin
to a low
Cable
connection
Set USB1_pwr_en pin to output
(high) by USBDMA setting register
Set port D6 to USB clock input pin
Set port E2 to USB1_pwr_en pin
Main loop
Stop USBF clock by
standby control register 3
No
USB1_pwr_en
D+ PULLUP
enabled?
Set USB interrupt level by interrupt
priority order setting register G
Yes
Set 48-MHzclock to be used by
USB to EXCPG control register
UDC core reset
canceled
Bus reset signal received
USBIFR0/BRST = 1
Bus reset interrupt
USBFI0
interrupt
generated
Set USB transceiver 1 by extra
pin function controller register
ActBusReset
Interrupt flag cleared
Set USBF to operate by
standby control register 3
All FIFOs cleared
Wait for setup command
receive complete interrupt
All stall bits cleared
Set interrupt request used by
USB interrupt enable register
Media status record
variables cleared
Set vector no. for interrupt request
by USB interrupt selection register
Figure 5.3 Interrupt on Cable Connection
Rev. 1.0, 01/03, page 46 of 74
5.4
Control Transfers
In control transfers, bits 0 to 3 of the interrupt flag registers are used. Control transfers can be
divided into two types according to the direction of data in the data stage (figure 5.4). In the data
stage, data transfers from the host controller to the USB function module are control-out transfers,
and transfers in the opposite direction are control-in transfers.
Control-out transfers
Host controller
USB function module
Data
(Data stage)
Control-in transfers
Host controller
USB function module
Data
(Data stage)
Figure 5.4 Control Transfers
Control transfers consist of three stages: setup, data (no data is possible), and status (figure 5.5).
Further, the data stage consists of multiple bus transactions.
In control transfers, stage changes are recognized through the reversal of the data direction. Hence
the same interrupt flag is used to call a function to perform control-in or control-out transfers (cf.
table 5.1). For this reason, the firmware must use states to manage the type of control transfer
currently being performed, whether control-in or control-out, (figure 5.5) and must call the
appropriate function. States in the data stage (TRANS_IN and TRANS_OUT) are determined by
commands received in the setup stage.
Rev. 1.0, 01/03, page 47 of 74
Setup stage
Control-in
Firmware state
Control-out
Firmware state
No data
Firmware state
Data stage
SETUP (0)
IN (1)
IN (0)
DATA0
DATA1
DATA0
WAIT
Satus stage
...
IN (0/1)
OUT (1)
DATA0/1
DATA1
TRANS_IN
WAIT
SETUP (0)
OUT (1)
OUT (0)
DATA0
DATA1
DATA0
WAIT
...
OUT (0/1)
IN (1)
DATA0/1
DATA1
TRANS_OUT
WAIT
SETUP (0)
IN (1)
DATA0
DATA1
WAIT
TRANS_OUT
WAIT
Figure 5.5 Status in Control Transfers
5.4.1
Setup Stage
In the setup stage, the host and function modules exchange commands. For both control-in and
control-out transfer, the firmware goes into the WAIT state. Depending on the type of command
issued, discrimination between control-in transfer and control-out transfer is performed, and the
state of the firmware in the data stage (TRANS_IN or TRANS_OUT) is determined.
• Commands for control-in transfers:
GetDescriptor (Standard command)
Get Max LUN (Class command)
• Commands for control-out transfers: Bulk-Only Mass Storage Reset (Class command)
Figure 5.6 shows operation of the sample program in the setup stage. The figure on the left shows
operation of the USB function module.
Rev. 1.0, 01/03, page 48 of 74
USB function module
Sample program
BranchOflnt
ActControl
Setup token received
SETUP TS flag cleared
EP0o/EP0i FIFO cleared
8-byte command data
received at EP0s
Firmware state set to WAIT
Application processing
command?
No
Read pointer and write pointer for
command buffer initialized
Yes
Automatic
processing by
USB module
Setup command receive
complete flag set
(USBIFR0/SETUP TS=1)
GetPacket
Read data from EP0s FIFO
USBFI0 interrupt
genarated
EP0s read complete bit set to 1
(USBTRG/EP0s RDFN = 1)
To data stage
DecStandardCommands
Yes
Vender command?
No
Yes
DecBOTClass
Commands
DecVender
Commands
Class command?
No
No
Corresponding
command?
Corresponding
command?
No
Yes
No
Corresponding
standard command
which should
be processed?
Yes
Yes
Process preparation of
Get/Set Descriptor
Firmware sate set to STALL
Yes
Firmware sate
STALL?
No
Yes
Transfer direction
is IN?
No
Firmware state set to
TRANS_IN
Firmware state set to
TRANS_OUT
Mask EP0i/EP0o interrupt
Set interrupt enable bit for
Control In Transfer
Set interrupt enable bit for
Control Out Transfer
Set EP0 STALL bit
Write data to FIFIO
PutPacket
To data stage
Figure 5.6 Setup Stage
Rev. 1.0, 01/03, page 49 of 74
5.4.2
Data Stage
In the data stage, the host and function module exchange data. The firmware state becomes
TRANS_IN for control-in transfers, and TRANS_OUT for control-out transfers, according to the
result of decoding of the command in the setup stage. Figures 5.7 and 5.9 show the operation of
the sample program in the data stage of control transfer.
USB function module
Sample program
In-token received
BranchOfInt
ActControlInOut
No
USBTRG/EP0s RDFN
set to 1?
NAK
Firmware state is
TRANS_OUT?
Yes
To Control-out
transfer
(figure 5.8)
No
Yes
ActControl In
Receive
complete interrupt?
(USBIFR0/EP0o TS)
When data direction changes,
data stage is completed and
status stage is entered.
Yes
No
Valid data in
EP0i FIFO?
NAK
Yes
No
Status stage
USBIFR0/EP0i TS
interrupt flag cleared
Data sent to host
PutPacket
ACK
EP0i transmit flag set
(USBIFR0/EP0iTS=1)
Data written to USBEP0i
data register
USBFI0 interrupt
generated
EP0i packet cnable bit set to 1
(USBTRG/EP0i PKTE=1)
Figure 5.7 Data Stage (Control-In Transfer)
Rev. 1.0, 01/03, page 50 of 74
Sample program
USB function module
BranchOfInt
Out-token received
ActControlInOut
Firmware state is
TRANS_OUT?
To Control-in
transfer
(figure 5.7)
No
Yes
ActControlOut
Any space in EP1 FIFO?
NO
NAK
Receive
complete interrupt?
(USBIFR0/EP0o TS)
When data direction changes,
data stage is completed and
status stage is entered.
NO
YES
YES
Data received from host
ACK
USBFI0 interrupt
generated
EP0o receive complete flag set
(USBIFR0/EP0o TS=1)
Status stage
EP0o receive complete
flag cleared
(USBIFR0/EP0o TS = 0)
GetPacket
Data read from USBEP0o receive
data size register (USBEPSZ0o)
Out-token received
Data read from USBEP0o
data register (USBEPDR0o)
USBTRG/EP0s RDFN
set to 1?
YES
NO
NAK
EP0o read complete bit set to 1
(USBTRG/EP0o RDFN=1)
Figure 5.8 Data Stage (Control-Out Transfer)
Rev. 1.0, 01/03, page 51 of 74
5.4.3
Status Stage
The status stage begins with a token for the opposite direction from the data stage. That is, in
control-in transfer, the status stage begins with an out-token from the host controller; in controlout transfer, it begins with an in-token from the host controller.
Sample program
USB function module
BranchOfInt
Out-token received
ActControlInOut
0 byte received from host
Firmware state is
TRANS_OUT?
ACK
EP0o receive complete flag set
(USBIFR0/EP0o TS=1)
USBFI0 interrupt
To Control-out
transfer
(figure 5.10)
Yes
No
ActControl In
generated
Receive
complete interrupt?
(USBIFR0/EP0o TS)
Control transfer end
No
Data stage
Yes
EP0o-related interrupt
flags excluding SETUP
flag cleared
Firmware state
changed to WAIT
EP0o receive complete flag set to 1
(USBTRG/EP0o RDFN=1)
Control-in transfer end
Figure 5.9 Status Stage (Control-In Transfer)
Rev. 1.0, 01/03, page 52 of 74
Sample program
USB function module
BranchOfInt
ActControlInOut
In-token received
Valid data in
EP0i FIFO?
No
USBFI0 interrupt
generated
Firmware state is
TRANS_OUT?
To Control-in
transfer
(figure 5.9)
No
NAK
Yes
Yes
ActControlOut
0 byte sent to host
Receive
complete interrupt?
(USBIFR0/EP0o TS)
ACK
EP0i transmit complete flag
set (USBIFR0/EP0o TS=1)
Control transfer end
USBFI0 interrupt
generated
No
Yes
Data stage
Receive
complete interrupt?
(USBIFR0/EP0o TS)
No
Yes
EP0o transmit complete flag
cleared (USBIFR0/EP0i TS=0)
EP0i transfer request flag cleared
(USBIFR0/EP0i TR=0)
Firmware state
changed to WAIT
SetControlOutContents
EP0i packet enable bit set to 1
(USBTRG/EP0i PKTE=1)
Figure 5.10 Status Stage (Control-Out Transfer)
Rev. 1.0, 01/03, page 53 of 74
5.5
Bulk Transfers
In bulk transfers, bits 4 to 6 of the interrupt flag register are used. Bulk transfers can also be
divided into two types according to the direction of data transmission (figure 5.11).
When data is transferred from the host controller to the USB function module, the transfer is
called a bulk-out transfer; when data is transferred in the opposite direction, it is a bulk-in transfer.
Bulk-out transfers
Host controller
USB function module
Data
Bulk-in transfers
USB function module
Host controller
Data
Figure 5.11 Bulk Transfers
The Bulk-Only Transport used in the USB Mass Storage Class consists of bulk-in and bulk-out
transfers.
Bulk-Only Transfer comprises two or three stages (see figure 5.12): command transport (CBW),
data transport (this is sometimes not included), and status transport (CSW). In addition, data
transfer is made up of multiple bus transactions.
With Bulk-Only transport, the command transport (CBW) is done using bulk-out transfer, while
the status transport (CSW) is sent using bulk-in transfer. Either bulk-in transfer or bulk-out
transfer may be used for data transport, depending on the direction in which the data is being sent.
Whether bulk-in or bulk-out transfer is used for data transport is determined by the CBW data
received using command transport. In the firmware, whether bulk-in or bulk-out is used for data
transport is controlled by states (TRANS_IN and TRANS_OUT) (see figure 5.12). The
appropriate variables must be loaded by the firmware.
Additionally, the transition in stages from data transport to status transport is handled by data of a
planned length being sent or received using data transport requested by the host PC. Consequently,
the firmware manages the data length sent or received using data transport, and after the transition
between stages, status transport must be used to send the data to the host PC.
If the CBW data received using command transport cannot be acknowledged as valid, the endpoint
is stalled, and no bulk transfer is carried out.
Rev. 1.0, 01/03, page 54 of 74
Command
transport
Bulk In
Firmware state
Bulk Out
Firmware state
No data
Firmware state
CBW
WAIT
CBW
WAIT
Data
transport
IN
IN
Status
transport
...
IN
TRANS_IN
OUT
WAIT
OUT
...
OUT
CSW
TRANS_OUT
WAIT
CSW
CBW
WAIT
CSW
TRANS_OUT
WAIT
Figure 5.12 Various Stages in Bulk-Only Transport
5.5.1
Command Transport
With command transport, the CBW data is transferred from the host to the function.
At this point, the firmware is in the WAIT state. At the stage following reception of the CBW
data, the five types of processing listed below are carried out.
1. The CBW data is stored from the EP1 data register to the work area.
2. A judgment is made as to whether the CBW data is valid.
3. The CSW data is prepared.
4. The contents of the CBW data are decoded, and if there is any data to be sent using data
transport, the data is prepared. (Processing is carried out in the DecBotCmd function.)
5. A distinction is made as to whether the data transport is bulk-in or bulk-out, and the firmware
state (TRANS_IN or TRANS_OUT) is determined.
Figure 5.13 shows the operation carried out by the sample program when command transport is
used. The operation of the USB function module is shown at the left of the illustration.
Rev. 1.0, 01/03, page 55 of 74
USB function module
Sample program
Out-token received
BranchOfInt
ActBulkOnly
31-byte CBW data
received at EP3
TRANS_OUT state?
YES
To data transport
(figure 5.15)
YES
To data transport
(figure 5.14)
NO
UIFR1/EP2i TR
interrupt flag register
NO
TRANS_IN state?
EP3FIFO full status set
(USBIFR0/EP3 FULL = 1)
NO
USBFI0 interrupt generated
State is WAIT and receive
data is in bulk-out FIFO
YES
ActBUlkOnlyCommand
CBW data stored
in work area
GetPacket
NO
Valid CBW data?
YES
EP2 stalled
CSW data prepared
Data
direction determined
by CBW
Bulk-out
Bulk-in
State set to TRANS_IN
State set to TRANS_OUT
SCSI command analyzed
and data transfer prepared
dCBWDataTransferLength=0
and dCSWDataResidue!=0?
NO
Data transport
Figure 5.13 Command Transport
Rev. 1.0, 01/03, page 56 of 74
DecBotCmd
YES
dCSWStatus set
to 0x02
5.5.2
Data Transport
With data transport, data is sent and received between the host and the function.
At this point, the firmware is in either the TRANS_IN or TRANS_OUT state.
If the firmware state is TRANS_IN (bulk-in transport), the following three types of processing are
carried out.
1. Data is sent from the function to the host.
2. If the length of the data sent by the function is shorter than the length planned by the host, 0 is
added.
3. The information to be sent by the CSW is created.
Figure 5.14 shows the operations that take place when data transport (bulk-in transport) is carried
out in the sample program. The operation of the USB function module is shown at the left side of
the illustration.
In this sample software, if the length of the data sent by the function is shorter than the length of
the data requested by the host, 0 is added after the data sent by the function, as noted in the BulkOnly Transport of the USB Mass Storage Class, and after data of the length requested by the host
has been sent, the number of 0 bytes added is reported, using status transport.
In order to carry out this operation, the following is used as global variables: the
dCBWDataTransferLength of the CBW data, the dCSWDataResidue of the CSW data, and the
bCSWStatus of the CSW data.
Rev. 1.0, 01/03, page 57 of 74
USB function module
Sample program
BranchOfInt
Any space
in EP2 FIFO?
Yes
ActBulkOnly
TRANS_OUT state?
No
No
EP2 empty status cleared
(USBIFR0/EP2 EMPTY=0)
Yes
TRANS_IN state?
No
EP2 empty status set
(USBIFR0/EP2 EMPTY=1)
State is WAIT and receive
data is in bulk-out FIFO
USBFI0 interrupt generated
ActBulkOnlyIn
Data length requested by host
(dCBWData TransferLength)
transferred?
Yes
To status transport
(figure 5.16)
No
bCSWStatus = 0x00 and
planned transmit data length
is larger than MaxPacketSize?
Yes (normal path)
No
No (normal path)
bCSWStatus!=0x00?
Yes (error path)
Data written to
transmit register
and sent
Remaining length of data
requested by host
(dCSWDataTransferLength)
is subtracted
Planned transmit
data output prepared
Data written to
transmit register
and sent
ActBulkIn
Planned transmit data length
(dCSWDataRecidue)
is subtracted
0 added Data
output prepared
Remaining length of data
requested by host
(dCBWDataTransferLength)
is subtracted
Data written to
transmit register
and sent
Data length sent from
dCSWDataResidue is
substracted
Remaining length of
data requested by host
(dCBWDataTransferLength)
is subtracted
Work area cleared
ActBulkIn
Data length of additional 0s
(dCSWDataResidue)
is subtracted
Figure 5.14 Data Trans port (Bulk-In Transport)
Rev. 1.0, 01/03, page 58 of 74
ActBulkIn
Figure 5.15 shows the operations that take place when data transport (bulk-out transport) is carried
out in the sample program. The operation of the USB function module is shown at the left side of
the illustration.
If the firmware state is TRANS_OUT (bulk-out transport), the following three types of processing
are carried out.
1. Data from the host is received in the function.
2. Data length is calculated.
3. The information to be sent by the CSW is created.
In this sample software, if the length of the data received by the function is shorter than the length
of the data that the host planned to send, the missing length of data received by the function using
data transport is reported using status transport, as noted in the Bulk-Only Transport of the USB
Mass Storage Class.
In order to carry out this operation, the following is used as global variables: the
dCBWDataTransferLength of the CBW data and the dCSWDataResidue of the CSW data.
Rev. 1.0, 01/03, page 59 of 74
USB function module
Sample program
USBFI0 interrupt
generated
BranchOfInt
Out-token received
NAK
Any space
in EP1 FIFO?
No
ActBulkOnly
Yes
TRANS_OUT
state?
No
Yes
TRANS_IN
state?
No
Data received
from host
State is WAIT and receive
data is in bulk-out FIFO
ACK
No
EP1 FIFO full status set
(USBIFR0/EP1 FULL=1)
ActBulkOnlyOut
EP1FIFO
full interrupt?
(USBIFR0/EP1 FULL)
No
To status transport
(figure 5.17)
Yes
No
Data is to be stored?
Yes
Data read from data
receive register
ActBulkOut
dCBWDataTransferLength and
dCSWDataResidue subtracted
Yes
Sent data longer than
data stored in function?
No
dCBWDataTransferLength
subtracted
Dummy read prepared
Data read from data
receive register
ActBulkOut
dCBWDataTransferLength
subtracted
dCSWDataResidue
is substracted
dCSWStatus set to 0x01
Dammy read prepared
dCSWDataResidue
is substracted
Wait for next interrupt
Read remaining data
from register
Figure 5.15 Data Transport (Bulk-Out Transport)
Rev. 1.0, 01/03, page 60 of 74
5.5.3
Status Transport
With status transport, data is sent from the function to the host.
At this point, the firmware is in either the TRANS_IN or TRANS_OUT state.
If the firmware state is TRANS_IN (bulk-in transport), the following four types of processing are
carried out.
1. EP2 empty status interrupts are inhibited.
2. The system prepares to send the CSW data.
3. The CSW data is issued.
4. The firmware state is set to WAIT.
Figure 5.16 shows the operations that take place when status transport (data transport bulk-in
transport) is carried out in the sample program. The operation of the USB function module is
shown at the left side of the illustration.
Rev. 1.0, 01/03, page 61 of 74
Sample program
USB function module
USBFI0 interrupt generated
BranchOfInt
Yes
Any space in EP2 FIFO?
ActBulkOnly
No
Yes
TRANS_OUT
state?
EP2 empty status cleared
(USBIFR0/EP2 EMPTY=0)
No
Yes
TRANS_IN
state?
No
EP2 empty status set
(USBIFR0/EP2 EMPTY=1)
No
State is WAIT and receive
data is in bulk-out FIFO
Yes
Data length requested by host
(dCBWData TransferLength)
transferred?
ActBulkOnlyIn
No
Yes
To data transport
EP2 empty status
interrupt disabled
CSW data output prepared
bCSWStatus = 0x00 and
dCSWDataResidue! = 0?
Yes
bCSWStatus set
to 0x02
No
Data written to transmit
register and sent
ActBulkIn
State set to WAIT
Figure 5.16 Status Transport (Data Transport Bulk-In Transport)
Rev. 1.0, 01/03, page 62 of 74
Figure 5.17 shows the operations that take place when status transport (data transport bulk-out
transport) is carried out in the sample program. The operation of the USB function module is
shown at the left side of the illustration.
If the firmware state is TRANS_OUT (bulk-out transport), the following four types of processing
are carried out.
1. Preparation is made to send the CSW data.
2. The data is checked to see if any data is missing from the reception.
3. The CSW data is issued.
4. The firmware state is set to WAIT.
In this sample software, if the length of the data received by the function is shorter than the length
of the data that the host planned to send, the missing length of data received by the function using
data transport is reported using status transport, as noted in the Bulk-Only Transport of the USB
Mass Storage Class. In order to do this, a check is made to see if there is any data missing that
should have been received by the function, and if there is, the value of the bCSWStatus of the
CSW data is set to 0x02 (phase error).
Rev. 1.0, 01/03, page 63 of 74
USB function module
Sample program
USBFI0 interrupt
generated
In token received
BranchOfInt
ActBulkOnly
NAK
Valid data in
EP2 FIFO?
No
Yes
TRANS_OUT
state?
No
Yes
TRANS_IN
state?
Data sent to host
No
State is WAIT and
receive data is in
bulk-out FIFO
ACK
EP2 transfer request set
(USBIFR0/EP2 TR=1)
ActBulkOnlyOut
Yes
EP1 FIFO full interrupt?
(USBIFR0/EP1FULL)
No
To data transport
Yes
CSW data
output prepared
dCSWDataResidue! = 0,
dCBWDataTransferLength = 0,
bCSWStatus = 0
No
bCSWStatus set to 0x02
Data written to data
transmit register and sent
ActBulkIn
State set to WAIT
USBIFR0/EP2 TR
interrupt flag cleared
Figure 5.17 Status Transport (Data Transport Bulk-Out Transport)
Rev. 1.0, 01/03, page 64 of 74
Section 6 Analyzer Data
In this chapter, we look at how measurement is carried out with the USB Inspector, a USB
protocol analyzer made by CATC (http://www.catc.com), using the USB function module in the
SH7705, and at what happens to the data as it actually flows along the bus. For more detailed
information on the packets, please see section 2.3.
Note: The Packet # found in front of each packet is the packet number used when measuring.
• INQUIRY command
CBW
(command
transport)
INQUIRY command
DATA
(data
transport)
INQUIRY information
CSW
(status
transport)
INQUIRY command execution result
Rev. 1.0, 01/03, page 65 of 74
• READ CAPACITY command (Normal)
CBW
(command
transport)
READ CAPACITY command
READ CAPACITY information
DATA
(data
transport)
READ CAPACITY command execution result
CSW
(status
transport)
• READ CAPACITY command (When the medium is removed)
CBW
(command
transport)
READ CAPACITY command
DATA
(data
transport)
READ CAPACITY information (invalid data)
CSW
(status
transport)
REQUEST SENSE command execution result (command fail)
Rev. 1.0, 01/03, page 66 of 74
• READ (10) command
CBW
(command
transport)
READ(10) command
READ(10) information
DATA
(data
transport)
CSW
(status
transport)
READ(10) command execution result
Rev. 1.0, 01/03, page 67 of 74
• WRITE (10) command
CBW
(command
transport)
WRITE(10) command
WRITE(10) information
DATA
(data
transport)
CSW
(status
transport)
WRITE(10) command
execution result
Rev. 1.0, 01/03, page 68 of 74
• REQUEST SENSE command
CBW
(command
transport)
REQUEST SENSE command
REQUEST SENSE information
DATA
(data
transport)
CSW
(status
transport)
REQUEST SENSE command execution result
• PREVENT ALLOW MEDIUM REMOVAL command
CBW
(command
transport)
PREVENT ALLOW MEDIUM REMOVAL command (PREVENT)
CSW
(status
transport)
PREVENT ALLOW MEDIUM REMOVAL command execution result
Rev. 1.0, 01/03, page 69 of 74
• TEST UNIT READY command (Normal)
CBW
(command
transport)
TEST UNIT READY command
CSW
(status
transport)
TEST UNIT READY command execution result
• TEST UNIT READY command (When the medium is removed)
CBW
(command
transport)
TEST UNIT READY command
CSW
(status
transport)
TEST UNIT READY command execution result (command fail)
Rev. 1.0, 01/03, page 70 of 74
• VERIFY (10) command
CBW
(command
transport)
VERIFY(10) command
CSW
(status
transport)
VERIFY(10) execution result
• STOP/START UNIT command
CBW
(command
transport)
STOP/START UNIT command (EJECT)
CSW
(status
transport)
STOP/START UNIT execution result
Rev. 1.0, 01/03, page 71 of 74
• MODE SENCE (6) command
CBW
(command
transport)
MODE SENCE(6) command (1C)
MODE SENCE(6) information
DATA
(data
transport)
MODE SENCE(6) command execution result
Rev. 1.0, 01/03, page 72 of 74
CSW
(status
transport)
• READ FORMAT CAPACITIES command (unsupported command)
CBW
(command
transport)
READ FORMAT CAPACITIES command
READ FORMAT CAPACITIES information (invalid data)
DATA
(data
transport)
CSW
(status
transport)
READ FORMAT CAPACITIES command execution result (command fail)
Rev. 1.0, 01/03, page 73 of 74
Rev. 1.0, 01/03, page 74 of 74
SH7705 USB Function Module Mass Storage Class
(Bulk-Only Transport) Application Note
Publication Date: 1st Edition, January 2003
Published by:
Business Operation Division
Semiconductor & Integrated Circuits
Hitachi, Ltd.
Edited by:
Technical Documentation Group
Hitachi Kodaira Semiconductor Co., Ltd.
Copyright © Hitachi, Ltd., 2003. All rights reserved. Printed in Japan.