Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

usb3 device power state goes to U2 & already submitted INT IN URB not able to wake up device to U0

Bhoomil_ChavdaBhoomil_Chavda Member - All Emails Posts: 7

Currently, I'm facing one weird issue with my custom Windows USB driver.
So I know in USB 3.0 the interrupt xfer mechanism is totally changed i.e from polling to async notification.
From the driver perspective, I have submitted my Interrupt URB immediately after driver registration when the device will probe on the USB port.
That means my driver will always in a listening mode for any Interrupt packets.

But unfortunately, my device goes into U2 state whenever there is no bus activity like other endpoints operations. and I'm not able to read Interrupt IN packets from the device. over here at device side IN transfer to host is successfully but after that, on USB analyzer there is not activity.

My Question is, If one of my endpoint already submitted URB then why device is not wakeup to U0?
I have also referring deferred packets concept to resolve this problem and found that in LinkControlWord there is Deferred bit... If i set it to 1 than it should works
How can I set that bit?

https://docs.microsoft.com/en-us/windows-hardware/drivers/usbcon/common-hardware-problems-with-u1-or-u2-implementation
USB 3.0 spec section c.1.2.2 Packet Deferring

Comments

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 12,966
    via Email
    Bhoomil_Chavda wrote:
    > That means my driver will always in a listening mode for any Interrupt packets.

    Well, that's only true if you resubmit the read URB immediately after
    processing a completed one.  Is that how you do it?  The old "continuous
    reader" model?


    > But unfortunately, my device goes into U2 state whenever there is no bus activity like other endpoints operations.

    The U2 state only affects the link, not your device.  The link is
    supposed to go into a low-power state after you return NRDY, but your
    device shouldn't be changing its own power state if it still has work to
    do.  The link power state is between your chip's USB engine and the hub
    port.


    > My Question is, If one of my endpoint already submitted URB then why device is not wakeup to U0?

    That's a device firmware question.  If you have issued an NRDY, then the
    hub is waiting for your device to send ERDY before it can send another
    IN token.  When your device has data, there must be some firmware API
    call to wake up your USB engine so it can send ERDY.


    > I have also referring deferred packets concept to resolve this problem and found that in LinkControlWord there is Deferred bit... If i set it to 1 than it should works
    >
    > How can I set that bit?

    You are looking in the wrong place.  The problem is in your firmware.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • Bhoomil_ChavdaBhoomil_Chavda Member - All Emails Posts: 7

    thanks, Tim for your replay. Still, investigate the problem. but for a simplified solution as of now, I have disabled the power down mode of firmware and it is working good.

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
Developing Minifilters 29 July 2019 OSR Seminar Space
Writing WDF Drivers 23 Sept 2019 OSR Seminar Space
Kernel Debugging 21 Oct 2019 OSR Seminar Space
Internals & Software Drivers 18 Nov 2019 Dulles, VA