Author Topic: How to resume USB after suspend  (Read 12121 times)

david.dobsky

  • Member
  • ***
  • Posts: 4
How to resume USB after suspend
« on: April 30, 2020, 04:14:14 pm »
Hello,

I am completely new to USB development.

We are trying to develop a HID based full speed device and are using a Microchip PIC32MZ part for the device along with their "Embedded Connectivity Starter Kit".  We have started with the Microchip "hid_basic" demo code and can send and receive data fine using a modified version of the "Generic HID Tester" code.  The main issue we have now is that the device will go into suspend as indicated by onboard LEDs when there is no bus activity.  Communication after that will not occur unless the device cable is unplugged and plugged back in. 

I have read about the resume signals that are sent from the host to get a device back into a normal mode and have looked at the USB specification concerning this.  My question is what command does the host program need to send to the device so it can see the resume signal and start normal operations?

Any suggestions or direction would be greatly appreciated.

Jan Axelson

  • Administrator
  • Frequent Contributor
  • *****
  • Posts: 3033
    • Lakeview Research
Re: How to resume USB after suspend
« Reply #1 on: May 03, 2020, 05:45:48 pm »
Can your host software send periodic control requests (Input, Output, or Feature reports)? And if so, does that keep the device from suspending?

Even if the device is suspended, sending a request should wake it.

The host isn't polling for Input reports?


david.dobsky

  • Member
  • ***
  • Posts: 4
Re: How to resume USB after suspend
« Reply #2 on: May 04, 2020, 07:58:33 am »
Thanks for your reply. The host program could send commands could but the main issue is if the device is started before the host program is started.  Right now, the device will go into suspend, then if the program is launched, the device (indicated by LEDs) has either been de-configured by the host or a bus reset has occurred.  The only time so far that data can be sent back and forth to the device is if the host program launches and begins sending commands before the device goes into suspend.  Any thoughts on this would be greatly appreciated.

We have also been looking at a Winbus solution.  There is a Microchip demo program for that as well. So far, the Winbus demo does not go into suspend if the host program is not running and it looks like I should be able to send and retrieve data in a similar manner.  I am beginning to go through the Winbus host project code you have on you website. Hopefully I will be able to see if that is a good solution for us soon.  If you have any thoughts on using an HID versus Winbus solution, that would be appreciated as well.

Thank you for your time.

david.dobsky

  • Member
  • ***
  • Posts: 4
Re: How to resume USB after suspend
« Reply #3 on: May 04, 2020, 03:08:22 pm »
I have tried to make use of the WinUSB project and have updated the VID, PID amd GUID as noted on the website in the winusbdemo.inf file. I currently have a Microchip project using their inf file.  When I try to update the driver through Device Manager to use the WinUSB driver, I get an error as noted in the attachment.  I have downloaded the WDK as well.  Any guidance on this would be appreciated.  Thank you.

Jan Axelson

  • Administrator
  • Frequent Contributor
  • *****
  • Posts: 3033
    • Lakeview Research
Re: How to resume USB after suspend
« Reply #4 on: May 05, 2020, 11:49:31 am »
For issues with Microchip firmware and host software, the Microchip forums might be a better source of help:

https://www.microchip.com/forums/Forums

Assume you mean "WinUSB" not Winbus. Briefly: HID advantage - all OSes support it. WinUSB advantages - can use bulk transfers, not limited to defined report structures.

To troubleshoot installation issues, see:

https://docs.microsoft.com/en-us/windows-hardware/drivers/install/setupapi-device-installation-log-entries

david.dobsky

  • Member
  • ***
  • Posts: 4
Re: How to resume USB after suspend
« Reply #5 on: May 06, 2020, 06:52:32 am »
Thanks for the suggestions.  I think we are going to proceed with a Winbus solution.  We got communications going this morning.  Thank you very much for your help.  Take care.