STM32F303xB: How to reset USB Endpoint on USB disconnect ?

[Prasant J]

Posted on August 18, 2017 at 08:34

Hi,

I'm using custom hardware that has STM32F303VB (firmware version F3 v1.8.0) and uses USB in self-powered mode.

I have modified USB Custom HID class to appear as USB Vendor Class (1 IN + 1 OUT endpoint). USB Vendor class is working fine except one generic case. The USB communication does not work after the USB cable is disconnected and reconnected.

I'm assuming the problem is that the endpoints are not reset when the cable is disconnected. I did not see such a function in the USB HAL.

Has anyone implemented endpoint reset functions?

Did anybody face a similar problem?

Any inputs will be of help!

Regards, Pj

#stm32f303 #usb #endpoints

[Ben K]

Posted on August 18, 2017 at 19:06

I would recommend checking the following steps during USB reconnection:

1. Reset signal is sent from the host, check that your code closes all non-control endpoints (EP > 0) from USBD class DeInit callback
2. Device setup by the host (setting bus address, reading descriptors), check that the device is recognized at all by the PC
3. The host selects the USB configuration (typically only one configuration is available), check that your non-control endpoints are opened from USBD class Init callback
4. Class-specific USB configuration by the host
5. Communication through the non-control endpoints

If we know which step fails it is much easier to tell what exactly went wrong.

[Prasant J]

Posted on August 21, 2017 at 15:20

Hi

Kupper.Benedek

‌,

Thanks a lot for inputs!

I traced the steps mentioned by you.

1 to 3 work.

Step 4: Since its vendor class there is no class specific initialization.

Step 5:fails.

Any further checks that you think I should do?

Regards, Pj

[Ben K]

Posted on August 21, 2017 at 21:01

In this case I wouldn't blame the device, but would rather investigate the device driver on the host (PC) side. Does it have a custom driver, or uses a built-in mouse/keyboard driver? I haven't worked with HID myself yet, but it is possible that the driver is not detecting the detachment of the device, and thus keeps communicating on the broken channel instead of re-initializing it.

This is as much as I can add to this topic, I hope you manage to solve the issue (keep us updated).