USB CDC descriptor problem

I read your message, and I'll post the reply as soon as possible.

Regards, RubeÂ'n.

Hello Rubén R,
I'm doing simillar implementation with MAX3420. How did you manage to send the configuration descriptor of 67bytes. The EP0 (control End point) has 64 byte FIFO, it's look like sending anything above 64bytes is a problem. I can get the host PC to regonise the device by removing a functional descriptor (to make configuration descriptor is less than 64 byte). but that doesn't provide all the functions of the intented design.

please let me know how you overcome this issue.

Thaks for your time.
Kind regards,
Thanushan

This is exactly the same issue i am facing. You mention that you reply to SET_CONTROL_LINE_STATE setup command from the host using the interrupt endpoint (which is 3 IN in your case). What is the exact reply you post to host? Is it NETWORK_CONNECTION status?

Also after you send the reply, you mention that a ZLP has to be sent. Is it from device to the host? Is it on control endpoint (EP 0 IN)?

I am looking forward to the reply from you or Tsuneo. Thanks in advance.

Hi,

I also have some USB problems.
I use the windows driver usbser.sys to make a CDC device

But if I add the Union Functional Descriptor (UFD) then then communication flow stops after SetConfiguration(1).
If I remove the UFD then my communication works fine, but I don't think it is 100% USB compliant.
Can anyone give me a hint to why the UFD make my communication flow stops? My target code is not stalled, but no data seem to be transferred from the host.
My device/configuration/interface and endpoint descriptors are like already mentioned.

Thanks,
Peter

After checking the problem Thanushan Bala have, I realized that it is not the UFD that is the problem, but the same as Thanushan Bala.
Does anyone have a good explanation why the length of configuration descriptor should be less that 64 bytes?

Thanks,
Peter

Sorry for spamming the discussion, but I found a solution for my problem. I don't know why, but perhaps someone can give an explanation.
I found out that my EP0 max packet size was set to 32 bytes.
This split the configuration descriptor (CD) of 67 bytes into 3 IN transactions (32,32 and 3). These were transferred correctly and host responded with SetConfiguration, but the communication flow stopped!?!
After changing EP0 packet size to 64 the CD was split into 64 and 3 bytes, but now the communication flow continued as wanted.
Now why is it a problem using EP0 max packet size of 32 byte?

Thanks,
Peter

Send me the code now and I will confirm the results.

Sorry, but my project is not using the MAX3420 as used by the other authors.
It could be nice to hear from others if they change the EP0 max packet size to 32 to see if they experience the same problem.

/Peter

Hello Peter,

"I found out that my EP0 max packet size was set to 32 bytes... These were transferred correctly and host responded with SetConfiguration, but the communication flow stopped!?!
After changing EP0 packet size to 64 the CD was split into 64 and 3 bytes, but now the communication flow continued as wanted."

Which request stops the enumeration?
Find it out with a bus analyzer.
If you don't have a hardware analyzer, download this software sniffer and 'evaluate' it :-)

SourceUSB - 1 month trial
http://www.sourcequest.com/

As you see SetConfiguration, I don't think GetDescriptor( Config ) is not the problem. Maybe the problem lies on other request handling.

Tsuneo

Hi,

I am facing another problem with my CDC. After set_control_line_state status packet from host, the next interrupt I receive is an interrupt IN. This is followed by bulk IN interrupt. What am i supposed to sent as reply to these? can i just STALL them?

After I open the hyper terminal, there occurs 4 get_line_coding, 1 set_line_coding, 1 set_control_line_state, 1 set_line_coding and again 1 get_line_coding? Are all these expected or is it coming because of some firmware issues? After all this, no more transactions occur. No bulk IN or bulk OUT. When i press characters on the hyper terminal; on the software analyser I see a bulk out transaction started but then CANCELLED.

I am really goin crazy over this. Any help will is highly appreciated.

Hello Arun,

Sorry, I missed your previous post,

"You mention that you reply to SET_CONTROL_LINE_STATE setup command from the host using the interrupt endpoint (which is 3 IN in your case). What is the exact reply you post to host? Is it NETWORK_CONNECTION status?

Also after you send the reply, you mention that a ZLP has to be sent. Is it from device to the host? Is it on control endpoint (EP 0 IN)?"

SET_CONTROL_LINE_STATE request and the interrupt IN endpoint has no relation. Nor bulk IN endpoint. Handle these request and endpoint independently.

1) SET_CONTROL_LINE_STATE requuest
The handling of SET_CONTROL_LINE_STATE finishes like other requests.
a) The SETUP packet is parsed and the execution enters to SET_CONTROL_LINE_STATE handler.
b) In this handler, the handshake lines are changed following D0(DTR) and D1(RTS) of wValue.
c) At the STATUS stage of this request (control transfer), ZLP is sent back to host over the default endpoint, to show success.

SET_CONTROL_LINE_STATE is carried over no-data control transfer.
SetConfiguration, ClearFeature and SetFeature requests are also no-data control transfer. You'll write the SET_CONTROL_LINE_STATE handler similar to the handler of these requests. Just the job of the request, ie. above b) part, is different.

2) Interrupt IN endpoint
Over this endpoint, the firmware returns SerialState notification. This notification is sent to host just when DSR is changed on the device. Or other signaling, DCD and error flags (overrun, parity, frame), are changed.

6.5.4 SerialState (PSTN120.pdf p32)
www.usb.org/.../CDC1.2_WMC1.1.zip

The hardware interrupt of this endpoint is not a good place to handle this process. A typical implementation is,
In a timer (or SOF) interrupt, check the state of DSR, DCD and error flags. If there are any state change, make up SerialState data block and fill it to the interrupt IN endpoint.



"After I open the hyper terminal, there occurs 4 get_line_coding, 1 set_line_coding, 1 set_control_line_state, 1 set_line_coding and again 1 get_line_coding? Are all these expected or is it coming because of some firmware issues?"

It's the normal (?) sequence of Windows usbser.sys device driver. :-)

"After all this, no more transactions occur. No bulk IN or bulk OUT."

Actually, bulk IN-NAK transaction occurs repeatedly on the bus, but software sniffer can't see this traffic. Just hardware analyzer does.

"When i press characters on the hyper terminal; on the software analyser I see a bulk out transaction started but then CANCELLED."

Do you read out the bulk OUT endpoint in the interrupt handler of this endpoint?

Tsuneo

hi, Mr Tsuneo Chinzei
do you ever build an cdc device? have you tested it?
several days ago i build it, and now it's works. but my device is not full duplex. if i send data from VCOM to UART(microcontroller, UART TX) and as soon after it ,i send data from UART (microcontroller received data/ UART RX), so the communication is hang. but if only transmitted or received, my device is ok. can you give advice how i can make full duplex?? i ever try with interrupt (RX) and polling (TX), but it's to many data error .

thanks for your help

how i can avoid buffer overrun when using usb-cdc? i have tested usb-cdc from many site, but if i countinuous send data full duplex from microcontroller and loopback again to PC, sometimes my microcontroller hang after 3-4 minutes(i using 9600 baudrate, 8-N-1), for transmitting - loopback 32.768Kbytes takes time +-34 s. (3 minutes=180s, 180/34 ~ 6 x[32Kbytes]. i using interrupt for transmitting and receiving, 256 bytes buffer for RX, 128 bytes for TX. when i change this size (both RX and TX buffer) this problem still occur. i have debug and the problem is buffer overrun. I try to monitor usb transaction with USB protocol analyser "usblyzer" (http://www.usblyzer.com), i found report with ...buffer overrun. what i should do?? any suggestion how to add timeout for bulk in transaction??(receive UART-RX and send back to USB host). or maybe any other idea to solve this problem?

thank you

"how i can avoid buffer overrun when using usb-cdc?"

Send ZLP after 32.768Kbytes transfer to the bulk IN endpoint.

Windows CDC device driver, usbser.sys, doesn't finish bulk IN transfer until you send a short packet. Short packet means a packet whose payload is less than wMaxPacketSize (usually 64), including zero (Zero-Length Packet: ZLP). As 32.768Kbytes is just the multiple of 64, you have to send ZLP.



Another point is,
Using SetupComm(), increase the RX buffer size on the device driver to fit to the transfer size.

"SetupComm Function" on MSDN
msdn.microsoft.com/.../aa363439(VS.85).aspx



If you are working on VB6 MSCOMM using onComm_event, another usbser.sys problem arises. See this post

"CDC transmitt delay" on Microchip USB forum

"define start bit ?" on Microchip USB forum
forum.microchip.com/tm.aspx

Tsuneo

thanks Tsuneo Chinzei,
i was try add ZLP and increase the RX buffer size on the device driver to fit to the transfer size, but sometimes "buffer overrun" problem still occur. i was try using thesycon cdc driver, and this problem still happen, but transfer rate more faster (+-9%). i try to loopback using my software serial terminal (i develop for myself using .net). the loopback procedure is every byte sent from pc (COM port, ex COM1 --> Virtual COM port, ex COM2)will transmitted back to pc (Virtual COM port,COM2 --> COM port, COM1) i looback from software on PC, not in microcontroller. any suggestion? thank you