Windows USB CDC Serial Issue

Go To Last Post
12 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am seeing the following behaviour upon enumeration of my ATSAMD21 (not important) as USB CDC device.

Get device descriptor.

Assign Address.

Get device descriptor.

Get Strings.

Get Configuration Descriptor

Set Configuration Descriptor

Get line coding (baud rate)

Set line coding (baud rate)

 

Then again repeatedly with about 1 second interval..

Get Configuration Descriptor

Get Configuration Descriptor

Get Configuration Descriptor

Get Configuration Descriptor

Get Configuration Descriptor

Get Configuration Descriptor... and on and on.

 

At some stage it gives up asking for it again and again.

I am just wondering what could be causing this?

 

While this is going on I can still transmit and receive through the BULK pipes ... as I can type on serial terminal program.

 

Another question I have is...when serial term program is on and connected if I happen to restart my microcontroller...there I hear the windows ding dong meaning its enumerating again which it successfully does. But then when I disconnect and reconnect the serial term program...it says port already open and it wont reconnect! Annoying...and I actually have to physically unplug and replug the cable for this to work again. Any advise on why this happens?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've never seen Windows repeatedly ask for the configuration descriptor.

 

You must kill the PC program, or disconnect it from the virtual serial port, before restarting the microcontroller.   If you forget to do that, you need to kill it or disconnect it, and restart the microcontroller again.   You shouldn't need to unplug the USB cable.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well here is what I see on my terminal as I print out the setup packets as they come to micro:

 

RXn: 80 06 00 01 00 00 40 00 
RXn: 00 05 02 00 00 00 00 00 
RXn: 80 06 00 01 00 00 12 00 
RXn: 80 06 00 02 00 00 FF 00 
RXn: 80 06 00 03 00 00 FF 00 
RXn: 80 06 02 03 09 04 FF 00 
RXn: 80 06 00 01 00 00 12 00 
RXn: 80 06 00 02 00 00 09 01 
RXn: 00 09 01 00 00 00 00 00 
RXn: A1 21 00 00 00 00 07 00 
RXn: 21 22 00 00 00 00 00 00 
RXn: 80 06 00 02 00 00 09 00 
RXn: 80 06 00 02 00 00 09 00 
RXn: 80 06 00 02 00 00 09 00 
RXn: 80 06 00 02 00 00 09 00 
RXn: 80 06 00 02 00 00 09 00 
RXn: 80 06 00 02 00 00 09 00 
RXn: 80 06 00 02 00 00 09 00 
RXn: 80 06 00 02 00 00 09 00 
RXn: 80 06 00 02 00 00 09 00 
RXn: 80 06 00 02 00 00 09 00 
RXn: 80 06 00 02 00 00 09 00 
RXn: 80 06 00 02 00 00 09 00 
RXn: 80 06 00 02 00 00 09 00 
RXn: 80 06 00 02 00 00 09 00 
RXn: 80 06 00 02 00 00 09 00

You can see after the setting of line speed

RXn: 21 22 00 00 00 00 00 00

It is continuously sending the config reqeusts... these requests are slow and tends to be around 1 a second.

 

Also I have no issue if I disconnect the terminal program first then reset micro. But when I leave the software connected and reset micro, the only way I can get the terminal program to connect again is by unplugging the usb lead. Reseting the micro does not work on this case.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I just installed a program on my Xmega that uses CDC.  I do get a pot full of setup packets.  I think it's about twice what I get with winusb which is the USB protocol I normally use.  I get 21 of them.  You get 26.  I don't remember getting that many back when I used CDC.   

 

I'm currently using Win7.  What  Windows are you using?

 

I don't need to unplug my Xmega to recover from the "Xmega reset while my PC program is connected to the virtual serial port" catastrophe.  All I need to do is hit the reset button on my board.  The difference might be the difference in the Windows version or the difference in the microcontroller chips.  I'll boot up Windows 10 soon and try it out. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm now on Windows 10 1703.  Now I get 25 setup packets.  So that is O.S. dependent.  I seem to get them all in a second or so.

  

I can still recover from the reset disaster by simply hitting the reset button, after the PC program closes the virtual port of course.  This may depend on the device hardware and/or software. 

  

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It looks like I get the configuration request in the 4th, 10th and 11th setup packets.  After that I get different requests.

It looks like the first config request setup pkt contains a response bytecount of 0xff.  The second and third have 0x43 and 0x109 respectively.

I guess the responses are the big ones that include a lot of descriptors.  As I recall, the actual byte count of my responses are 67 bytes (0x43).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

The rest of the setup packets are a combination of SetLineStatus, SetLineCoding and GetLineCoding.  Over and over again.  None of which means anything unless it's really driving an RS232 line.

 

The best I can say about CDC is, it's half-assed.  Pardon my use of technical terms.  It seems to be the only easy way to allow PC programs to make the connection by just opening a serial port.  I normally use winusb in my PC programs but I had to write the interface. 

 

EDIT:  Maybe I should say Microsoft's version is half-assed.  Maybe someone with a clue could do better.

Last Edited: Sun. May 21, 2017 - 09:39 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You have captured some of my original frustration.

Here is what I understand so far...(I am using win7):

 

- At first there is device descriptor request

- address seting

- device descriptor request again but this time expecting 18byte size as return packet

- string descriptor requests (0, 1, 2)

- configuration descriptor with 0x0109 bytes (265).

- To which I respond with either 67 bytes (ONE CDC port) or 141 bytes (two CDC port). This goes through correctly.

- You can see the PC accepting the configuration and setting the configuration.

- Then comes the Line coding get and set stuff.

- You would expect this should be the end by now. But no windows keeps asking for the configuration requests as well as the string requests over and over again. It goes like this, give me config and strings, wait 1 second, give me config and strings, wait 1 second, and so on... for a few times... yes possibly somewhere around 20 or so. I have not counted exactly. What I posted above was not the end of it.

 

I had last night managed to get the TWO CDC working on my ATSAMD21 as well. Its working great. But have been able to sort out the strange behaviour above. It does not however affect the operation of the CDC ports.

 

Regarding the reset issue...I have found that you must click "DISCONNECT" in the terminal program and THEN reset the micro controller. Then after enumeration, you can "CONNECT" the terminal program again. This works fine...

 

I don't know anything about winusb....better go do some reading.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've never used 2 configurations.  Maybe that's confusing Windows.  It doesn't take much.smiley

 

I guess I should use the word WCID instead of winusb.  Here's what I know about it on the device side.

https://github.com/pbatard/libwd...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Nah the same behaviour exists if I just recompile with 1 port configuration.

 

So this WCID thing... how does it determine how many ports, what kind (CDC)? etc? A unique VID/PID still needed? If I wrote a WCID implementation on my ATSAMD21...will it also work on Linux?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I don't know a lot about it, but I do know a few things.

 

You don't need unique VID/PID.  In fact, I guess each device could be a perfect clone.  If you had multiple clones plugged in it might be difficult to tell which is which.  I guess you could tell by the USB hub and port.  I use the "serial number" to tell them apart.  The "serial number" is a misnomer because it doesn't have to be a number or serial.  I think it can be any ascii characters.   You could give each device it's name,  Peter, Paul, and Mary, etc.  by storing it on the chip.  I took the simpler way out.  The Xmega has some data that added together can make a unique number. Things like wafer number, batch number, location on the wafer, etc..  I grabbed a few bytes here and there and used it for the serial number.

 

WCID uses winusb or libusb.  You will probably want the latter.  The advantage of libusb is it can be ported to most operating systems, and winusb cannot.  There are 2 versions of libusb mentioned in the P. Batard document and I didn't want to spend the time figuring which one I wanted, or whether there was a newer one.  I took the easier way of using winusb.  I guess once you get one working, it would probably be fairly easy to switch.

 

WCID simply gives you a communications channel between the host and device.  You don't have to pretend to be keyboard or hard drive or mousetrap or a toaster.  I don't know if you can have multiple configurations because I wasn't interested.  

 

On my PC program, I ask Windows for a list of all WCID devices that are currently connected.  I display the list of "serial numbers" and the user can choose.

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Apparently Atmel uses winusb for "Data Gateway" whatever that is.  Apparently it's not WCID.