USB FS IN Transfer

[dimax]

Posted on January 05, 2014 at 21:15

Hi,

I'm reaching Control Pipe IN Timeout indication in DIEPINT0.TOC :

Bit 3 TOC: Timeout condition

Applies only to Control IN endpoints. Indicates that the core has detected a timeout condition on the USB for the last IN token on this endpoint.

What exactly this timeout is? Does it mean that TxFIFO is empty while IN token received from Host? If yes how long this timeout is?

I'm tying to send more then 64 bytes IN data - let's say 100bytes. To do it I write 100 bytes to TxFIFO, and fill DIEPTSIZ.XFRSIZ = 100 DIEPTSIZ.PKTCNT = 2 But it turns out that core does not send two packets (64 and 36 bytes) but stops after first 64 bytes IN transfer. Why? How in this case

DIEPTSIZ XFRSIZ and PKTCNT

should be used? I looked at the USB sample code from ST and they are using only PKTCNT=1 and XFRSIZ<=64. They also fill TxFIFO with no more then 64 bytes. If this is the right way to make IN transfer what are all this nice control registers for? And why it is not clearly written in reference manual?  

[dimax]

Posted on January 05, 2014 at 21:18

I forgot to mention that I'm working with STM32F207.

[dimax]

Posted on January 13, 2014 at 06:44

Hi,

I'm still waiting for explanation about DIEPINT0.TOC

DIEPTSIZ.XFRSIZ

DIEPTSIZ.PKTCNT

[chen]

Posted on January 13, 2014 at 12:38

Hi

''Hi, I'm still waiting for explanation about DIEPINT0.TOC

DIEPTSIZ.XFRSIZ

DIEPTSIZ.PKTCNT'' Do not know. ''

I'm tying to send more then 64 bytes IN data - let's say 100bytes. To do it I write 100 bytes to TxFIFO

'' I have found that with USB CDC (serial device) device and PC Host VirtualComPort, the VCP would not reliably send more than 64bytes at a time. We had to insert a <CR> to force the VCP driver to send multiple packets. In the end we gave up trying to send more than 64btes/packet (we do not use <CR> in our protocol) we just made sure our host program sent in 64byte packets. That does not answer you question though.

[dimax]

Posted on January 14, 2014 at 19:07

More likely ST has a bug in implementation of this flow. From what I could get experimenting with it

DIEPTSIZ.PKTCNT

can not be nothing else but ''1''. It means no more that one packed can be stored in FIFO.

BUT!!!

I want te get clear explanation from ST representative here in forum regarding mentioned registers and USB device IN transfer functionality. If it is not working as described in reference manual (and it is not working) tell us how it does work?

[ivan23]

Posted on January 15, 2014 at 14:52

So, yours is a USB OTG driver problem, I'm curious, because eventually I will have to implement complex USB transfers and all in my project, but I don't know anything about this topic. The only help I can offer is go look for errata and silicon limitations, two of my problems were due to ST production bugs indicated in the ''Errata and Silicon limitations for ST32F-so-and-so'' documents. Most often there are software workarounds for that.