MCBSTM32EXL Keil, MCBSTM32EXL Datasheet - Page 809

• Manufacturer Part Number: MCBSTM32EXL
• Description: BOARD EVALUATION FOR STM32F103ZE
• Manufacturer: Keil

Specifications of MCBSTM32EXL

• Lead Free Status / RoHS Status: Lead free / RoHS Compliant

RM0008
●
●
Isochronous IN transactions
The assumptions are:
–
–
–
The sequence of operations is as follows:
a)
b)
c)
d)
e)
f)
g)
h)
i)
Selecting the queue depth
Choose the periodic and non-periodic request queue depths carefully to match the
number of periodic/non-periodic endpoints accessed.
The non-periodic request queue depth affects the performance of non-periodic
transfers. The deeper the queue (along with sufficient FIFO size), the more often the
core is able to pipeline non-periodic transfers. If the queue size is small, the core is able
to put in new requests only when the queue space is freed up.
The core’s periodic request queue depth is critical to perform periodic transfers as
scheduled. Select the periodic queue depth, based on the number of periodic transfers
scheduled in a microframe. In Slave mode, however, the application must also take into
account the disable entry that must be put into the queue. So, if there are two non-high-
bandwidth periodic endpoints, the periodic request queue depth must be at least 4. If at
least one high-bandwidth endpoint is supported, the queue depth must be 8. If the
The application is attempting to receive one packet (up to 1 maximum packet size)
in every frame starting with the next odd frame (transfer size = 1 024 bytes).
The receive FIFO can hold at least one maximum-packet-size packet and two
status DWORDs per packet (1 031 bytes).
Periodic request queue depth = 4.
Initialize channel 2. The application must set the ODDFRM bit in
OTG_FS_HCCHAR2.
Set the CHENA bit in OTG_FS_HCCHAR2 to write an IN request to the periodic
request queue. For a high-bandwidth isochronous transfer, the application must
write the OTG_FS_HCCHAR2 register MCNT (maximum number of expected
packets in the next frame times) before switching to another channel.
The OTG_FS host writes an IN request to the periodic request queue for each
OTG_FS_HCCHAR2 register write with the CHENA bit set.
The OTG_FS host attempts to send an IN token in the next odd frame.
As soon as the IN packet is received and written to the receive FIFO, the OTG_FS
host generates an RXFLVL interrupt.
In response to the RXFLVL interrupt, read the received packet status to determine
the number of bytes received, then read the receive FIFO accordingly. The
application must mask the RXFLVL interrupt before reading the receive FIFO, and
unmask it after reading the entire packet.
The core generates an RXFLVL interrupt for the transfer completion status entry in
the receive FIFO. This time, the application must read and ignore the receive
packet status when the receive packet status is not an IN data packet (PKTSTS bit
in OTG_FS_GRXSTSR  0b0010).
The core generates an XFRC interrupt as soon as the receive packet status is
read.
In response to the XFRC interrupt, read the PKTCNT field in OTG_FS_HCTSIZ2.
If PKTCNT 0 in OTG_FS_HCTSIZ2, disable the channel before re-initializing the
channel for the next transfer, if any. If PKTCNT = 0 in OTG_FS_HCTSIZ2,
reinitialize the channel for the next transfer. This time, the application must reset
the ODDFRM bit in OTG_FS_HCCHAR2.
Doc ID 13902 Rev 9
USB on-the-go full-speed (OTG_FS)
809/995