USB-CDC driver - reconnection after reset issue

[russian]

I have a problem with serial port reconnection after stm32f4discovery board reset (for instance, re-programming)

Here are steps to reproduce:
1) make ARMCM4-STM32F407-DISCOVERY-MEMS demo (I am using 2.6.3 now but the same issue was present in 2.6.1 and probably before)
2) program ch.hex, connect micro USB cable. My windows 7sp1 has driver version 1.3.1, that's the latest version
3) connect to the serial port with putty - shell is responding as expected
4) keep putty open, reset stm32f4discovery with the black button
5) windows make the 'device disconnected/device connect' sound as expected
6) press any key in putty, PuTTy fatal error: error writing to serial device reported, as expected
7) close putty

8) open putty. Actual result: Unable to open connection to COM.... Unable to open serial port. That's while the port is available in the Device Manager.
Expected result: I would expect putty to establish a new connection

the only way to get putty connected again is to reset stm32f4discovery one more time, which is pretty confusing

Is this a known issue? I realize that it could be something in the ST driver, I guess it would be little fun convincing them that they have an issue

Please tell me if I should create a bug in the SF tracker

[Giovanni]

Probably it is a Windows issue.

PUTTY keeps the COM port open while the board USB is disconnected and reconnected. Probably the host USB stack assigns to the board another COM number on reconnect.

Giovanni

[alexblack]

Hi.
I have the same problems.
It seems this is a problem of STM VCP drivers for Windows. If restart USB connection when Virtual COM port is active (open) by any program, then Virtual COM port freezes and do not respond.
For example if use FT232 chip in that situation then Virtual COM port takes the new port number and will work. That's why I think this is a problem of Windows drivers.

[russian]

I was really hoping the issue is not with the driver because I just do not see this fixed by ST even if the issue is there

I have asked the question on the ST forum.

[russian]

Wow, I've got an unexpected response on the ST forum:

This "driver" (INF file) assigns Windows in-box driver, usbser.sys, to the device....
It’s the notorious "feature" of the Windows in-box device driver(s) (*1).
When the device disconnects, PC application should close the COM port handle immediately, before the device re-connects. After the device connects, the app opens the COM port again. That is, the PC app has to monitor device disconnection / connection.

Unfortunately, the major terminal apps, like TeraTerm, PuTTY, br@y++, RealTerm, don’t take care of this "feature"

I will see if I would be able to adjust my PC application accordingly - but I am depending on a 3rd party java serial com port library - so with one extra layer I am not sure if I would have the right event at the right time.

Who wants to report the issue to Putty?

[Giovanni]

I think it is unlikely they will want to try to fix this, it is more related to the Windows USB stack and handling of com ports.

Giovanni

[alexblack]

Hi.
You can periodically write to COM port, and close it if write fail. In this case the MCU application must read bytes to clear the buffer or usb will stop.
Another method is to monitor Windows events but it is much difficult and STM VCP drivers do not generate properly events such as COM port disconnecting. I already spent some time for this...

[russian]

You've probably seen this on the ST thread forum, looks like there is a guy there who knows this stuff:

If you would write your own PC code,
Windows notifies your app on COM port disconnection/ re-connection over
WM_DEVICECHANGE message
- WParam: DBT_DEVICEARRIVAL or DBT_DEVICEREMOVECOMPLETE
- LParam: DEV_BROADCAST_PORT
- - dbch_DeviceType: DBT_DEVTYP_PORT
- - dbcp_name: "COMx" (x = 1,2,3..)
COM port broadcast WM_DEVICECHANGE without any registration (RegisterDeviceNotification() is not required)

When your app receives WM_DEVICECHANGE - DBT_DEVICEREMOVECOMPLETE on your current COM port, close the COM port handle, immediately.
When your app receives WM_DEVICECHANGE - DBT_DEVICEARRIVAL on the last COM port, open the COM port, and send the settings (baudrate, etc) again.

[alexblack]

Yes, that is what I tried, but the driver does not send messages containing the port number. So far I've put it off.