5

I got a strange error in the USB CDC on the STM32F2. I use HAL implementation of the driver. The size of the buffer transferred in USBD_CDC_SetTxBuffer () is 4096 bytes. On the PC side, I accept the data in the terminal.

The problem is as follows. I am trying to transfer large amounts of data on 4096 bytes. Large parcels and send them in a cycle of 4096 bytes.

In case I do not touch the PC successfully transfer data. Tested on 165 MB. However, if on PC I start using the browser, open pictures, listen to music and in every possible way load it, then I don’t receive the entire data packet. I get <165 MB. What is the reason for this problem. PC Operating System - Windows

if I send this large buffer (165 MB) by 256 bytes in cycle - all right

nanoeng
  • 171
  • 11
Foxek
  • 61
  • 4
  • There are situations where moving this to its own USB bus (or changing operating systems or PCs) might help, but as Marcus explains it seems like you have unreasonable expectations of what sounds like an unbuffered system. – Chris Stratton Mar 01 '19 at 22:09

4 Answers4

5

USB has no way for a (non-isochronous) device endpoint to send data proactively – your host needs to poll the device for new data.

It looks like your PC isn't keeping up with that task, and your ARM-side buffering can't compensate for that.

This probably means you should be adding more buffering on your ARM, and also might mean that either your PC is pretty slow, or that the Windows CDC driver sucks. Which wouldn't be a thing unheard – especially demo / dev kit drivers tend to be "intern-grade" software, in my sorry experience.

Also, I don't know what your terminal application is – never overestimate the quality of host-side software.

Marcus Müller
  • 88,280
  • 5
  • 131
  • 237
3

There does appear to be an issue with the Windows 10 serial driver (also see MSDN). The workaround that we use is sending at most 63 bytes (in one packet) per USB frame. This results in 1 packet per transfer and 1 transfer per frame. Usually microcontrollers have some sort of SOF interrupt or callback that can be utilized to implement this.

Robert_ps
  • 31
  • 2
1

This situation was caused by the windows 10 cdc driver. If you send data at high speed and the host is loaded with other tasks, it will still request data, but not all data will be processed. As a result, packets are lost. Installing another cdc driver solved the problem.

On windows 7 this problem is not observed.

Foxek
  • 61
  • 4
  • 1
    I have the same problem. Works fine on Windows7 and data is lost on Windows 10. What CDC driver did you use for windows 10? – hadez Sep 16 '20 at 14:05
  • yes it is a windows driver problem. Install custom one and the problem will be solved)) – Foxek Sep 17 '20 at 16:00
  • 1
    @Foxek Do you mind telling us which custom driver you used? – luni64 Oct 08 '21 at 08:11
  • I'm also very interested in other off-the-shelf (possibly commercial) CDC drivers to overcome this problem. Did you write your own driver, or did you find a third-party CDC driver? – wovano Aug 17 '22 at 09:24
0

You need to check if USB is busy before tx CDC. If you don't touch anything, PC is polling USB fast enough for bulk in data. If you are doing something, polling is slower. If you don't check busy flag before transmit data in device, the packet is lost.

Michael Tien
  • 1