• AVR Freaks

Helpful ReplyCDC lost connection

Author
Ferdinans
New Member
  • Total Posts : 25
  • Reward points : 0
  • Joined: 2006/05/18 01:26:28
  • Location: 0
  • Status: offline
2011/01/24 11:50:26 (permalink)
0

CDC lost connection

Hello,
 
I'm using the USB framework with CDC for COM port emulation.
Everything works fine until I apply disturbance on one of the USB data lines (D+ or D-) for example short circuit D- to GND.
Then somehow I'm no longer able to either send data or receive data (one of them keeps working).
 
I monitored the lower layer USB connection and I saw that enumeration and setup is still working.
I suspect some endpoint configuration, or ..... to get corrupted.
 
Does someone have any idea?
 
Thank you.
 
#1
chinzei
Super Member
  • Total Posts : 2250
  • Reward points : 0
  • Joined: 2003/11/07 12:39:02
  • Location: Tokyo, Japan
  • Status: offline
Re:CDC lost connection 2011/01/24 14:14:56 (permalink) ☄ Helpful
0

Everything works fine until I apply disturbance on one of the USB data lines (D+ or D-) for example short circuit D- to GND. 
Then somehow I'm no longer able to either send data or receive data (one of them keeps working).

USB hardware has built-in ability of error detection and retry. Even if a transaction is disturbed by short noise on the bus, the hardware repeats the same transaction(s), up to twice more. However, burst noise on the bus may defeat all of these retries. In such case, PC class driver is notified of the error by the host host controller, and, usually, class driver should recover the error.

Unfortunately, Windows CDC driver (usbser.sys) does no error recovery for the bulk IN pipe. It just stops the pipe. Moreover, no error is reported to  the PC application.

In this topic, I explained it in details.
CDC - stalled bulk IN
http://www.microchip.com/forums/m538194.aspx


To recover from this trouble, plug off the USB cable manually
- Close the COM port on the PC application, first.
- Plug off the USB cable.
- After a couple of seconds, plug in the cable, again.
- Open the COM port on the PC application.

Instead of manual plug-off/in, you may apply soft-detach / attach on the device.

Tsuneo
#2
Ferdinans
New Member
  • Total Posts : 25
  • Reward points : 0
  • Joined: 2006/05/18 01:26:28
  • Location: 0
  • Status: offline
Re:CDC lost connection 2011/01/25 02:15:12 (permalink)
0
Thank you very much for your reply.
 
Since there's no error reported to the PC application is it possible on the device side to detect the stall of the bulk IN pipe?
For example is there a way to determine that the PC has stopped polling the bulk IN endpoint?
 
Regards
 
post edited by Ferdinans - 2011/01/25 02:40:54
#3
chinzei
Super Member
  • Total Posts : 2250
  • Reward points : 0
  • Joined: 2003/11/07 12:39:02
  • Location: Tokyo, Japan
  • Status: offline
Re:CDC lost connection 2011/01/25 08:29:10 (permalink)
0
To detect the disorder of the bulk IN endpoint by the firmware, there are a couple of options. Here is one of the ways.

TX timeout
- Just after the firmware passes data to CDC bulk IN EP by putrsUSBUSART(), putsUSBUSART() or putUSBUSART(), start a timer to count down timeout.
- USBUSARTIsTxTrfReady() is examined in ProcessIO(), to stop this timer on the TX completion.
- This timer is examined in ProcessIO(), too. When the timer expires, call detach() (below)
  Another value is loaded to the timer to make a period of disconnection (around 2-3 sec)
- When the timer expires, again, call attach() (below)

Usually, the data on the bulk IN EP is retrieved by the host at the current USB frame or next one.
5 ms is enough for the timeout.

 
void detach( void )
{
    U1CON = 0;                       // Disable USB engine & detach from bus
    U1IE  = 0;                       // Mask all USB interrupts             
    USBDeviceState = POWERED_STATE;  // Move to powered state, temporarily
}

void attach( void )
{
    USBDeviceState = DETACHED_STATE; // Move to the detached state
                                     // stack moves it to ATTACHED_STATE
                                     // and initialize the USB engine
}


Some USB engine on other MCUs (NXP LPC family, AT90USB, SAM3U, EZ-USB series, etc) has a bit for NAK sent (Unfortunately PIC USB engine doesn't have this bit). For these engines, check and drop this bit in SOF interrupt. It provides an easy way of integrity check of polling IN transactions. This function is desirable for the next generation of PIC USB engine wink



Host app side also has a couple of options.
For example,

a) COM Port polling
SerialPort.GetPortNames lists up all COM ports. Checking the list periodically, disconnection and re-connection of the target COM port is known. When the target COM port disappears from the list, close the COM port. When it appears again, open the COM port.

OR

b) DSR/DTR handshake
The firmware notifies coming detach to host app by DSR. Seeing DSR change, Host closes the COM port. CloseHandle() (WinAPI) drops DTR automatically. Seeing DTR change, the firmware actually detaches.

Serial_State notification (DCD/DSR/RI etc) support
http://www.microchip.com/forums/fb.ashx?m=480514

etc.

Tsuneo
post edited by chinzei - 2011/01/25 09:22:21
#4
Ferdinans
New Member
  • Total Posts : 25
  • Reward points : 0
  • Joined: 2006/05/18 01:26:28
  • Location: 0
  • Status: offline
Re:CDC lost connection 2011/01/26 05:35:56 (permalink)
0
At the device side is there a way to find out whether the bulk IN endpoint is being polled by the host even when there's no data to be sent to the host?
 
I found out that the result of 'USBUSARTIsTxTrfReady()' is not garantueed to be FALSE when the data IN pipe is broken.
The sent data then just disappears into nothing.
 
I'm concentrating on solutions at the device side because I can not do much about the host application.
 
Thank you
 
#5
DarioG
Allmächtig.
  • Total Posts : 54081
  • Reward points : 0
  • Joined: 2006/02/25 08:58:22
  • Location: Oesterreich
  • Status: offline
Re:CDC lost connection 2011/01/26 06:11:27 (permalink)
0
Thanks for the tip Tsuneo, might be useful.

GENOVA :D :D ! GODO
#6
chinzei
Super Member
  • Total Posts : 2250
  • Reward points : 0
  • Joined: 2003/11/07 12:39:02
  • Location: Tokyo, Japan
  • Status: offline
Re:CDC lost connection 2011/01/26 10:30:14 (permalink)
0
At the device side is there a way to find out whether the bulk IN endpoint is being polled by the host even when there's no data to be sent to the host?

Unfortunately, PIC USB engine (SIE) can't.
While no data is armed on the IN EP, the EP is NAKing to the polling IN transactions. PIC engine NAKs silently for firmware. Firmware doesn't know it, without any NAK-sent flag on the USB register.
If the engine could notify NAK-sent to firmware, it would tell the polling IN transactions are still coming.

Tsuneo
post edited by chinzei - 2011/01/26 10:37:32
#7
Ferdinans
New Member
  • Total Posts : 25
  • Reward points : 0
  • Joined: 2006/05/18 01:26:28
  • Location: 0
  • Status: offline
Re:CDC lost connection 2011/01/28 06:15:04 (permalink)
0
The workaround I now implemented is regularly sending a Zero Length Packet and checking the transaction complete flag (U1IR.TRNIF). If the flag is not set within a certain interval the USB connection will be reset (detach/attach).
 
#8
chinzei
Super Member
  • Total Posts : 2250
  • Reward points : 0
  • Joined: 2003/11/07 12:39:02
  • Location: Tokyo, Japan
  • Status: offline
Re:CDC lost connection 2011/01/28 23:24:28 (permalink)
0

ZLP is a fine implementation for PIC engine.
The extra ZLP also speeds up the process on usbser.sys, if your PC app reads the RX buffer using SerialPort.DataReceived event of .NET, or OnComm event of MSCOMM.

Tsuneo
#9
Ferdinans
New Member
  • Total Posts : 25
  • Reward points : 0
  • Joined: 2006/05/18 01:26:28
  • Location: 0
  • Status: offline
Re:CDC lost connection 2011/02/02 03:20:32 (permalink)
0
Is it possible for the virtual COM port on the PC after disturbance of the USB data lines to get in such a state that it's visible in Device Manager but can't be opened by an application?

If this can happen I think it's something that's impossible to detect at the device side.
#10
chinzei
Super Member
  • Total Posts : 2250
  • Reward points : 0
  • Joined: 2003/11/07 12:39:02
  • Location: Tokyo, Japan
  • Status: offline
Re:CDC lost connection 2011/02/08 00:50:30 (permalink)
0

Is it possible for the virtual COM port on the PC after disturbance of the USB data lines to get in such a state that it's visible in Device Manager but can't be opened by an application?

CDC has four pipes, bulk IN/OUT, interrupt IN and the default pipe. Bulk IN is often disturbed by noise, because polling IN transactions are frequently carried on USB line.
When just bulk IN pipe is disturbed,
- Device manager reports no error on this device instance
- PC application gets no error for all of serial API call, but no RX data is transferred.
Just RX drops. Any of other functions (TX, DSR/DTR, RTS, baudrate setting etc.) doesn't affect by this trouble.

If this can happen I think it's something that's impossible to detect at the device side.

The CDC driver (usbser.sys) stops polling the bulk IN endpoint, when this trouble occurs.
Your idea using ZLP is good to detect this trouble on the device side.

Tsuneo
#11
Ferdinans
New Member
  • Total Posts : 25
  • Reward points : 0
  • Joined: 2006/05/18 01:26:28
  • Location: 0
  • Status: offline
Re:CDC lost connection 2011/02/09 06:25:37 (permalink)
0
Indeed using ZLP works for a lot of disturbances.

However I discovered another failure mode in which the ZLP's are handled correctly while the virtual COM port becomes unusable.
This means that an application on the PC can't open the COM port despite being visible in device manager.
I also monitored the data traffic on the USB port during this failure mode using a software USB analyzer and saw that the ZLP's (bulk data) are transferred correctly.

Therefore this state is hard if not impossible to detect by the device.
#12
chinzei
Super Member
  • Total Posts : 2250
  • Reward points : 0
  • Joined: 2003/11/07 12:39:02
  • Location: Tokyo, Japan
  • Status: offline
Re:CDC lost connection 2011/02/09 15:25:33 (permalink)
0
This means that an application on the PC can't open the COM port despite being visible in device manager.

This problem occurs when the device re-appears immediately after soft-detach, before the PC application closes the old COM port handle. The device should give enough time (2-3 sec) to Windows system and PC application, so that PC app detects disconnection and it closes the handle.

Tsuneo
#13
Ferdinans
New Member
  • Total Posts : 25
  • Reward points : 0
  • Joined: 2006/05/18 01:26:28
  • Location: 0
  • Status: offline
Re:CDC lost connection 2011/02/22 05:49:41 (permalink)
0
When enumeration has finished there's only bulk/interrupt data exchange.
Is it likely for enumeration to re-occur at a later random moment?
 
If this is not the case it's possible for the device to reset when after succesful enumeration there's another enumeration request from the host.
 
Regards
 
#14
chinzei
Super Member
  • Total Posts : 2250
  • Reward points : 0
  • Joined: 2003/11/07 12:39:02
  • Location: Tokyo, Japan
  • Status: offline
Re:CDC lost connection 2011/02/23 15:48:41 (permalink)
0
Is it likely for enumeration to re-occur at a later random moment?


Another enumeration occurs, just when
a) device is plugged off, and plugged in again (or soft-detach/attach)
OR
b) Host application or device driver order bus reset to host controller or hub.

Tsuneo
#15
Jump to:
© 2019 APG vNext Commercial Version 4.5