USB initialisation and deinitialisation

[brians]

Posted on March 13, 2017 at 17:13

I am using USB CDC both for bootloader and in the loaded application with the IAR toolset and the CubeMX Middleware/HALlibrary.  Turning off the USB & Timer interrupts before the jump it jumps cleanly and runs the application, except that the USB will not restart (USBD_Start). I am using the normal start USBD start sequence.  If I load the application and run it at the same address all is fine and USB initialises runs as expected.  Is there a prescribed way to turn off USB in the boot loader and re-start it in an application?

[MDS]

Posted on July 27, 2017 at 13:59

I have been writing USB device driver stacks for over 10 years. Assuming you have a Windows host, this sounds like the Windows bug that I found back at Windows XP and it still exists with Window 10.

If a USB device disconnects while the Windows application has the socket or COM port open, upon reconnection, the USB device will enumerate, but Windows cannot open the socket or COM port. Here is the procedure our installer app uses to revive the connection after it has gone away.

1. Windows must close the connection, e.g. exit the application.

2. Then, either Windows can cycle power on the USB port, or issue a USB Bus Reset, or the user can unplug and re-plug the USB device.

After the Windows app has closed the connection and the USB device has re-enumerated, communications is restored.

It would be nice if Windows would fix this issue. There appears to be a communications issue between the Windows USB driver and the upper COM/Socket layer. Windows USB driver sees the re-enumeration and Device Manager sees the USB device, but the upper layer is not informed of the re-enumeration so it can close the COM/socket layer. Windows USB sees the USB disconnect, but the upper layer does not see it, or just does not close the upper layer connection. When the USB reconnects, Windows has not closed the upper layer, so it cannot open another connection to the same COM/socket.

BTW: I ported my USB stack over the HAL low-level USB physical layer. My USB stack supports composite devices which allows simultaneous multiple COM ports or RNDIS with COM ports, and it is dynamically reconfigurable. Porting looked easier than trying to extend the HAL.

[Vangelis Fortounas]

Posted on July 27, 2017 at 13:22

Georgiev Hello!!

I downloaded your Hterm.

Same behaviour to me also, except one point . If disconnect and connect from the upper left button is OK.

I use W10 64 upgraded

goldstein.howard

‌ suggested

/external-link.jspa?url=https%3A%2F%2Fwww.chiark.greenend.org.uk%2F%7Esgtatham%2Fputty%2F

A year ago searched hard to find a Terminal to open and close the ports automaticaly.. and to be connected at all situations.

I found as i wrote you, the

https://ttssh2.osdn.jp/index.html.en

. In menu->setup->general , put your default port . and try to see if you have the same behaviour

[zdravko]

Posted on July 27, 2017 at 13:40

Vangelis,

I'll definately try that, thank you. But I think we should try to be more constructive and try to formulate some kind of explanation why exactly after switching from application to bootloader the HTerm is not able to find the COM port even after doing refresh several times. Though after plug-in-out it's able to find it. The problem is that HTerm is just an example, the real PC software used to communicate through the USB with the stm32f105 is a python GUI software developed by us (which also can't find the COM port). This means that we need to know what's going wrong in order to make the changes in GUI.  .

[zdravko]

Posted on July 31, 2017 at 13:19

Hi,

thank you Merle and Vangelis for your contribution. I've tried with PuTTY and after the device switches from application to bootloader comes an error ''Unable to open connection to COM2. Unable to open serial port''. In addition the teraterm is not finding COM2, though the device manager is. Interestingly this error is different from the case when the COM is occupied. The other thing is that the connection is closed i.e. the application which was talking with the stm32f105 prior the bootloader switch is closed. Even if I reopen and reclose the application the COM2 is still not visible from any other application. Only the device manager sees it. Unplug and re-plug is a solution, but it's not very convienient as there should be someone to do the manuel work. Therefore the question is how to make the windows cycle power the USB or issue USB bus reset, and can this be done from the stm32f105 side?

[zdravko]

Posted on July 31, 2017 at 13:33

For example by using somehow the VBUS, which I'm not using right now.

[j2399]

Posted on August 01, 2017 at 13:21

A manual RESET cures the problem, right?

So you could do the RESET in software at the end of the bootloader.This works for me.

In order not to get into an endless loop, at the beginning of the bootloader there is a switch, which evaluates a flag and goes either right into the application or the main bootloader. There are several predefined flags, but you could also use your own.

See

https://github.com/rogerclarkmelbourne/STM32duino-bootloader

 (for F103)

https://github.com/trueserve/stm32f103-bootloader

 (for F103)

https://github.com/j1rie/F105-bootloader/blob/master/usbdfu.c#L296

(uses libopencm3)

@Vangelis Fortounas: Would you show a little bit of code (especially the 'Unconfigure USB, uninitialize HW' part)?

[MDS]

Posted on August 01, 2017 at 13:31

The key to recovering the USB interface is to first close the host controller connection on the host computer. Then force the USB device to re-enumerate, by cycling power, a host issued USB bus reset, or the device toggling the D+ pull-up. If you toggle the pull-up, be sure to allow sufficient time for the host controller to see the disconnect. Windows is suppose to have some filter to prevent glitches from causing a disconnect.

[zdravko]

Posted on August 03, 2017 at 11:38

Skelton.Merle

‌ I just figured out that I'm not exactly sure how the OTG is controlling the pull-up resistor, and if it's configured at all. I'm just using the function USB_OTG_BSP_Init from the usb_bsp.c file and USBD_Init from the usbd_core.c all from the usb_otg library. The A11 and A12 which I'm using are configured to be GPIO_Mode_AF_PP and then remaped. After then USBD_Init I'm just saying

DCD_DevDisconnect(&USB_OTG_dev);

delay(100); DCD_DevConnect(&USB_OTG_dev);

which is not helping. How to check and make sure that the pull-up resistor is on or off?

[zdravko]

Posted on August 03, 2017 at 11:57

Riedmiller.Rupert

‌ this reset function made no difference. I'm using it at the end of the application prior switching to bootloader, which is equivalent and there is no difference whatsoever. After I'm in the bootloader and if I press reset on the Keil uVision then it's working. I can't use cycle reset with the flags story, because I'm doing other important things at that time like flash read/write operations. So this will be very expensive to implement, I'll need state machines synchro mechanisms and so long and so long and so long.

[MDS]

Posted on August 03, 2017 at 13:26

The 100 ms delay may be too short. Windows enumeration does longer delays, although I have never seen any documentation for how long is long enough. I would try at least 1000 ms until you get it to work, although 500 ms should be sufficient. Windows is expecting human response times, so how fast can a person unplug and plug a USB cable? A USB analyzer would certainly be helpful to check the line states and see if the pull-up is active. A digital scope can also be used to look at D+ and D-.