5
\$\begingroup\$

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

\$\endgroup\$
1
  • \$\begingroup\$ 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. \$\endgroup\$ Commented Mar 1, 2019 at 22:09

4 Answers 4

5
\$\begingroup\$

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.

\$\endgroup\$
3
\$\begingroup\$

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.

\$\endgroup\$
1
  • \$\begingroup\$ Yes, that's right. I already fix that issue by setup other driver \$\endgroup\$
    – Foxek
    Commented Sep 17, 2020 at 15:59
1
\$\begingroup\$

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.

\$\endgroup\$
4
  • 1
    \$\begingroup\$ 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? \$\endgroup\$
    – hadez
    Commented Sep 16, 2020 at 14:05
  • \$\begingroup\$ yes it is a windows driver problem. Install custom one and the problem will be solved)) \$\endgroup\$
    – Foxek
    Commented Sep 17, 2020 at 16:00
  • 1
    \$\begingroup\$ @Foxek Do you mind telling us which custom driver you used? \$\endgroup\$
    – luni64
    Commented Oct 8, 2021 at 8:11
  • \$\begingroup\$ 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? \$\endgroup\$
    – wovano
    Commented Aug 17, 2022 at 9:24
0
\$\begingroup\$

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.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.