USB CDC - problems with high datarate

[dennisfrie]

I've been using the USB CDC class from lpcopen for a while, but just been running into a problem when sending too much data from the PC. Basically, the USB CDC is used in a firmware-update chain and all data is forwarded to a traditional RS232 serial output to another device.
The PC-tool (which I can't modify) sends some very large messages (around 10000-20000 bytes), before waiting for a response. Unfortunately, the USB transfer speed is significantly faster than the UART-output, which means all data must be stored in an internal buffer, which is just not practical.

Is it possible to set the USB-state to "busy" or do anything else to indicate, that the USB-device is not ready for more data? The FTDI FT232 seems to solve this problem with a minimal buffer-size, so I guess it's supported in the USB-protocol somehow? 

Any help would be much appreciated.

[andyjackson · Accepted solution]

The trick here is to stop reading packets from the USB interface. It will then NAK the data causing the host to stop sending. When can handle more data simply start reading again and the USB interface will pick up where it left off. You will have to work out the details of achieving this depending on your implementation.

[dennisfrie]

That sure seemed to do the trick.

My main problem seemed to be:

- When not reading the usb-buffer (vcom_bread) the USB-buffer will simply fill up and not receive the data.

- When disabling communication with NVIC_DisableIRQ(USB0_IRQn), the USB-buffer already had a lot more data than expected and the 512 byte receive-buffer was misleading me to believe, that data was actually still being received.

This solved the problem - thanks a lot

[dennisfrie]

Thanks for your quick reply. I previously tried to achieve this by:

- Not calling CheckUsb, that calls vcom_bread, that reads the USB-buffer.

- Disabling USB-interrupt by calling NVIC_DisableIRQ(USB0_IRQn) and enabling it again when ready.

However, I seemed to just loose bytes/packages. I will have to give it another try to see.