USB HID Failing (Long Term connection)

 I have been running long term tests on the Brick Controller 2.  The setup is as follows:

Connection

• USB connected to PC
• Debug Serial Port connected to PC
• PICKit3 connected only to program PIC32
• LEDs hooked up only to verify PC connectivity and response

PC

• TeraTerm to watch the debug serial port
• HID Device Tester-PC program to report what Windows see as plugged in HID devices
• MyMakerTools BrickBuddy software ready to run, but not running

Test Process

1. Download program into PIC32
2. Verify the BC2 connects to PC via debug serial port and HID device tester
3. Start MyMakerTools software to verify HID connection and control of deivce (exercise LEDs)
4. Close MyMakerTools software
5. Wait 60 to 90 minutes, sometimes hours
   
6. Repeat steps 3 thru 5 until failure occurs

The first data showed that the failure is happening in the USBDeviceHIDEventHandler, which is part of the Harmony framework.  The event handler is triggered by the USB framework that is part of the USB driver/middleware of the Harmony Framework. 

When the MyMakerTools software starts up it sends a report (USB terminology) to the device, basically it is a 64 byte message to start the application level connection process so the PC software can determine what is connected.  The event that is triggered in the Brick Controller 2 is:

USB_DEVICE_HID_EVENT_REPORT_RECEIVED

Here are the comments from the Harmony Framework

    /* The eventData parameter will be
   * USB_DEVICE_HID_EVENT_REPORT_RECEIVED pointer type containing
   * details about the report that was received. */

What this does is take the pointer to the eventData that is passed to the HID event handler from the USB driver and cast it as report received type.  The next thing it does is check the driver handle to see if it matches the handle when the USB device was opened.  For some reason it is not matching.

What I tried was to implement a restart of the USB driver.  I created a new state in USB tasks called USB_STATE_RESTART.  In this new state I call USB_DEVICE_CLOSE with the handle.  Then I start the USB initialization again, reopening the the USB Device.  This failed to do a complete restart, but I did not have enough debug info to determine what was happening.

On the next capture, the UART debug port revealed the USB EVENT handler had executed a Device Suspend event (this happened the last time also, but I failed to keep the capture).  The USB driver went through some tasks of trying to reconfigure, the driver handle is set to invalid and then it receives a USB Device Resume event followed by a HID SET IDLE event from the PC.  This is where I think the issue emanates from.  For whatever reason the PC puts the device into suspend, then resumes and then a HID set idle.  When I launch the MyMakerTools software, the PIC32 code detects the request, but the driver handle is invalid.  The newly added code appears to successfully re-initialize the USB driver, but it fails to connect.

Now for whatever reason, the PC is not sending the USB Device Suspend event.  It has been 36 hours and the device is still running and working.  

This is really a very small corner case, but it is bothering me.  For now I will leave it alone and go on to other items in the TODO list.  When I have time or need to do something else, I can always set this up and run the tests.