32F4 USB CDC - any way to tell if Host has retrieved the data sent to it?

[peter-h]

The Cube IDE transmit (target -> PC) code flow is

CDC_Transmit_FS
USBD_CDC_TransmitPacket
USBD_LL_Transmit
HAL_PCD_EP_Transmit
USB_WritePacket

and the last one does 16 32 bit word transfers to the USB FIFO

Code: [Select]

HAL_StatusTypeDef USB_WritePacket(USB_OTG_GlobalTypeDef *USBx, uint8_t *src, uint8_t ch_ep_num, uint16_t len, uint8_t dma)
{
  uint32_t USBx_BASE = (uint32_t)USBx;
  uint32_t *pSrc = (uint32_t *)src;
  uint32_t count32b, i;
 
  if (dma == 0U)
  {
    count32b = ((uint32_t)len + 3U) / 4U;
    for (i = 0U; i < count32b; i++)
    {
      USBx_DFIFO((uint32_t)ch_ep_num) = *((__packed uint32_t *)pSrc);
      pSrc++;
    }
  }
 
  return HAL_OK;
}
My Q is whether there is any way to tell when that data has been consumed by Windows.

I have been doing tests and found

- there is a ~10kHz rate limit on calling CDC_Transmit_FS
- the max CDC_Transmit_FS packet size is 800 bytes

I am sure these are both system dependent, so I am rate limiting to 1kHz and size limiting (splitting up longer packets) to 256 bytes. The data rate is pretty impressive; you can easily do 256kbytes/sec this way, and one could go much faster if something at the Windows end was acking the packets. And this is VCP, not MSC which is used for removable storage devices.

There are various return codes from various functions but none of these appear to relate to whether you can shove more data out.

Is USB really "open loop" like that? I know it is all polled by the PC, seemingly at ~10kHz.

[peter-h]

This has been solved.

I think flow control was unimplemented in the original Cube MX generated code. I did it with the method shown here

https://community.st.com/s/question/0D53W00001mfognSAA/32f4-usb-cdc-any-way-to-tell-if-host-has-retrieved-the-data-sent-to-it?t=1662361131149

Probably people don't implement it because USB is fast enough for issues to not get spotted. However, a 168MHz CPU will easily exceed a 10kHz packet rate.

Also the ST HAL functions tend to return all kinds of error codes, which are often useless because one can't do anything with them. In this case, the caller was supposed to retry the packet transmit if it got USBD_BUSY, but it wasn't implemented properly by the next layer up.