This problem has really bothered me, since I know it should be fixable. After searching the Microchip site, I finally found the Harmony USB Reference for V2.06. (Be careful, Ver1.11 still exists. Don't know if there are differences.) Digging through this and going back to the original Harmony HID example program, I found a slight difference.
As I noted in the previous post, the Device Suspend, Device Resume and HID Set IDLE sequence bothered me. Looking at the USB Reference, they specifically note that neither Device Suspend or Device Resume require a response from the PIC32 Application. The example program only does a SYS_PRINT for each state in the state machine. However for some reason I changed the state of the USB_Tasks STATE MACHINE to WAIT_FOR_CONFIGURATION. Not sure why I did this, but this is where the HID Rx HANDLE is being change to invalid.
This is happening in the function call to USB_DEVICE_HID_ReportReceive. The USB reference has this for the description of the function call
This function submits the buffer to HID function driver library to receive a report from host to device. On completion of the transfer the library generates USB_DEVICE_HID_EVENT_REPORT_RECEIVED event to the application. A handle to the request is passed in the transferHandle parameter. The transfer handle expires when event handler for the USB_DEVICE_HID_EVENT_REPORT_RECEIVED exits. If the receive request could not be accepted, the function returns an error code and transferHandle will contain the value USB_DEVICE_HID_TRANSFER_HANDLE_INVALID.
The important part to note is the last line, the transferHandle value is changed to INVALID. Additionally this function returns one of 4 results. Currently this result is never checked.
It now became obvious that ReportRecieve function was changing the transferHandle to invalid, because it is called in the WAIT_FOR_CONFIGURATION state of the USB Tasks state machine. This function call was needed after configuration in the initial configuration or the USB connection would not work. But at this state of the connection, this is causing a problem. So I changed the action in the Device Suspend state to "no action".
After testing, this change solved the problem. The Brick Controller 2 goes through the sequence of SUSPEND, RESUME and HID SET IDLE, but the transferHandle is not invalidated. When the MyMakerTools software starts, it connects normally. Problem Solved.
One last comment. I have said this before, the generated Harmony Source in APP.C is quite good, but it is not production code. There is insufficient error handling. The USB Reference provides a good starting point to providing proper error handling, but you will have implement the code yourself.
No comments:
Post a Comment