STM32F4 USB HID - Problem Win8/10 - Device Selective Suspended

[Mig (Gast)]

Hi,

since Windows 8 and 10 I have Problems with my USB HID.

I'm using the STM USB HID Stack and the demo VB project from 
JANAXELSON.COM.

If I connect the STM32F407 via USB the connection works for ~1sec.
Afterwards the USB_HID_STATUS changes from USB_HID_CONNECTED to
USB_HID_DETACHED.

Workaround (not practically) is to change the variables in the registry 
from 1 to 0:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB
AllowIdleIrpInD3    = 0
DeviceSelectiveSuspended  = 0
EnhancedPowerManagementEnabled  = 0
SelectiveSuspendEnabled    = 0

In Windows (Printers and Devices) the device is correct registered, but 
in
a kind of suspend mode. If I start the software before I plugg the USB 
cable,
the Software recognizes this and connects to STM32F4. Afterwards the 
device
remains 'online' and do not go to the suspend mode.

I'm looking for a solution either on PC side, or on the STM32F4 USB 
stack:

PC Side (Preferred, I'm using Visual Studio Express 2015 - VB.Net)
Are there functions that checks the power state of the USB HID and 
somehow 'wake up'
the device before writing/reading via fileStreamdevicedata?
Or, to deactivate the USB Selective Suspend for this device (not all USB 
devices) to
avoid the device to suspend.

USB Stack
Can the desciptors be changed to avoid Windows 8/8.1/10 to set the 
device
into other mode than D0 (eg. D3 DeviceSelectiveSuspended).

[bluppdidupp (Gast)]

>Are there functions that checks the power state of the USB HID and
>somehow 'wake up'
>the device before writing/reading via fileStreamdevicedata?
I think IO-Requests initiated from the host should automatically ensure 
that the driver wakes the device up.
Maybe the device is not waking up properly? usb30cv/usb20cv could be 
used to test the device, or "Windows HCK"

"All USB devices must support the Suspended state (refer to Chapter 9). 
The device is placed into the Suspended state via control of the hub 
port to which the device is attached. Normal device operation ceases in 
the Suspend State; however, if the device is capable of wakeup signaling 
and the device is enabled for remote wakeup, it may generate resume 
signaling in response to external events.
The power management system may transition a device to the Suspended 
state or power-off the device in order to control and conserve power. 
The USB provides neither requirements nor commands for the device state 
to be saved and restored across these transitions." (USB 2.0 
Specification)

A common workaround to prevent getting suspended is to just send dummy 
data to the host every few ms so the driver will not think that the 
device is idle.

[Arc N. (arc)]

Mig schrieb:
> Workaround (not practically) is to change the variables in the registry
> from 1 to 0:
> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB
> AllowIdleIrpInD3    = 0
> DeviceSelectiveSuspended  = 0
> EnhancedPowerManagementEnabled  = 0
> SelectiveSuspendEnabled    = 0

There exists a mechanism to automatically set these registry values:
"Microsoft OS 2.0 Descriptors Specification" 1). The spec also includes 
some examples demonstrating how to set SelectiveSuspendEnabled (page 15)

1) 
https://msdn.microsoft.com/de-de/library/windows/hardware/dn385747.aspx

[Mig (Gast)]

Hi Guys,

many thanks for your help. Fortunately is was a stupid bug in my FW and 
luckily I do not need to play around with further descriptors.

Problem solved. It was a bug in the user section of the FW in my 
function where I used the disconnected flag instead of connected.

void USBD_USR_DeviceResumed(void)