25 Control Packets for Every Bulk Packet

[remixed123]

I have performed a packet capture of a device I am working with and have noticed that for every data/bulk packet I send, there are 25 control packets. Mostly getting and setting the line coding.

Is this behaviour expected with USB communication or does there look to be an issue somewhere?

The application I am using to communicate with the device is a C# application that is using the .NET SerialPort Class (it is very simple and nothing complex in the code). The device is running the Microchip USB Stack.

My eventual goal is to get the device to work with my embedded USB host, and I am wondering if these excess packets (if they are excess) could behind the difficulties I am having. Possibly the embedded host stack I am using is not as fault tolerant as the Microsoft .Net Class Libraries.

You can view the trace from the following links:-

USBlyzer Trace - https://app.box.com/s/8sro2hwpry49ry8lnd71
USBlyzer Trace (HTML Format) - https://app.box.com/s/7waakwcgm2fwmb0jfpvo

Glenn.

[Jan Axelson]

I don't know why the host feels the need to constantly get and set the line coding on your device, but bulk transfers get most of the bandwidth by default so the control transfers aren't slowing the bulk transfers.

[Barry Twycross]

With our COMs device and a Windows host, there's a flurry of requests like that when the associated COM port is opened, then it settles down to just the data endpoints. Do the control requests happen with every packet?

If they do, is the program on the host constantly opening the port, reading it and closing it?

[remixed123]

Thanks Barry,

That is exactly what is happening. I was opening and closing the port for each packet I was sending.

The flurry of requests stops after the first packet is successfully sent.

Glenn.