09.12.2012 Views

RM0090: Reference manual - STMicroelectronics

RM0090: Reference manual - STMicroelectronics

RM0090: Reference manual - STMicroelectronics

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

USB on-the-go full-speed (OTG_FS) <strong>RM0090</strong><br />

● Isochronous IN transactions<br />

The assumptions are:<br />

– The application is attempting to receive one packet (up to 1 maximum packet size)<br />

in every frame starting with the next odd frame (transfer size = 1 024 bytes).<br />

– The receive FIFO can hold at least one maximum-packet-size packet and two<br />

status Word per packet (1 031 bytes).<br />

– Periodic request queue depth = 4.<br />

The sequence of operations is as follows:<br />

a) Initialize channel 2. The application must set the ODDFRM bit in<br />

OTG_FS_HCCHAR2.<br />

b) Set the CHENA bit in OTG_FS_HCCHAR2 to write an IN request to the periodic<br />

request queue.<br />

c) The OTG_FS host writes an IN request to the periodic request queue for each<br />

OTG_FS_HCCHAR2 register write with the CHENA bit set.<br />

d) The OTG_FS host attempts to send an IN token in the next odd frame.<br />

e) As soon as the IN packet is received and written to the receive FIFO, the OTG_FS<br />

host generates an RXFLVL interrupt.<br />

f) In response to the RXFLVL interrupt, read the received packet status to determine<br />

the number of bytes received, then read the receive FIFO accordingly. The<br />

application must mask the RXFLVL interrupt before reading the receive FIFO, and<br />

unmask it after reading the entire packet.<br />

g) The core generates an RXFLVL interrupt for the transfer completion status entry in<br />

the receive FIFO. This time, the application must read and ignore the receive<br />

packet status when the receive packet status is not an IN data packet (PKTSTS bit<br />

in OTG_FS_GRXSTSR ≠ 0b0010).<br />

h) The core generates an XFRC interrupt as soon as the receive packet status is<br />

read.<br />

i) In response to the XFRC interrupt, read the PKTCNT field in OTG_FS_HCTSIZ2.<br />

If PKTCNT≠ 0 in OTG_FS_HCTSIZ2, disable the channel before re-initializing the<br />

channel for the next transfer, if any. If PKTCNT = 0 in OTG_FS_HCTSIZ2,<br />

reinitialize the channel for the next transfer. This time, the application must reset<br />

the ODDFRM bit in OTG_FS_HCCHAR2.<br />

● Selecting the queue depth<br />

Choose the periodic and non-periodic request queue depths carefully to match the<br />

number of periodic/non-periodic endpoints accessed.<br />

The non-periodic request queue depth affects the performance of non-periodic<br />

transfers. The deeper the queue (along with sufficient FIFO size), the more often the<br />

core is able to pipeline non-periodic transfers. If the queue size is small, the core is able<br />

to put in new requests only when the queue space is freed up.<br />

The core’s periodic request queue depth is critical to perform periodic transfers as<br />

scheduled. Select the periodic queue depth, based on the number of periodic transfers<br />

scheduled in a microframe. If the periodic request queue depth is smaller than the<br />

periodic transfers scheduled in a microframe, a frame overrun condition occurs.<br />

● Handling babble conditions<br />

OTG_FS controller handles two cases of babble: packet babble and port babble.<br />

Packet babble occurs if the device sends more data than the maximum packet size for<br />

1127/1416 Doc ID 018909 Rev 3

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!