WriteFile / ERROR_GEN_FAILURE error

[beth]

Hi,

I have an application that communicates to a PIC controller via its USB port using USB HID protocol.  The application code is written in C#, .NET 3.5 Framework, VS2010, and is based on your generic_hid_cs example code.

The application runs and sends a command to the PIC at least once a minute.  The application usually runs for a number of hours without a problem.  However, the application eventually gets a "HID Write Output Failure", and the Win32 Last Error Code is 31, which means "A device attached to the system is not functioning."  It takes 12-15 hours for this error to occur. I have tried to google this error with respect to HID / USB to no avail.  I am trying to determine 1) why this error occurs, and 2) what the application can do to recover (or should something be done in the firmware?).

The application code opens both a read handle and a write handle to the usb:
                        readHandle = FileIO.CreateFile(myDevicePathName, FileIO.GENERIC_READ, FileIO.FILE_SHARE_READ | FileIO.FILE_SHARE_WRITE, IntPtr.Zero, FileIO.OPEN_EXISTING, 0, IntPtr.Zero);
                            writeHandle = FileIO.CreateFile(myDevicePathName, FileIO.GENERIC_WRITE, FileIO.FILE_SHARE_READ | FileIO.FILE_SHARE_WRITE, IntPtr.Zero, FileIO.OPEN_EXISTING, 0, IntPtr.Zero);

The application code writes to the HID using OutputReportViaInterruptTransfer - however I believe the application code creates a single object of this type for the entire duration of the application and simply continues to call Write():
                    success = FileIO.WriteFile(writeHandle, outputReportBuffer, outputReportBuffer.Length, ref numberOfBytesWritten, IntPtr.Zero);

I tried a test where after the WriteFile failed, and the error code 31 was logged, then the writeHandle did not get closed.  However the application code was then "hung" anytime it tried to write to the HID.
Interestingly enough, the readHandle is still intact - we use it to read the HID and generate events that the application code receives.  This still works after the write HID failure.

The application code runs on a specific device, based on Windows XP platform.  There is no debugger installed on the target device (not sure how useful that would be anyway since it takes many hours to reproduce the problem).  I am sure there is other information I should give, but that's all I can think of for now.

I am going to try another test to reinitialize the write error when an error occurs, but since it takes a long time to see if that works, I thought I would post a question here in the meantime to see if I can learn any additional information.

Thanks,
Beth

[beth]

If it helps, here are the capabilities:

      Usage: 1
      Usage Page: ff00
      Input Report Byte Length: 65
      Output Report Byte Length: 65
      Feature Report Byte Length: 0
      Number of Link Collection Nodes: 1
      Number of Input Button Caps: 0
      Number of Input Value Caps: 1
      Number of Input Data Indices: 64
      Number of Output Button Caps: 0
      Number of Output Value Caps: 1
      Number of Output Data Indices: 64
      Number of Feature Button Caps: 0
      Number of Feature Value Caps: 0
      Number of Feature Data Indices: 0

and we are not using overlapped reads/writes.

Thanks,
Beth

[Jan Axelson]

The host driver will give up if the endpoint fails to return ACK or NAK after three tries. The host may then send a Clear_Feature(Endpoint HALT) request. If you can trigger a protocol analyzer on that request, you might see the error.

Jan

[beth]

I'm sorry, I'm not quite sure what you mean by "The host may then send a Clear_Feature(Endpoint HALT) request. "  Is this something that the host application (C#) would send?  I haven't been able to find any information on how it would do this.

Or should closing the write handle accomplish the same thing?  It doesn't appear to help, as I've tried a test where I closed just the write handle when I got this error then re-opened it.  But that didn't help.

We've been able to reproduce this problem much quicker when we have a debug cable attached to the firmware and are issuing debug commands at the same time the application software is sending commands (writing) to the hid firmware.  Our hardware engineer thinks "The PIC probably is not responding with an ACK or NACK within a predefined time period because it is working on other routines that are interrupt driven, while  The USB firmware stack is polled (not interrupt driven).  It finally responds and thinks that everything is OK; meantime, the host thinks that everything is NOT OK and holds the Write handle as BUSY.  No more data will come through from then on."

So it makes sense to me that the clear/halt will work to reset the endpoint, I just don't know how to initiate this from the host application.  The firmware isn't aware that there is a problem.  Alternately, if I could close and reopen the handle, but that didn't seem to have any affect.

Thanks,
Beth

[Jan Axelson]

The endpoint should be able to NAK even if the firmware is busy. That's what NAK is for.

The host driver, not applications, sends Clear_Feature. It's a last resort to restore communications. If you're seeing it, you should find and fix the problem that is causing the host to send the request.

Jan