hidg_set_report_complete FAILED

[Jan Axelson]

A host might disable an endpoint after repeated failures in communicating with it, for example, no response at all to a packet directed to the endpoint.

[coolsunny]

As it is a composite driver, whenever there is a problem I see the HID channel is good (looking at the USBlyzer traces) but the Host is not able to communicate on Mass storage end points. In my case, I have a windows application on mass storage driver which talks to the device on HID channel. I also read from your book that the device will be considered idle in some cases.

I am also not sure whether i need to look at the power management of iMX28 processor which might be happening from the device side also.

[Gurkan]

Dear Forum Comunity;
I am trying to improve myself in USB with Microchip 18F series, using XC8 compiler.
I am using VisualStudio2010 - VB.net in Windows 8.0; I used mainly Jan's VB.net generic HID example
I have a smiliar problem to this subject.
- The Enumeration seems to be completed without any problem, I checked with software analyser
- If I connect the USB to 2.0 port after forcing 2 or 3 successful control transfer out operation then the PC application freezes. (300milisec between the transfers)
- If I connect the USB to 3.0 port after forcing 250 or 300 successful control transfer out operation then the PC application freezes.(300milisec between the transfers)
- In both situation, analyser says "Transfer Failure 0xC0000011".
- I canceled the Interrupt in/out operations and Control In transfer. Again I received the same problem.
- If I try only Interrupt In and/or Interrupt Out; no problem occurred.
- I tried only Control In transfer and I received same problem.
- After getting this failure, nothing resets the device and I should physicaly disconnect the cable and reconnect.
- After getting this failure, I can see no abnormality when I check my device in device manager. Still there with configured.
- When I try my hardware and my application in Windows 7 enterprise; I receive neither a failure nor an abnormality; works great for a long time (tested 6 hours). (300milisec between the transfers
- Then I decided to test it in Win8.1 in other PC; I received the same problem.

Am I facing a driver issue? I am very bad in VB.net programming and Windows OS & driver systems.
I will appreciate for any support or any clue which will drive me to solve my problem.

Thank You in Advance
Gurkan
 

[Jan Axelson]

It's likely a problem in the device firmware. Different OS editions might not encounter the issue or may "forgive" it.

A hardware-based protocol analyzer can show what is happening on the bus. If you don't have an analyzer, use whatever debugging tools you have to isolate the problem.

The device MUST return ACK or STALL to every valid received Setup packet and data that arrives in the Data stage.

[Gurkan]

Hi Jan
Thanks a lot for the feedback.
I have figured out that my problem is the timing issue. In otherwords Bus BANDWIDTH.
in 32bit Win7 (in slower PC), my device firmware answers "without any problem" to the setup stage of SET_REPORT request; however, in 64bits Win 8.1 (Faster PC), my firmware cannot responses fast enogh after the status stage of setup token; then host drops the device after 3 failure.
The point is that, I face no problem during the enumeration. However, SET_REPORT fails after 8-10 successfull Control Transfer in faster PC.

The the problem in the links is not the same as mine, but similiar
http://www.microchip.com/forums/m839410.aspx
http://www.microchip.com/forums/m593364.aspx

As far as I see; there is no possibility to touch the timings between the tokens of the Control Transfer Transactions.

From USB Complete :

The host must make its best effort to ensure that all control transfers get
through as quickly as possible. The host controller reserves a portion of the
bus bandwidth for control transfers: 10 percent for low- and full-speed
buses and 20 percent for high-speed buses

Kind Regards
Gurkan

[Jan Axelson]

If you are saying that the device is failing to ACK the Setup stage of control transfers, that is not a bandwidth issue, it's an issue of device hardware not being configured to detect and ACK all Setup stages of control transfers.

In the Data stage, the endpoint may return NAK for up to 5 seconds before accepting the data.

In the Status stage, the endpoint may return NAK for up to 50 ms before returning a ZLP.

If the endpoint isn't responding at all, the host will give up.
 

[Barry Twycross]

Making sure that your device endpoint can always receive a SETUP packet can be tricky. For the device I'm working on now, I turn on SETUP packet reception in the ISR when there's a completion on endpoint zero.

Its usually not impossible to manage, just can be tricky.

[Gurkan]

Thanks a lot for your comments and efforts as well;
I have found an intresting and very simple bug in my firmware (Microchip - PIC18F2550)
Believe me there is no need to explain this bug  .

Thanx again
Greetings from Turkey & Kind regards
Gurkan

[Jan Axelson]

Happy to know you found the problem! Thanks for letting us know!