Posted on May 29, 2015 at 12:36Hi,
Having had a working USB VCP using the old non-cube drivers, I've spent the last week trying to get a reliable VCP with the new ones - and failing. In fact at one point just uncommenting some irrelevant and unused code made it work reliably, and commenting it made it fail when sending and receiving at the same time - which makes me think it's potentially something accessing out of bounds.
I'm using USB only in FS mode, which should simplify things.
I now have something that works, but that locks up when it is both sending and receiving (with TxState left at 1). The only solution seems to be to unplug USB and plug it back in. Does anyone know why it might get into this state?
I have some questions related to the API. Is there any specific documentation that would help me? Documentation in the code seems very sparse at the moment.
- Is USBD_LL_Transmit supposed to block until the packet is transmitted? I had assumed that you gave your data to USBD_LL_Transmit and then when more data could be sent, USBD_ClassTypeDef->DataIn got called and you could call it again with more data.... But in my case, USBD_LL_Transmit seems to block until the data has been sent, so nothing in the main loop gets executed.
- From the Datasheets, I get the impression that the USB peripheral has 1.25kB of RAM that is in FIFOs, but the example code allocated 512 bytes for the 'data' variable, as well as separate arrays for RX and TX. To what extent are these needed? For instance is it safe to call USBD_LL_Transmit and/or USBD_LL_PrepareReceive with a buffer allocated on the stack.
- Is there any way to do flow control when receiving while still exiting the USBD_ClassTypeDef->DataOut function? Can I just delay calling USBD_LL_PrepareReceive until I actually have room for another buffer of data?
