USB CDC VCP device flow control?

[Sebastian G.]

Posted on December 06, 2016 at 15:36

The function CDC_Receive_HS() is not meant to be exited until all data is copied from the USB stack.

Is there a way to not do this? I am not using an operating system, so not leaving the function means blocking every way to empty the buffers to copy into!? This makes transferring a firmware via VCP impossible, because there is no way to implement client/device side flow control.

<LINK NO LONGER ACTIVE>

 mentioned the same issue in his last post here: '

<LINK NO LONGER ACTIVE>

[Tesla DeLorean]

Posted on December 06, 2016 at 16:34

>>

This makes transferring a firmware via VCP impossible, because there is no way to implement client/device side flow control.

Use something like X-MODEM which inherently has flow control and integrity checking to do firmware updates. The writing/erasing of Flash can stall the processor to a point that real-time operation is impossible unless everything is running from RAM.

You'd need to virtualize the CTS/RTS or DTR/DSR pins to implement flow control.

[Sebastian G.]

Posted on December 06, 2016 at 16:46

Yes I have implemented Y-Modem in my old system. It is painfully slow compared to what is possible with US, is at least another 1k of code size and adds an extra layer to everything.

AKA: considering USB spec it should not be needed, but until now it is a solutionUSB CDC has enough flow control built in for the purpose (-> NAK until buffer empty). The limitation is the named function 

CDC_Receive_HS() that I don't know how not to leave without an RTOS..

[Tesla DeLorean]

Posted on December 06, 2016 at 17:58

Without an RTOS you'd need to copy the data to another buffer, leave, and handle the data in a worker task, for the old SPL examples this could be the main() while loop

Beyond a basic demo most of the ST code would need to be tailored to handle anything remotely complicated.

[Sebastian G.]

Posted on December 06, 2016 at 18:16

Clive One schrieb:

Without an RTOS you'd need to copy the data to another buffer, leave, and handle the data in a worker task, for the old SPL examples this could be the main() while loop

The way you describe is what I have done for half a year. But you describe exactly critical section! If the buffer is full (very easy with USB speed) all incoming data is lost. It should be possible to keep all data within die USB Core FIFO until my app is ready for more data!

Clive One schrieb:

Beyond a basic demo most of the ST code would need to be tailored to handle anything remotely complicated.

I get the same impression, but what I am trying to do is not uncommon at all! There are many applications, like my bootloader, that don't need the complexity and code size of an RTOS.

All I am searching for is a USB CDC implementation that I can leave alone until I can handle data or want to send. Just like any other real COM-Port (RS-232).

[shingadaddy]

Posted on December 06, 2016 at 23:28

Forgive me for jumping on here but isn't this flow control handled by the core automatically when the RX fifo has been filled.?  In the L4 manual it has :

Peripheral Rx FIFO

The OTG peripheral uses a single receive FIFO that receives the data directed to all OUT

endpoints. Received packets are stacked back-to-back until free space is available in the Rx

FIFO. The status of the received packet (which contains the OUT endpoint destination

number, the byte count, the data PID and the validity of the received data) is also stored by

the core on top of the data payload. When no more space is available, host transactions are

NACKed and an interrupt is received on the addressed endpoint. The size of the receive

FIFO is configured in the receive FIFO Size register (OTG_GRXFSIZ).

And :

43.15.9 OTG Receive FIFO size register (OTG_GRXFSIZ)

Address offset: 0x024

Reset value: 0x0000 0200

The application can program the RAM size that must be allocated to the Rx FIFO.

And that register has a 16 bit value available.

Is this the same level of control you seek or am I muddling up 2 different things here?.

And I imagine you need to have the PC side set to enable flow control. However THATS

handled on THAT side for VCP. I thought a NACK back to the PC would generate near the

same operation as CTS RTS.

[shingadaddy]

Posted on December 06, 2016 at 23:39

And I just check my project (Well the HAL demo project to be more proper) and nowhere in it is OTG_GRXFSIZ. That means it is DEFAULT to 0x200 or 512 bytes.

[shingadaddy]

Posted on December 07, 2016 at 00:21

RE-READ   -   512  '32 bit values'  =    2048 bytes......

Got to remember that next page straddle data

Bits 15:0

RXFD:

Rx FIFO depth

This value is in terms of 32-bit words.

Minimum value is 16

Programmed values must respect the available FIFO memory allocation and must not

exceed the power-on value.

Of course in the DATA sheet for the L4 OTG_FS:

Combined Rx and Tx FIFO size of 1.25 KB with dynamic FIFO sizing

All the 'IF's' , 'AND's', 'BUT's' and contradictions make it hard to grab on the first pass.

The OTG module itself seems to have a little over 1.2K of RAM for the fifo. Maybe...

[Walid FTITI_O]

Posted on December 07, 2016 at 16:42

Hi

Gessler.Sebastia

,

Check the response submitted today in the other

https://community.st.com/0D50X00009XkewpSAB

. It seems useful for tou

-Hannibal-

If aresponse is useful, you would mention that by clicking the correct button. Thank you for the contribution

[mario basanta]

Posted on April 26, 2017 at 09:09

I have a similar question about this , can I use flow control (xon xoff, dts rts , etc)? When I use the CDC usb virtual com.

this feature it's included with the CDC usb library or examples . 

Thanks in advance .