ST virtual com port issue in case of MCU reset

[arro239]

Posted on February 22, 2014 at 17:03

I have a problem with serial-over-USB port reconnection after stm32f4discovery board reset (for instance, re-programming) - with the native USB controller port, not the uart dongles.

I have originally reported this issue to ChibiOS since I can reproduce this with a ChibiOS standard demo application, but they believe the issue is within ST VCP driver. I wonder if anyone can maybe reproduce this issue without ChibiOS and, in case the issue is reproducible, how do we go from there? Here are the detailed steps to reproduce: 1) make ARMCM4-STM32F407-DISCOVERY-MEMS ChibiOS 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 Now the issue: 8) start putty again. 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. This is not a putty issue because originally I've experienced this with my own application which was talking to my MCU using COM port.

[arro239]

Posted on February 24, 2014 at 03:32

Can someone please try the same steps with their the VCP implementation they use? I would love to confirm if this issue is specific to ChibiOS or not. Just connect with putty, reset MCU and see if you can reconnect with putty after that.

[tsuneo]

Posted on February 24, 2014 at 06:33

> 2) .. My windows 7sp1 has driver version 1.3.1

Do you mean this Windows ''driver'' (actually, INF file) on the ST site? STM32 Virtual COM Port Driver (v1.3.1) http://www.st.com/web/en/catalog/tools/FM147/CL1794/SC961/SS1533/PF257938 This ''driver'' (INF file) assigns Windows in-box driver, usbser.sys, to the device. > 4) keep putty open, reset stm32f4discovery with the black button > 6) press any key in putty, PuTTy fatal error 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'' As a workaround on terminal applications, - close the terminal (or disconnect on the terminal) first. - reset the board. - open the terminal (or connect on the terminal) again. 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. (*1) Not just COM port, HID, WinUSB, etc. too. Tsuneo

[arro239]

Posted on February 24, 2014 at 06:40

Yes 'STSW-STM32102

STM32 Virtual COM Port Driver

' - they call it a driver but I see what you are saying, it's more like a configuration for the default windows driver? Wow, that's an unexpected twist! So you are saying the bug is in Putty?

[arro239]

Posted on February 24, 2014 at 06:41

PS: thank you for the in-depth response!

[arro239]

Posted on February 24, 2014 at 07:04

Wait a second.

But since I am closing putty, is not it the OS responsibility to close the port? Once I restart Putty I guess it should expect a nice sweet connection and it should expect the driver to be in proper state, should not it? So while maybe Putty is contributing to the issue but not acting properly, would not it be fair to say that the issue is in the standard windows driver which does not do the job of resetting the state once the application which used the resource is closed? What a mess :( With so many parties involved I guess there is little hope to have this resolved. Can you name a serial client which does NOT have this issue? If there would be a serial client which works better than Putty I guess there would be a case to be made.

[tsuneo]

Posted on February 24, 2014 at 07:50

If the PC app would still occupy the old COM port Handle, when the device connects again, Windows should silently fail to initialize the COM port (symbolic link). Therefore, PC app should release the COM port Handle before the device connects again. It is the expected ''feature'' of Windows application, as long as built-in device drivers concern.

I don’t say it’s a bug of terminal applications, but they aren’t just up to date. In those days of legacy built-in RS232 COM ports, COM ports never been ''detached''. And then, terminal apps didn’t need to take care of this ''feature''. But in USB-serial age, they should be aware of this feature. Tsuneo

[arro239]

Posted on February 25, 2014 at 05:27

I will try to report this issue to PuTTy. Still, if at least some application would handle this properly we would be golden :)

[chen]

Posted on February 25, 2014 at 10:12

''I will try to report this issue to PuTTy. Still, if at least some application would handle this properly we would be golden :)''

What part of tsuneo's post did you not understand? The Virtual COM port is an emulation of a Serial (RS232) port. Serial ports do not 'disconnect'. So terminal programs, such as PuTTY do NOT need to respond to a disconnect.

[arro239]

Posted on February 25, 2014 at 22:28

Sung, I am sure it is the language barrier but I find your response a little bit offensive.

While I see your point I cannot agree with it. Nowhere in http://en.wikipedia.org/wiki/Serial_port I see that it HAS to be always on, where are you taking this from? Times are changing and hardware is changing. Your average serial port these days is not a DE-9 connector, so what?