2013-03-15 01:28 AM
Hello everybody,
I have a question about USB device in VCP mode. I would like to keep my VCP communication open after a microcontroller reset (STM32F207). Is it possible ? In example, I have a terminal software running on my PC and connected to the USB virtual communication port. After the reset of the microcontroller, the terminal software does not detect anymore the communication port (I keep the connection of the terminal open everytime). Can I modify the USB stack to handle this case, or is it impossible ? Thank you in advance for your support. Thomas2013-03-15 03:23 AM
I suspect if you totally replicated the state/context immediately prior to the reset it might work, but what are the odds of that being easy to achieve?
The normal path would be to re-enumerate, but software written to open serial ports, with an early 90's design philosophy, usually doesn't deal with asynchronous re-enumeration of the port via the OS. The OS can send such messages, but Microsoft hasn't been particularly consistent about it's hardware attachment, device management and PnP implementations over the decades. Most people just want to use CreateFile() to access the device, not add a 1000 lines of code to handle the dozens of issues removing and reinserting the same device would cause.2013-03-15 08:54 AM
''I would like to keep my VCP communication open after a microcontroller reset (STM32F207). Is it possible ?''
No, it's not. When the microcontroller resets, the USB connection is lost. As far as the Host is concerned, it's been unplugged - sothe hostremoves the device. When the MCU restarts,has to re-enumerate. I guess you could come up with some kind of ''veneer'' to sit on the PC between the OS COM port and the application - using something like com0com... If you really want the link to stay alive while the MCU restarts, using an external USB-to-UART adaptor is probably the best way; eg,2013-03-16 11:18 AM
Umm,
If the device wouldn't be CDC, it could. PC CDC driver keeps polling at the bulk IN endpoint. Windows CDC driver (usbser.sys) fails, when the bulk IN endpoint doesn't respond at all, while chip reset/initialize is going on. Once this failure occurs, usbser.sys doesn't recover, unless the COM port is closed AND the device (soft-)detach/attaches.> When the microcontroller resets, the USB connection is lost An external 1k5 pull-up at D+ line works this problem around. To make the device stack ''enumerated'' - Set up the endpoints on the USB engine. - Initialize a couple of stack variables Tsuneo2013-10-15 04:47 PM
I have a question about USB device in VCP mode.
I would like to keep my VCP communication open after a microcontroller reset (STM32F207). Is it possible ?
In example, I have a terminal software running on my PC and connected to the USB virtual communication port. After the reset of the microcontroller, the terminal software does not detect anymore the communication port (I keep the connection of the terminal open everytime). Can I modify the USB stack to handle this case, or is it impossible ? Hi I have a similar problem related to this. My STM32F207 board has a USB serial port connection to my Win 7 x64 PC. I have the port open and all is well. But then my micro reboots for some reason (perhaps the watchdog, perhaps an assert, perhaps because I want it to do a firmware update). If I don't close the serial port BEFORE the reboot then after the micro has restarted the serial port doesn't work any more. I'm not aiming for a seamless continuation of the open serial port connection - I realise that is impossible. But what I mean is that the PC won't let me close the serial port and open it again. The serial port appears in the device manager after the micro has rebooted. But my .NET app doesn't detect it and another terminal app can see it exists but gets an error trying to open it. I've also noticed that when the micro reboots the PC doesn't make the normal ''ding'' sound when a device is removed. Can I somehow ''force'' the USB device to be removed from the micro side? Any other ideas? My system is designed to be monitored by a PC remotely - if someone has to unplug/plug the USB cable every time the board reboots then it's not going to work... Peter