2

I use USB device - STMicroelectronics development board. Use firmware, that support usb hardware. Its works as USB serial port.

On host PC (win10 21H1) i use serial terminal ("Tera Term") for get data from my device. I use standart windows usbserial driver.

My device sending data. If data flow is small (1-2-5 kByte/s) - all work fine. But if i speed up (flow about 100 kByte/s or more) - i see data loss.

I communicated with STMicroelectronics support. We checked issue. We saw USB communication with USB analyzer. We think, than it's windows side problem.

Also, I use a custom port read utility. Data integrity problem persists.

In received data i saw lost 64 or 128... multiple of 64 bytes. 64bytes - endpoint size in my case. See linked data for more information.

I create USB_test project in CubeMx. And add simple code for sending data to PC. Loop data sending if previous CDC transmit complete. Adding delays is unacceptable: firstly, it is not 100% elimination of losses; secondly, it has a bad effect on the bandwidth of the channel.

//in main() function 

uint8_t is_transmit = 0;

HAL_Delay(5000);
uint8_t Buf[2048];
uint8_t k = 48;
// fill the array with printable characters
for(uint16_t i=0; i<sizeof(Buf)-2; i++){
    if(k > 100) {
        k = 48;
    }
    Buf[i] = k++;
}
// array - is a one string line
Buf[sizeof(Buf)-2] = '\r';
Buf[sizeof(Buf)-1] = '\n';
        
    
while (1)
{
    if(is_transmit == 0){
        is_transmit = 1;
        //HAL_Delay(1); // add delay on 1 ms reduces the likelihood of losses by an order of magnitude
        CDC_Transmit_FS(Buf, sizeof(Buf));
    }
}

In CDC_TransmitCplt_FS() i flash is_transmit.

static int8_t CDC_TransmitCplt_FS(uint8_t *Buf, uint32_t *Len, uint8_t epnum)
{
    ---
    extern uint8_t is_transmit;
    is_transmit = 0;
    ---

  return result;
}

Information from ST support communication and USB analyzer log file. https://drive.google.com/drive/folders/1CvTPfaFGmcFxD4V5zTvsVE6U26DNwG2v?usp=sharing

How i fix this issue? I need data flow from device to host 500 kB/s or more.

Best regards, Andrey.

MAndreyG
  • 21
  • 3
  • The windows serial port driver stack seems to contain a lot of code that controls the transmission speed. It probably makes sense for a serial port in its original incarnation, but gets in the way of modern USB based communication with higher speed. Try to increase the baud rate (even though is irrelevant in theory). Alternatively, discard CDC and go with a vendor specific USB device. – Codo Jun 02 '21 at 14:41
  • 1. Communication speed not affected. 2. Discard CDC in stm32 device and use CP210x or FTDI - no, i need synchronization other USB (by SOF packet). CP210x dont offer this. Thanks you for solutions. – MAndreyG Jun 02 '21 at 15:08
  • I don't suggest using a CP210x or FTDI chip. Instead I propose to use the STM32's USB port implementing one or two bulk endpoints with a device descriptor that does not declare the device as virtual serial device (USB CDC ACM). On the Windows side, you would then to need WinUSB instead of the serial port APIs. And what do you mean by "Communication speed not affected"? – Codo Jun 02 '21 at 15:24
  • Thanks, i will see what is WinUSB (now our soft use work with serial port). I meant ports baud rate setup. – MAndreyG Jun 02 '21 at 17:34
  • I see about winusb. Working with winusb will require some work from both the device and the host side. But the most frightening thing is debugging and testing, testing, testing .... And support during all device life cycle phase. I would very much like to stay within the functionality of the serial port. This is a big burden for our team. This is highly undesirable. But we will consider this possibility among the potential outcomes. – MAndreyG Jun 02 '21 at 18:03
  • ST Usb stack is a mess but generally it works. What mpu are you using? – Damiano Aug 09 '23 at 10:01

0 Answers0