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 />

● Generic non-isochronous OUT data transfers<br />

This section describes a regular non-isochronous OUT data transfer (control, bulk, or<br />

interrupt).<br />

Application requirements:<br />

1. Before setting up an OUT transfer, the application must allocate a buffer in the memory<br />

to accommodate all data to be received as part of the OUT transfer.<br />

2. For OUT transfers, the transfer size field in the endpoint’s transfer size register must be<br />

a multiple of the maximum packet size of the endpoint, adjusted to the DWORD<br />

boundary.<br />

– transfer size[EPNUM] = n × (MPSIZ[EPNUM] + 4 – (MPSIZ[EPNUM] mod 4))<br />

– packet count[EPNUM] = n<br />

– n > 0<br />

3. On any OUT endpoint interrupt, the application must read the endpoint’s transfer size<br />

register to calculate the size of the payload in the memory. The received payload size<br />

can be less than the programmed transfer size.<br />

– Payload size in memory = application programmed initial transfer size – core<br />

updated final transfer size<br />

– Number of USB packets in which this payload was received = application<br />

programmed initial packet count – core updated final packet count<br />

Internal data flow:<br />

1. The application must set the transfer size <strong>and</strong> packet count fields in the endpointspecific<br />

registers, clear the NAK bit, <strong>and</strong> enable the endpoint to receive the data.<br />

2. Once the NAK bit is cleared, the core starts receiving data <strong>and</strong> writes it to the receive<br />

FIFO, as long as there is space in the receive FIFO. For every data packet received on<br />

the USB, the data packet <strong>and</strong> its status are written to the receive FIFO. Every packet<br />

(maximum packet size or short packet) written to the receive FIFO decrements the<br />

packet count field for that endpoint by 1.<br />

– OUT data packets received with bad data CRC are flushed from the receive FIFO<br />

automatically.<br />

– After sending an ACK for the packet on the USB, the core discards nonisochronous<br />

OUT data packets that the host, which cannot detect the ACK, resends.<br />

The application does not detect multiple back-to-back data OUT packets<br />

on the same endpoint with the same data PID. In this case the packet count is not<br />

decremented.<br />

– If there is no space in the receive FIFO, isochronous or non-isochronous data<br />

packets are ignored <strong>and</strong> not written to the receive FIFO. Additionally, nonisochronous<br />

OUT tokens receive a NAK h<strong>and</strong>shake reply.<br />

– In all the above three cases, the packet count is not decremented because no data<br />

are written to the receive FIFO.<br />

3. When the packet count becomes 0 or when a short packet is received on the endpoint,<br />

the NAK bit for that endpoint is set. Once the NAK bit is set, the isochronous or nonisochronous<br />

data packets are ignored <strong>and</strong> not written to the receive FIFO, <strong>and</strong> nonisochronous<br />

OUT tokens receive a NAK h<strong>and</strong>shake reply.<br />

4. After the data are written to the receive FIFO, the application reads the data from the<br />

receive FIFO <strong>and</strong> writes it to external memory, one packet at a time per endpoint.<br />

Doc ID 13902 Rev 9 817/995

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

Saved successfully!

Ooh no, something went wrong!