ST STR9 User manual

November 2008 Rev 2 1/76
UM0290
User manual
STR7/STR9 USB developer kit
Introduction
The STR7/9 USB developer kit is a complete firmware and software package including
examples and demos for all USB transfer types (control, interrupt, bulk and isochronous). It
supports all ST 32-bit USB microcontrollers (STR71x, STR75x and STR91x).
The aim of the STR7/9 USB developer kit is to use the same certified USB library across the
STR7/STR9 microcontroller families and present for each at least one firmware demo per
USB transfer type.
This document presents a description of all the components of the STR7/9 USB Developer
kit, including:
■Common STR7/9 USB library: All processes related to default endpoint and standard
requests
■Joystick mouse demo: Interrupt transfer
■Custom HID: interrupt transfer
■Device Firmware Upgrade (DFU): control transfer
■Mass storage demo: Bulk transfer
■Virtual COM port: Bulk transfer
■USB voice demo (speaker and microphone): Isochronous transfer
www.st.com

Contents UM0290
2/76
Contents
1 STR7/STR9 USB firmware library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1 USB application hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2 USB library core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.1 usb_type.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.2 usb_reg(.c, .h) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2.3 usb_int (.c , .h) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.2.4 usb_core (.c , .h) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.3 Application interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.3.1 usb_istr(.c) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.3.2 usb_conf(.h) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.3.3 usb_endp (.c) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.3.4 usb_prop (.c , .h) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.3.5 usb_pwr (.c , .h) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.4 Implementing a USB application using the STR7/9 USB library . . . . . . . 21
1.4.1 Implementing a no data class specific request . . . . . . . . . . . . . . . . . . . 21
1.4.2 How to implement a data class specific request . . . . . . . . . . . . . . . . . . 21
1.4.3 How to manage data transfers in a non-control endpoint . . . . . . . . . . . 22
2 Joystick mouse demo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3 Custom HID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.1 General description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2 Descriptor topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.3 Custom HID implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.3.1 LEDs control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.3.2 Push button states report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.3.3 ADC converted data transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4 Device firmware upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.1 General description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.2 DFU extension protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.2.2 Phases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.2.3 Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

UM0290 Contents
3/76
4.3 DFU mode selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.3.1 Run-time descriptor set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.3.2 DFU mode descriptor set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.4 Reconfiguration phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.5 Transfer phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.5.1 Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.5.2 Special command/protocol descriptions . . . . . . . . . . . . . . . . . . . . . . . . 34
4.5.3 DFU state diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.5.4 Downloading and uploading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.5.5 Manifestation phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.6 DFU implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.6.1 DFU mode entry mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.6.2 Available DFU images in the STR7/9 USB development kit . . . . . . . . . 37
4.6.3 How to create a DFU Image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5 Mass storage demo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.1 Mass storage demo overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.2 Mass storage protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.2.1 Bulk Only Transfer (BOT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.2.2 Small Computer System Interface (SCSI) . . . . . . . . . . . . . . . . . . . . . . . 42
5.3 Mass storage demo implementations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.3.1 Hardware configuration interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.3.2 Endpoint configurations and data management . . . . . . . . . . . . . . . . . . 44
5.3.3 Class specific requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.3.4 Standard request requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.3.5 BOT state machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.3.6 SCSI protocol implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.3.7 Memory management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.4 How to customize the mass storage demo . . . . . . . . . . . . . . . . . . . . . . . 49
6 Virtual COM port demo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
6.1 Virtual COM port demo proposal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
6.2 Software driver installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
6.3 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
6.3.1 Hardware implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
6.3.2 Firmware implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

Contents UM0290
4/76
7 USB voice demos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
7.1 Isochronous transfer overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
7.2 Audio device class overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
7.3 STR7/9 USB audio speaker demo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
7.3.1 General characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
7.3.2 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
7.3.3 STR91x USB audio speaker using the DMA . . . . . . . . . . . . . . . . . . . . . 62
7.4 STR7/9 USB microphone (only for STR75x and STR91x families) . . . . . 63
7.4.1 General characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
7.4.2 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
8 Revision history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

UM0290 STR7/STR9 USB firmware library
5/76
1 STR7/STR9 USB firmware library
This section describes the firmware interface (called USB Library) used to manage the
STR7/9 USB 2.0 full-speed macrocell.
The main purpose of this firmware library is to provide resources to ease the development of
applications using the USB macrocell in all STR7/9 microcontrollers (STR71x, STR75x and
the STR91x families).
1.1 USB application hierarchy
Figure 1 shows the interaction between the different components of a typical USB
application and the USB library.
Figure 1. USB application hierarchy
The USB library is divided into two layers:
●USB Library Core layer: This layer manages the direct communication with the USB
IP hardware and the USB standard protocol. The USB Library Core is compliant with
the USB 2.0 specification and doesn’t have dependences with any Standard Software
Library of STR7/9 microcontrollers.
●Application Interface layer: This layer presents to the user a complete interface
between the library core and the final application.
Note: The application interface layer and the final application can communicate with the Standard
Software Library to manage the hardware needs of the application.
Hardware (STR microcontroller + Board)
USB IP
USB Application Standard
Library
usb_core
usb_init
usb_regs usb_memusb_int
usb_istr usb_prop usb_endp
Application Interface
USB Library
Core
usb_pwr usb_desc

STR7/STR9 USB firmware library UM0290
6/76
A detailed description of these two layers with coding rules is provided in the next two
sections.
1.2 USB library core
Table 1 presents the USB library core modules:
Table 1. USB library core modules
1.2.1 usb_type.h
This file provides the main types used in the library. These types are dependent on the used
microcontroller family.
Note: The type definitions used in the USB library are the same as those used in the STRxxx
Standard library to guarantee the autonomy of the whole code.
File Description
usb_type.h Types used in the library core. This file is used to guarantee the
independency of the USB library
usb_reg (.h, .c) Hardware abstraction layer
usb_int.c Correct transfer interrupt service routine
usb_init (.h,.c) USB initialization
usb_core (.h , .c) USB protocol management (compliant with chapter 9 of the USB 2.0
specification)
usb_mem(.h,.c) Data transfer management (from/to Packet Memory Area)
usb_def.h USB definitions

UM0290 STR7/STR9 USB firmware library
7/76
1.2.2 usb_reg(.c, .h)
The usb_regs module implements the hardware abstraction layer, it offers a set of basic
functions for accessing the USB macrocell registers.
Note: The available functions have two call versions:
- As a macro: the call is: _NameofFunction(parameter1,...)
- As a subroutine: the call is: NameofFunction(parameter1,...)
1. Common register functions: These functions can be used to set or to get the
common USB registers:
Table 2. Common register functions
Register Function
CNTR
void SetCNTR (u16 wValue)
u16 GetCNTR (void)
ISTR
void SetISTR (u16 wValue)
u16 GetISTR (void)
FNR u16 GetFNR (void)
DADDR
void SetDADDR (u16 wValue)
u16 GetDADDR (void)
BTABLE
void SetBTABLE (u16 wValue)
u16 GetBTABLE (void)

STR7/STR9 USB firmware library UM0290
8/76
2. Endpoint register functions: All operations related to endpoint registers can be
performed with the SetENDPOINT and GetENDPOINT functions. However, several
functions are derived from these to permit direct action on a specific field.
a) Endpoint set/get value
SetENDPOINT : void SetENDPOINT(u8 bEpNum,u16 wRegValue)
bEpNum = Endpoint number, wRegValue = Value to write
GetENDPOINT : u16 GetENDPOINT(u8 bEpNum)
bEpNum = Endpoint number
return value: the endpoint register value
b) Endpoint TYPE field
The EP_TYPE field of the endpoint register could have these defined values:
#define EP_BULK (0x0000) // Endpoint BULK
#define EP_CONTROL (0x0200) // Endpoint CONTROL
#define EP_ISOCHRNOUS (0x0400) // Endpoint ISOCHRONOUS
#define EP_INTERRUPT (0x0600) // Endpoint INTERRUPT
SetEPType : void SetEPType (u8 bEpNum, u16 wtype)
bEpNum = Endpoint number, wtype = Endpoint type (value from the
above define’s)
GetEPType : u16 GetEPType (u8 bEpNum)
bEpNum = Endpoint number
return value: a value from the above define’s
c) Endpoint STATUS field
The STAT_TX / STAT_RX fields of the endpoint register could have these defined
values:
#define EP_TX_DIS (0x0000) // Endpoint TX DISabled
#define EP_TX_STALL (0x0010) // Endpoint TX STALLed
#define EP_TX_NAK (0x0020) // Endpoint TX NAKed
#define EP_TX_VALID (0x0030) // Endpoint TX VALID
#define EP_RX_DIS (0x0000) // Endpoint RX DISabled
#define EP_RX_STALL (0x1000) // Endpoint RX STALLed
#define EP_RX_NAK (0x2000) // Endpoint RX NAKed
#define EP_RX_VALID (0x3000) // Endpoint RX VALID
SetEPTxStatus : void SetEPTxStatus(u8 bEpNum,u16 wState)
SetEPRxStatus : void SetEPRxStatus(u8 bEpNum,u16 wState)
bEpNum = Endpoint number, wState = a value from the above define’s
GetEPTxStatus : u16 GetEPTxStatus(u8 bEpNum)
GetEPRxStatus : u16 GetEPRxStatus(u8 bEpNum)
bEpNum = endpoint number
return value:a value from the above define’s
d) Endpoint KIND field
SetEP_KIND : void SetEP_KIND(u8 bEpNum)
ClearEP_KIND : void ClearEP_KIND(u8 bEpNum)
bEpNum = endpoint number
Set_Status_Out : void Set_Status_Out(u8 bEpNum)

UM0290 STR7/STR9 USB firmware library
9/76
Clear_Status_Out : void Clear_Status_Out(u8 bEpNum)
bEpNum = endpoint number
SetEPDoubleBuff : void SetEPDoubleBuff(u8 bEpNum)
ClearEPDoubleBuff : void ClearEPDoubleBuff(u8 bEpNum)
bEpNum = endpoint number
e) Correct Transfer Rx/Tx fields
ClearEP_CTR_RX : void ClearEP_CTR_RX(u8 bEpNum)
ClearEP_CTR_TX : void ClearEP_CTR_TX(u8 bEpNum)
bEpNum = endpoint number
f) Data Toggle Rx/Tx fields
ToggleDTOG_RX : void ToggleDTOG_RX(u8 bEpNum)
ToggleDTOG_TX : void ToggleDTOG_TX(u8 bEpNum)
bEpNum = endpoint number
g) Address field
SetEPAdress : void SetEPAddress(u8 bEpNum,u8 bAddr)
bEpNum = endpoint number
bAddr = address to be set
GetEPAdress : BYTE GetEPAddress(u8 bEpNum)
bEpNum = endpoint number
3. Buffer description table functions: These functions are used to set or get the
endpoints’ receive and transmit buffer addresses and sizes.
a) Tx/Rx buffer address fields
SetEPTxAddr : void SetEPTxAddr(u8 bEpNum,u16 wAddr);
SetEPRxAddr : void SetEPRxAddr(u8 bEpNum,u16 wAddr);
bEpNum = endpoint number
wAddr = address to be set (expressed as PMA buffer address)
GetEPTxAddr : u16 GetEPTxAddr(u8 bEpNum);
GetEPRxAddr : u16 GetEPRxAddr(u8 bEpNum);
bEpNum = endpoint number
return value : address value (expressed as PMA buffer address)
b) Tx/Rx buffer counter fields
SetEPTxCount : void SetEPTxCount(u8 bEpNum,u16 wCount);
SetEPRxCount : void SetEPRxCount(u8 bEpNum,u16 wCount);
bEpNum = endpoint number
wCount = counter to be set
GetEPTxCount : u16 GetEPTxCount(u8 bEpNum);
GetEPRxCount : u16 GetEPRxCount(u8 bEpNum);
bEpNum = endpoint number
return value : counter value

STR7/STR9 USB firmware library UM0290
10/76
4. Double-buffered endpoint functions: To obtain high data transfer throughput in bulk
or isochronous modes, double-buffered mode has to be programmed.
In this operating mode some fields of the endpoint registers and buffer description table
cells have different meanings.
To ease the use of this feature, several functions have been developed.
SetEPDoubleBuff: An endpoint programmed to work in bulk mode can be set as
double-buffered by setting the EP-KIND bit. The function SetEPDoubleBuff()
accomplishes this task.
SetEPDoubleBuff : void SetEPDoubleBuff(u8 bEpNum);
bEpNum = endpoint number
FreeUserBuffer: In double-buffered mode the endpoints become mono-directional and
buffer description table cells of the unused direction are applied to handle a second
buffer.
Addresses and counters must be handled in a different way. Rx and Tx Addresses and
counter cells become Buffer0 and Buffer1 cells. Functions dedicated to this operating
mode are provided for in the library.
During a bulk transfer the line fills one buffer while the other buffer is reserved to the
application. A user application has to process data before the arrival of bulk needing a
buffer. The buffer reserved to the application has to be freed in time.
To free the buffer in use from the application the FreeUserBuffer function is
provided:
FreeUserBuffer: void FreeUserBuffer(u8 bEpNum, u8 bDir);
bEpNum = endpoint number
a) Double buffer addresses
These functions set or get the buffer address value in the buffer description table
for double buffered mode.
SetEPDblBuffAddr : void SetEPDblBuffAddr(u8 bEpNum,u16
wBuf0Addr,u16 wBuf1Addr);
SetEPDblbuf0Addr : void SetEPDblBuf0Addr(u8 bEpNum,u16 wBuf0Addr);
SetEPDblbuf1Addr : void SetEPDblBuf1Addr(u8 bEpNum,u16 wBuf1Addr);
bEpNum = endpoint number
wBuf0Addr, wBuf1Addr = buffer addresses (expressed as PMA buffer
addresses)
GetEPDblBuf0Addr : u16 GetEPDblBuf0Addr(u8 bEpNum);
GetEPDblbuf1Addr : u16 GetEPDblBuf1Addr(u8 bEpNum);
bEpNum = endpoint number
return value : buffer addresses
b) Double buffer counters
These functions set or get the buffer counter value in the buffer description table
for double buffered mode.
SetEPDblBuffCount: void SetEPDblBuffCount(u8 bEpNum, u8 bDir, u16
wCount);
SetEPDblBuf0Count: void SetEPDblBuf0Count(u8 bEpNum, u8 bDir, u16
wCount);
SetEPDblBuf1Count: void SetEPDblBuf1Count(u8 bEpNum, u8 bDir, u16

UM0290 STR7/STR9 USB firmware library
11/76
wCount);
bEpNum = endpoint number
bDir = endpoint direction
wCount = buffer counter
GetEPDblBuf0Count : u16 GetEPDblBuf0Count(u8 bEpNum);
GetEPDblBuf1Count : u16 GetEPDblBuf1Count(u8 bEpNum);
bEpNum = endpoint number
return value : buffer counter
c) Double buffer STATUS
The simple and double buffer modes use the same functions to manage the
Endpoint STATUS except the STALL status for double buffer mode which is
managed by the function:
SetDouBleBuffEPStall: void SetDouBleBuffEPStall(u8 bEpNum,u8 bDir)
bEpNum = endpoint number
bDir = endpoint direction
5. Direct Memory Access (DMA) functions: (only available for STR91x) For the
STR91x, the data transfer from/to the PMA can be managed using the Direct Memory
Access Controller (DMAC) to decrease the CPU usage. This section describes the
different implemented functions used to manage the two DMA transfer modes (unlinked
and linked).
a) DMA Unlinked mode functions
In this mode only a single data packet can be transferred by the DMA. Multiple
endpoints can be mapped on the channel (3 in Tx mode and 10 in Rx mode). The
CPU has to configure the DMA when the new CTR_TX/CTR_RX interrupt is
received.
In fact the CPU needs to decode the endpoint to be served (to get the source and
the destination addresses) before programming the next DMA transfer because
multiple endpoints are mapped on the same channel (Tx/Rx).

STR7/STR9 USB firmware library UM0290
12/76
Note: In unlinked mode the DMA interface doesn’t mask/clear any CTR_TX/CTR_RX interrupt
(the CPU is responsible for this task).
– IN Endpoint:
In unlinked mode only three endpoints can be mapped on the DMA channel using
the following functions:
void DMAUnlinkedModeTxConfig(u8 bEpNum ,u8 index):configure a IN
endpoint to use the DMA in unlinked mode.
bEpNum = Endpoint number: 0 to 9.
index = Endpoint index: 0,1 or 2.
void DMAUnlinkedModeTxEnable(u8 index):Enable a IN Endpoint to
trigger Tx DMA request.
index = Endpoint index: 0,1 or 2.
void DMAUnlinkedModeTxDisable(u8 index):Disable the trigger Tx DMA
request for the IN Endpoint.
index = Endpoint index: 0,1 or 2.
– OUT Endpoint
In unlinked mode up to 10 endpoints can be mapped in the DMA channel using
the following functions:
void DMAUnlinkedModeRxEnable(u8 bEpNum): Enable a OUT Endpoint to
trigger OUT DMA request.
bEpNum = Endpoint number: 0 to 9.
void DMAUnlinkedModeRxDisable(u8 bEpNum): Disable the trigger Rx
DMA request for the OUT Endpoint.
bEpNum = Endpoint number: 0 to 9.
b) DMA Linked Mode Functions
In this mode only a single endpoint can be mapped on the DMA channel (Tx/Rx).
The DMA can prepare linked lists (LLI) in order to manage multiple data packet
transfer without CPU intervention at the end of the single data packet transfer. The
DMA interface provides transfer requests to the DMA controller until the LLI is
completed. The CPU is only responsible for configuring the linked lists (descriptor

UM0290 STR7/STR9 USB firmware library
13/76
chains) before enabling the DMA and, on termination of the DMA transfer (terminal
count interrupt from the DMAC).
– IN Endpoint:
void DMALinkedModeTxConfig(u8 bEpNum): Configure a IN endpoint to
trigger DMA Tx linked mode request.
bEpNum = Endpoint number: 0 to 9.
void DMALinkedModeTxEnable(void): Enable a IN endpoint to trigger
DMA Tx linked mode.
void DMALinkedModeTxDisable(void): Disable the trigger Tx DMA
Linked request for the IN Endpoint.
void SetDMALLITxLength(u8 length): set the DMA linked list length
for IN Endpoint.
length = length of the linked list. This value can be up to 255.
– OUT Endpoint:
void DMALinkedModeRxConfig(u8 bEpNum): Configure a OUT endpoint to
trigger DMA Rx linked mode request.
bEpNum = Endpoint number: 0 to 9.
void DMALinkedModeRxEnable(void):Enable a OUT endpoint to trigger
DMA Rx linked mode.
void DMALinkedModeRxDisable(void):Disable the trigger Rx DMA Linked
request for the OUT Endpoint.
void SetDMALLIRxLength(u8 length):set the DMA linked list length
for OUT Endpoint.
length = length of the linked list. This value can be up to 255.
void SetDMALLIRxPacketNum(u8 PacketNum): Set the number of packets
to be received for each single descriptor of the Linked List.
PacketNum = number of packet. It can be up to 127 packets.
u8 GetDMALLIRxPacketNum(void): Get the number of packets to be
received for each single descriptor of the Linked List.
c) DMA common functions:
To configure the DMA in both unlinked and linked modes the USB library provides
some common functions used to synchronize the USB and the DMAC IPs and to
configure the burst size for IN or OUT endpoints.
void SetDMABurstTxSize(u8 DestBsize): Set the burst size for IN
endpoint (destination burst size)
DestBsize = Destination burst size.
void SetDMABurstRxSize(u8 SrcBsize):Set the burst size for OUT
endpoint (source burst size)
SrcBsize = Source burst size.
void DMASynchEnable(void): Enable the Synchronisation between the
DMAC and the USB IP.
void DMASynchDisable(void): Disable the Synchronisation between the
DMAC and the USB IP.

STR7/STR9 USB firmware library UM0290
14/76
1.2.3 usb_int (.c , .h)
The usb_int module handles the correct transfer interrupt service routines; it offers the link
between the USB protocol events and the library core.
The STR7 USB IP provides two correct transfer routines:
●Low priority interrupt: managed by the function CTR_LP() and used for the control,
interrupt and bulk (in simple buffer mode).
●High priority interrupt: managed by the function CTR_HP() and used for faster transfer
mode like Isochronous and bulk (in double buffer mode).
1.2.4 usb_core (.c , .h)
The usb_core module is the kernel of the library. It implements all the functions described in
chapter 9 of the USB 2.0 specification.
The available subroutines cover handling of USB standard requests related to the control
endpoint (EP0), offering the necessary code to accomplish the sequence of enumeration
phase.
A state machine is implemented in order to process the different stages of the setup
transactions.
The USB core module implements also a dynamic interface between the standard request
and the user implementation using the structure User_Standard_Requests.
The USB core dispatches the class specific requests and some bus events to user program
whenever it is necessary. User handling procedures are given in the Device_Property
structure.
The different data and functions structures used by the kernel are described in the following
paragraphs.
1. Device table structure: The core keeps device level information in the structure
Device_Table. Device_Table with the type: DEVICE.
typedef struct _DEVICE {
u8 Total_Endpoint;
u8 Total_Configuration;
} DEVICE;
2. Device information structure: The USB core keeps the setup packet from the host for
the implemented USB device in the Device_Info structure. This structure has the type:
DEVICE_INFO.
typedef struct _DEVICE_INFO {
u8 USBbmRequestType;
u8 USBbRequest;
u16_u8 USBwValues;
u16_u8 USBwIndexs;
u16_u8 USBwLengths;
u8 ControlState;
u8 Current_Feature;

UM0290 STR7/STR9 USB firmware library
15/76
u8 Current_Configuration;
u8 Current_Interface;
u8 Current_AlternateSetting;
ENDPOINT_INFO Ctrl_Info;
} DEVICE_INFO;
A union u16_u8 is defined to easily access some fields in the DEVICE_INFO in either
u16 or u8 format.
typedef union {
u16 w;
struct BW {
u8 bb1;
u8 bb0;
} bw;
} u16_u8;

STR7/STR9 USB firmware library UM0290
16/76
Description of the structure fields:
–USBbmRequestType is the copy of bmRequestType of a setup packet
–USBbRequest is the copy of bRequest of a setup packet
–USBwValues is defined as type: WORD_BYTE and can be accessed through 3
macros:
#define USBwValue USBwValues.w
#define USBwValue0 USBwValues.bw.bb0
#define USBwValue1 USBwValues.bw.bb1
USBwValue is the copy of wValue of a setup packet
USBwValue0 is the low byte of wValue, and USBwValue1 is the high byte of
wValue.
–USBwIndexs is defined as USBwValues and can be accessed by 3 macros:
#define USBwIndex USBwIndexs.w
#define USBwIndex0 USBwIndexs.bw.bb0
#define USBwIndex1 USBwIndexs.bw.bb1
USBwIndex is the copy of wIndex of a setup packet
USBwIndex0 is the low byte of wIndex, and USBwIndex1 is the high byte of
wIndex.
–USBwLengths is defined as type: WORD_BYTE and can be accessed through 3
macros:
#define USBwLength USBwLengths.w
#define USBwLength0 USBwLengths.bw.bb0
#define USBwLength1 USBwLengths.bw.bb1
USBwLength is the copy of wLength of a setup packet
USBwLength0 and USBwLength1 are the low and high bytes of wLength
respectively.
–ControlState is the state of the core, the available values are defined in
CONTROL_STATE.
–Current_Feature is the device feature at any time. It is affected by the
SET_FEATURE and CLEAR_FEATURE requests and is retrieved by the
GET_STATUS request. User code does not use this field.
–Current_Configuration is the configuration the device is working on at any time.
It is set and retrieved by the SET_CONFIGURATION and GET_CONFIGURATION
requests respectively.
–Current_Interface is the selected interface.
–Current_Alternatesetting is the alternative setting which has been selected for
the current working configuration and interface. It is set and retrieved by the
SET_INTERFACE and GET_INTERFACE requests respectively.
–Ctrl_Info has type ENDPOINT_INFO.
Since this structure is used everywhere in the library, a global variable
pInformation is defined for easy access to the Device_Info table, it is a pointer to
the DEVICE_INFO structure.
Actually, pInformation = &Device_Info.

UM0290 STR7/STR9 USB firmware library
17/76
3. Device Property Structure: The USB core dispatches the control to the user program
whenever it is necessary. User handling procedures are given in an array of
Device_Property. The structure has the type: DEVICE_PROP:
typedef struct _DEVICE_PROP {
void (*Init)(void);
void (*Reset)(void);
void (*Process_Status_IN)(void);
void (*Process_Status_OUT)(void);
RESULT (*Class_Data_Setup)(u8 RequestNo);
RESULT (*Class_NoData_Setup)(u8 RequestNo);
RESULT (*Class_Get_Interface_Setting)(u8 Interface,u8
AlternateSetting);
u8* (*GetDeviceDescriptor)(u16 Length);
u8* (*GetConfigDescriptor)(u16 Length);
u8* (*GetStringDescriptor)(u16 Length);
u8 MaxPacketSize;
} DEVICE_PROP;
4. User Standard Request Structure: The User Standard Request Structure is the
interface between the user code and the management of the standard request. The
structure has the type: USER_STANDARD_REQUESTS:
typedef struct _USER_STANDARD_REQUESTS {
void(*User_GetConfiguration)(void);
void(*User_SetConfiguration)(void);
void(*User_GetInterface)(void);
void(*User_SetInterface)(void);
void(*User_GetStatus)(void);
void(*User_ClearFeature)(void);
void(*User_SetEndPointFeature)(void);
void(*User_SetDeviceFeature)(void);
void(*User_SetDeviceAddress)(void);
} USER_STANDARD_REQUESTS;
If the user wants to implement specific code after receiving a standard USB request he
has to use the corresponding functions in this structure.
An application developer must implement tree structures having the DEVICE_PROP,
Device_Table and USER_STANDARD_REQUEST types in order to manage class
requests and application specific controls. The different fields of these structures are
described in the next section.
1.3 Application interface
The modules of the Application interface are provided as a template, they must be tailored
by the application developer for each application. Ta bl e 3 shows the different modules used
in the application interface.

STR7/STR9 USB firmware library UM0290
18/76
Table 3. Application interface modules
1.3.1 usb_istr(.c)
USB_istr module provides a function named USB_Istr() which handles all USB
macrocell interrupts.
For each USB interrupt source a callback routine named XXX_Callback (for example,
RESET_Callback) is provided in order to implement a user interrupt handler. To enable the
processing of each callback routines, a preprocessor switch named XXX_Callback must
be defined in the USB configuration file USB_conf.h.
1.3.2 usb_conf(.h)
The usb_conf.h is used to:
●Select the microcontroller: the user has to select the microcontroller. For the STR91x
the user has also to select the access mode to the USB IP (buffered or non-buffered) by
uncommenting the dedicated line:
//#define STR7xx
//#define STR71x
//#definr STR75x
//#define STR91x
//#define STR91x_USB_BUFFERED
//#define STR91x_USB_NON_BUFFERED
●Define the BTABLE and all endpoint addresses in the PMA.
●Define the interrupt mask according to the needed events.
1.3.3 usb_endp (.c)
USB_endp module is used for handling the CTR “correct transfer” routines for endpoints
different from endpoint 0 (EP0).
For enabling the processing of these call-back handlers a pre-processor switch named
EPx_IN_Callback (for IN transfer) or EPx_OUT_Callback (for OUT transfer) must be defined
in the USB_conf.h file.
1.3.4 usb_prop (.c , .h)
The USB_prop module is used for implementing the Device_Property, Device_Table and
USER_STANDARD_REQUEST structures used by the USB core.
File Description
usb_istr (.c,.h) USB interrupt handler functions
usb_conf.h USB configuration file
usb_prop (.c, .h) USB application specific properties
usb_endp.c CTR interrupt handlers routines for non control endpoints
usb_pwr (.h, .c) USB power management module
usb_desc (.c, .h) USB descriptors

UM0290 STR7/STR9 USB firmware library
19/76
1. Device property implementation
The device property structure fields are described below:
–void Init(void): Init procedure of the USB IP. It is called once at the start of the
application to manage the initialization process.
–void Reset(void): Reset procedure of the USB IP. It is called when the macrocell
receives a RESET signal from the bus. The user program should set up the
endpoints in this procedure, in order to set the default control endpoint and enable
them to receive.
–void Process_Status_IN(void): Callback procedure, it is called when a status in a
stage is finished. The user program can take control with this callback to perform
class and application related processes.
–void Process_Status_OUT(void): Callback procedure, it is called when a status
out stage is finished. As with Process_Status_IN, the user program can perform
actions after a status out stage.
–RESULT(a) *(Class_Data_Setup)(BYTE RequestNo): Callback procedure, it is
called when a class request is recognized and this request needs a data stage.
The core can not process such requests. In this case, the user program gets the
chance to use custom procedures to analyze the request, and prepare the data
and pass the data to the USB core to exchange with the host. The parameter
RequestNo indicates the request number. The return parameter of this function
has the type: RESULT. It indicates to the core the result of the request processing.
–RESULT (*Class_NoData_Setup)(BYTE RequestNo) Callback procedure, it is
called when a non-standard device request is recognized which does not need a
data stage. The core can not process such requests. The user program can have
the chance to use custom procedures to analyze the request and take action. The
return parameter of this function has type: RESULT. It indicates to the core the
result of the request processing.
–RESULT (*Class_GET_Interface_Setting)(u8 Interface, u8 AlternateSetting):
This routine is used to test the received set interface standard request. The user
must verify the "Interface" and "AlternateSetting" depending on the specific
implementation and return the USB_UNSUPPORT(a) and in case of error in this two
fields.
–BYTE* GetDeviceDescriptor(WORD Length): The core gets the device
descriptor.
–BYTE* GetConfigDescriptor(WORD Length): The core gets the configuration
descriptor.
–BYTE* GetStringDescriptor(WORD Length): The core gets the string descriptor.
–WORD MaxPacketSize: The maximum packet size of the device default control
endpoint.
a. * The RESULT type is the following:
typedef enum _RESULT {
USB_SUCCESS = 0,/* request process sucessfully */
USB_ERROR, /* error
USB_UNSUPPORT, /* request not supported
USB_NOT_READY/* The request process has not been finished,*/
/* endpoint will be NAK to further requests*/
} RESULT;

STR7/STR9 USB firmware library UM0290
20/76
2. Device table implementation
Description of the structure fields:
–Total_Endpoint is the number of endpoints the USB application uses.
–Total_Configuration is the number of configurations the USB application has.
3. USER_STANDARD_REQUEST implementation
This structure is used to manage the user implementation after receiving all standard
requests (except Get descriptors). The fields of this structure are:
–void (*User_GetConfiguration)(void): Called after receiving the Get
Configuration Standard request.
–void (*User_SetConfiguration)(void): Called after receiving the Set
Configuration Standard request.
–void (*User_GetInterface)(void): Called after receiving the Get interface
Standard request.
–void (*User_SetInterface)(void): Called after receiving the Set interface
Standard request.
–void (*User_GetStatus)(void): Called after receiving the Get interface Standard
request.
–void (*User_ClearFeature)(void): Called after receiving the Clear Feature
Standard request.
–void (*User_SetEndPointFeature)(void): Called after receiving the set Feature
Standard request (only for endpoint recipient).
–void (*User_SetDeviceFeature)(void): Called after receiving the set Feature
Standard request (only for Device recipient).
–void (*User_SetDeviceAddress)(void): Called after receiving the set Address
Standard request.
1.3.5 usb_pwr (.c , .h)
This module manages the power management of the USB device it provides the following
functions:
Table 4. Power management functions
Function Name Description
RESULT Power_on(void) Handles switch on conditions
RESULT Power_off(void) Handles switch off conditions
void Suspend(void) Sets suspend mode operation conditions
void Resume(RESUME_STATE
eResumeSetVal) Handles wake-up operations