USB reconnection issue after microcontroller reset

[Muhammad Moiz khan]

Posted on November 09, 2016 at 13:12

Hi,

I am working on USB in VCP mode, and sending some of my data to PC-terminal, while working I'd notice that on first USB established connection microcontroller sends my data to the PC correctly, however when microcontroller reset USB stops sending its data to terminal, I don't understand what the reason behind that since in the past I'd been using FTDI Serial-to-USB converter in the same scenario and it worked fine.

Any help in this regard would be highly appreciated.

Regards,Muhammad Moiz khan 

[Amel NASRI]

Posted on November 16, 2016 at 15:23

Hi moiz.khan,

What device/board are you using?Is there any error flag set?What are you using as firmware?Did you tried the already available examples?-Mayla-

[Muhammad Moiz khan]

Posted on November 23, 2016 at 12:13

Hi Mayla,

Thanks for the response, I am using STM32F070CB microcontroller, I don't know about error reset flag however I am following the example below:

~\STM32F0x2_USB-FS-Device_Lib V1.0.0\Projects\Virtual_COM_Port.

Can you tell me where to look in this example since my hyper terminal stop's receiving characters when I reset microcontroller. Regards,Muhammad Moiz khan

[shingadaddy]

Posted on November 24, 2016 at 17:20

If you close HT on the PC and relaunch HT without disconnecting the device, I suspect it reconnects?

I'm near certain that if you are using the STLink as a VCP connection and do the same thing, you'll see similar results. 

[mark239955_stm1]

Posted on November 25, 2016 at 06:14

Have a think about the differences between a separate USB-to-serial bridge device like the FTDI chips, and a USB stack that enumerates as a VCP running in the MCU.

If you reset the MCU when you're using a separate USB device, then that USB device is (probably, unless you've designed the circuit to do so) not reset so the USB stacks in the host (PC) and the USB device don't lose synchronization. If you reset the MCU when you're using it to host the USB device stack, then the USB host and device do lose synchronization.  The only way that I'm aware of to correct this and re-synchronize ST's Windows VCP host driver and STM32 VCP device driver is to first reset the host (e.g. by closing the COM port), then reset the device (by resetting the MCU).  You should now be able to re-open the COM port. More robust USB host and device drivers might be able to correct this, or they might not.  I'm certainly not convinced that FTDI's host driver is any more robust than ST's - try pulling power on an FTDI chip while the host has an open COM port to that VCP instance and see how it behaves.

[shingadaddy]

Posted on November 25, 2016 at 17:15

I cant confirm the FTDI does any better at the moment. Those projects are shelved for me for now. Butthe folks at FTDI are near wizards in USB land. They are familiar with the OTHER end of the cable too, which more looks like the KEYSTONE COPS at times.

Many terminal programs show this characteristic (3 that  know of) with the ST line (and yes OTHERS too) with embedded USB. FTDI, having wires and firmware connected to the 4 wires of the usual USB connection can tell, make some good guesses, about what might be going on on those wires and makes every attempt to reconnect for you even if the other end of the cable might be a little confused. My guess is that they MAY, upon CONNECTION or RESET, blast out a complimentary DISCONNECT message  or command or SIGNAL of some sort that puts the pc's marbles back in the bag.

Just guesses though

[DiBosco]

Posted on November 28, 2016 at 10:40

I suspect the difference with the FTDI chips is that they do not actually ever reset themselves. They can be a huge help, for example, with bootloaders as you can power the micro off and on, but the FTDI part always stays on and connected, it's just the RS232/485  side that disconnects and that is a million times simpler than USB disconnecting.

I have a similar set-up and I've tried disconnecting the STM32 from my Qt program before trying to reconnect after a reset of the STM32 (but not a power down); the only way I can get it to reconnect is by powering down the STM32 and rebooting the Qt program. Even allowing for how rubbish Windows is, this happens under properly designed OSes like Linux and OS X, so I suspect it's not anything to do with the host, but something at a lower level. I'm currently trying to work out how to disable the STM32's USB altogether when the host sends a signal to the device (in my case Linux to STM32 - in yours Windows to STM32) to say to the STM32 you reboot, I'm about to disconnect. I suppose that *might* help, but I'm still not, as yet, sure about whether it will be necessary to reboot the Qt program. I shall try it with a terminal program and see whether I can power off and on the STM32 and reconnect  afterwards. If I understand correctly, even in Windows, the CDC driver used on the STM32 is part of the basic USB stack, whereas the FTDI needs additional driver software to get it to work. My feeling based on ignorance is that this should make things simpler for a ttyACM device over a ttyUSB device (STM32/FTDI). However, I might be totally wrong about that and maybe FTDI do have something really funky in their drivers to help with all this.

[DiBosco]

Posted on November 28, 2016 at 13:44

OK, I made some progress with this:

Now, bear in mind I'm using older libraries and not this Cube HAL abomination, but I use this: /******************************************************************************* * Function Name  : PCD_DevDisconnect * Description    : Disconnect device * Input         : None * Output         : None * Return         : status *******************************************************************************/ void  PCD_DevDisconnect (void) {   USB_OTG_DCTL_TypeDef dctl;   dctl.d32 = 0;     dctl.d32 = USB_OTG_READ_REG32(&USB_OTG_FS_regs.DEV->DCTL);   /* Disconnect device for 20ms */   dctl.b.sftdiscon  = 1;   USB_OTG_WRITE_REG32(&USB_OTG_FS_regs.DEV->DCTL, dctl.d32);   mDELAY(25); } I called that just before I reboot from main app to bootloader and I can now have the Qt program auto rescan, connect to the STM32 and load the new program over USB. So, I guess this might be just the thing you want. It seems to be important to disconnect from both ends before you try to reconnect. So far I've not got it reconnecting to the main app after the bootloader has loaded said new application. Am looking in to that now.

[shingadaddy]

Posted on November 28, 2016 at 17:43

+1 on the first couple of lines here....

Yeah. You tell the PC you are bailing out before you bail out... That could get a dicey race going though.

Still as markt said before - ''- try pulling power on an FTDI chip while the host has an open COM port to that VCP instance and see how it behaves.''

[DiBosco]

Posted on November 28, 2016 at 19:33

I can confirm I have it working both ways. It's simply a case of closing the peripheral on the STM32 and shutting down the connection on the computer end. If you then scan the ports and look for the one you previously closed it'll open up just fine.