USB CDC example for stellaris-ek-lm4f120xl not working under WinXP/Win7 about libopencm3-examples HOT 18 CLOSED

The specification requires bDataBits to be either 5, 6, 7, 8, or 16. If the host sends a packet with bDataBits of 0, then that is an invalid packed, and the device correctly rejects it by stalling the pipe.

See "Universal Serial Bus Communications Class Subclass Specification for PSTN Devices, Revision 1.2, February 9, 2007", page 25.

from libopencm3-examples.

I know that the behavior of Windows is not standard conform. But it is also frustrating if you try an example and it doesn't work. I was lucky that i have access to a USB analyser. So it was not a big deal to find the problem. Maybe a little hint in the readme is ok for you.

For me it is ok to stick to the specification and left the example as is.

from libopencm3-examples.

USB analyzer or Wireshark should work. I don't know how the Windows driver model works and how they changed it since I last looked at it, but sounds like an issue with the *.inf file.

Feel free to submit a pull to update the README.

from libopencm3-examples.

I think it is not a problem with the inf file. The CDC device gets enumerated and a serial port is available. As soon as i try to open the serial port Windows send a bad SET_LINE_CODING with only the baudrate valid. If the device rejects the request after some retries Windows fails with an error. If the request is acceted Windows will send more SET_LINE_CODING requests with correct values.

I dont like such workaround as the the windows driver do not conform to the standard. But i need it to work under Windows. I am open for better solutions.

from libopencm3-examples.

I see three options:

1. File a bug report with microsoft.
2. Ignore bad packet in your project, but don't STALL the endpoint.
3. Write a custom driver.

However, I would rather not merge non-compliant code in the examples dir.
The SetLineCoding request is optional for CDC ACM, so I have no idea why windows just quits when it STALLs.

from libopencm3-examples.

If you can upload USB capture files (PCAP format) to somewhere public, I'd be interested to have a look.

from libopencm3-examples.

Is Wireshark under Windows able to capture USB ?

from libopencm3-examples.

AFAIK, you need to capture it with winpcap, and Wireshark will be able to open the capture file postmortem. I don't know if there is a faster method to do this natively.

Does your USB analyzer software support exporting to pcap format? That might be easiest for you.

from libopencm3-examples.

Currently i am at home. I will try with USBpcap and Wireshark at home. Tomorrow i can hava a lokk at the USB analyzer.

from libopencm3-examples.

Last time I had to do this kind of stuff, I used a linux host with windows VM, and just used usbmon on the host with Wireshark.

from libopencm3-examples.

Now there is USBpcap for Windows. I have captured to files.

1. lm4f_example_error.pcap (http://www.everwait.de/usb/lm4f_example_error.pcap)
2. lm4f_example_always_ack.pcap (http://www.everwait.de/usb/lm4f_example_always_ack.pcap)

The first is the original example and the second returns always ok on SET_LINE_CODING .

from libopencm3-examples.

Tomorrow i will try to export the data from the USB analyzer. I think the output from the analyzer is much better.

from libopencm3-examples.

Crap. winpcap didn't capture the setup packets. Can't tell what usbser.sys tried to do with all those SetLineCodingRequets. I suspect it is probing the capabilities, but that is a very wrong way to do it.

from libopencm3-examples.

The export capabilities of the analyzer software are not very helpfull. I will attach a screenshot of the captured data. The capture shows two tries with different baudrate. The SET_LINE_CODING requests are expanded in the view.

Hope that helps.

from libopencm3-examples.

Yeah. Just what I thought. It tries 115200 baud, and when that fails, 9600 baud. It probes the supported capabilities one at a time. They must have figured that since 0 is a valid value for bCharFormat and bParityType, it should be valid for bDataBits, which is of course, a bad assumption.

I'm curious about the capture when the device doesn't stall.

from libopencm3-examples.

Not Windows is probing. I have probed with two different settings. When i try to open the port with 115200 Windows returns an error and i am unable to open the port.

from libopencm3-examples.

It sends a GetLineCoding request right after the failed SetLineCoding request. This is what we call the

i=5; i=5; i=5; //Make sure i is 5 or the code below will crash

syndrome. The STALL is meant to indicate that that the request has failed, so asking the device for the parameters is futile, since no parameters were set in the first place. GetLineCoding is also sent more than once, perhaps in the hope that the device has not yet had time to respond, but will do so soon in the future. This tells me that whoever wrote the usbser.sys driver did not understand USB and the CDC ACM protocol well enough.

The obvious solution is to set bDataBits to 8 if it is received as 0, but since this violates the official protocol, I would rather not have this in the example.
Documenting the stupid things that some OSes do, along with a small set of modifications that could be done to make the device work is the preferred option. It should eliminate the frustration of "it doesn't work" because we know "how to make it work".

from libopencm3-examples.

Document the stupid things is for me the best solution. It is better the example do not violate the standard.
Thank you for your patience and help.

from libopencm3-examples.