29.01.2015 Views

STM32F101xx, STM32F102xx, STM32F103xx, STM32F105xx and ...

STM32F101xx, STM32F102xx, STM32F103xx, STM32F105xx and ...

STM32F101xx, STM32F102xx, STM32F103xx, STM32F105xx and ...

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

RM0008<br />

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

corresponding bits in the HAINT <strong>and</strong> GINTSTS registers. The mask bits for each interrupt<br />

source of each channel are also available in the OTG_FS_HCINTMSK-x register.<br />

● The host core provides the following status checks <strong>and</strong> interrupt generation:<br />

– transfer completed interrupt, indicating that the data transfer is complete on both<br />

the application (AHB) <strong>and</strong> USB sides<br />

– channel has stopped due to transfer completed, USB transaction error or disable<br />

comm<strong>and</strong> from the application<br />

– associated transmit FIFO is half or completely empty (IN endpoints)<br />

– ACK response received<br />

– NAK response received<br />

– STALL response received<br />

– USB transaction error due to CRC failure, timeout, bit stuff error, false EOP<br />

– babble error<br />

– frame overrun<br />

– data toggle error<br />

26.6.4 Host scheduler<br />

The host core features a built-in hardware scheduler able to autonomously re-order <strong>and</strong><br />

drive over the USB the transaction requests posted by the application. At the beginning of<br />

each frame the host executes the periodic (isochronous <strong>and</strong> interrupt) traffic first, followed<br />

by the nonperiodic (control <strong>and</strong> bulk) traffic to accomplish the higher level of priority granted<br />

to the isochronous <strong>and</strong> interrupt transfer types by the USB specification.<br />

The host pipes the USB transactions through request queues (one for periodic <strong>and</strong> one for<br />

nonperiodic). Each request queue can hold up to 8 entries. Each entry represents a pending<br />

transaction request from the application. Each entry in the request queue holds the IN or<br />

OUT channel number along with other information to perform a transaction on the USB. The<br />

order in which the requests are written into the queue determines the sequence of the<br />

transactions on the USB. The host processes the periodic request queue first, followed by<br />

the nonperiodic request queue, at the beginning of each frame. The host issues an<br />

incomplete periodic transfer interrupt (IPXFR bit in OTG_FS_GINTSTS) if an isochronous or<br />

interrupt transaction scheduled for the current frame is still pending at the end of the current<br />

frame.<br />

The management of the periodic <strong>and</strong> nonperiodic request queues is completely in the h<strong>and</strong>s<br />

of the OTG FS Core. A read-only register is available for the application to read the status of<br />

each request queue:<br />

● Periodic transmit FIFO <strong>and</strong> queue status register (HPTXSTS) <strong>and</strong> non periodic transmit<br />

FIFO <strong>and</strong> queue status register (GNPTXSTS), containing the:<br />

– number of free entries currently available in the periodic (non periodic) request<br />

queue (8 max)<br />

– free space currently available in the periodic (nonperiodic) Tx-FIFO (outtransactions)<br />

– IN/OUT token, host channel number <strong>and</strong> other status information<br />

As request queues can hold a maximum of 8 entries each, the application can push to<br />

schedule host transactions in advance with respect to the moment they physically reach the<br />

USB for a maximum of 8 pending periodic transactions plus 8 pending nonperiodic<br />

transactions. For example, for a bulk in/out transfer, up to 64 (max bulk packet size) × 8 (max<br />

Doc ID 13902 Rev 9 707/995

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

Saved successfully!

Ooh no, something went wrong!