Author Topic: Sleep / Suspend issues  (Read 10485 times)

vanweric

  • Member
  • ***
  • Posts: 24
Sleep / Suspend issues
« on: April 13, 2013, 11:09:56 am »
My apologies for an overly broad question.  I am having trouble with a finicky USB HID device when the host computer enters and resumes from sleep while the device is attached and being communicated with.  I was hoping you may have some advice in how to narrow my field of search.

The behavior appears to be dependent on the exact host that is connected.  On one laptop, the first read from the device returns what looks to be part of the negotiation packets from enumeration.  This behavior does not reproduce on my machine, so I do not have clearer information yet.  On my desktop (Win 7 x64), I get AccessViolationExceptions in the calls to read, write, and enumerate.  Similar issues happen on Macintosh.  The code pinvokes the hidapi library.

What is a good first step towards narrowing this search?  What specific information can I provide that would be helpful?  I have access to external USB analyzer, but I do not have good access to the innards of the device.  To change device behavior, I will need to prove what is going on before the firmware team will respond.

Thank You

Jan Axelson

  • Administrator
  • Frequent Contributor
  • *****
  • Posts: 3033
    • Lakeview Research
Re: Sleep / Suspend issues
« Reply #1 on: April 13, 2013, 11:25:01 am »
By "enumerate," I will assume you mean "the application attempts to retrieve information about the device" since enumeration is done at a lower level, on device attachment.

The protocol analyzer should show that the SOFs (or keep-alives if low speed) cease, putting the device in the Suspend state. Look at what happens when the SOFs or keep-alives resume. The device should start ACKing OUT packets and returning data or NAK in response to IN packets. If you don't see that, the firmware isn't responding properly to waking from Suspend.


Tsuneo

  • Frequent Contributor
  • ****
  • Posts: 145
Re: Sleep / Suspend issues
« Reply #2 on: April 14, 2013, 02:06:20 am »
Quote
On one laptop, the first read from the device returns what looks to be part of the negotiation packets from enumeration.

What is the laptop OS and its version?
At Vista SP1 and later, MS had changed host behavior after Suspend, as follows (*1)
Up to WinXP, bus reset (and following enumeration) is the first host action after Suspend.

(*1) "Do USB devices get reset on system sleep resume?" - Microsoft Windows USB Core Team Blog
http://blogs.msdn.com/b/usbcoreblog/archive/2009/10/27/do-usb-devices-get-reset-on-sleep-resume.aspx

Old behavior: In Vista RTM, when the system resumed from sleep, the USB stack used to reset the host controller, thereby resetting the whole bus.
...

New behavior: Because of these disadvantages, it was decided to change the stack behavior so as to not do the bus wide reset on system resume, except in some special circumstances. In Vista SP1, the new behavior was implemented but was configurable by OEMs and most of the OEMs chose the old behavior. In Windows7, the requirement to support the new behavior was hardened. Consequently USB devices in Windows7 will not be reset on system resume, unless the device lost power during sleep cycle.


Tsuneo