USB HID Device using ReadFile - ReadFile locks / no return sometimes

[bm.nJoi]

Hey all, first post on here so I'm sorry if I don't follow the right process of getting help, I'll try to provide as much info as I can.

First, I work for a company that does military applications so I can't give great detail into the use of my software and why I do it the way I do it so try to keep broad-sweeping changes to a minimum because they are of no use to me!

Now, onto the code / application:

I am writing a C#/WPF application that speaks to a device over USB HID protocol and I'm experiencing problems with communication.  When I use the kernel32.dll's ReadFile from a validated hidHandle, there's approximately a 1/100 chance that the function just NEVER returns!! Ughhhh!! Right now my workaround is simply threading out the upper level functionality so if it ever locks up it will clear the thread out and try it again. 

Where I need help? I am trying to port over the author of this website's generic HID driver + GUI application into my WPF application.  I have found that my device does not currently support the Get/SendReport methods (or so it appears, they always fail when I tried them) in the hid.dll (HidD_SetOutputReport()...), so I am going to be using the same WriteFile/ReadFile implementation that my last API used.

Here's as much code/psuedocode as I can possibly provide from my old API that would lock up during ReadFiles.  If anyone can find anything wrong with what I was doing or really any insight at all into my situation it would be greatly appreciated, thanks!

Also, the last bit of insight into this project is that the device exclusively talks to the WPF application I am writing so it has no need to check for capabilities and such, it will only respond to the software I write so none of that capability checking stuff is utilized by either end.

My Connect Function (w/ psuedocode)
//
driver.HidGuid();
driver.SetupDiGetClassDevs();
int interface = getDevice; //psuedocode
if(correctDevice){ // psuedocode
  SetupInterfaceDetail() // psuedocode
  didItWork = driver.CreateFile(devicePath, READ | WRITE, SHARE_READ | SHARE_WRITE, 0, OPEN_EXISTING, 0, 0);
}
//
My Read Function - this is the function that gets hung up and i'll comment the line that doesn't return
//
if(driver.HidD_GetPreparsedData(driver.HidHandle, ref ptrToPrepData) != 0)
{
  driver.HidP_GetCaps(ptrToPrepData);
  return ReadFile(hidHandle, Buffer, InputReportLength, ref numBytesRead, null);  // this line does not return sometimes, this is a kernel32.dll import ReadFile in my C# usb driver
}
//
My knowledge of HID USB communication is unfortunately minimal, this project already had its driver api written before I got my hands on it and now I'm trying to clean up the mess left behind so I am still in the learning stage of this HID USB comms stuff. 

Any help would be greatly appreciated, let me know if I need to provide more detail or whatever! Thanks!

-bm.nJoi

[Jan Axelson]

ReadFile returns on receiving an Input report that matches the size that the report descriptor defines for the Input report (or any Input report if using multiple report IDs.)

If ReadFile isn't returning, the device isn't providing data, or isn't sending the correct number of bytes.

If you can't fix the device firmware, use a ReadFile timeout.

Filestream methods are an alternative to ReadFile.

My example HID code is here:

www.Lvr.com/hidpage.htm

[bm.nJoi]

Thanks for the quick response!

I have done countless debugging attempts trying to prove that the hardware code wasn't sending data but I have proven time and time again that it is.

There is a chance that the GUI is over-reading (asking for a packet too many times so it eventually hangs when it doesn't get data when it over-reads?), are you confident enough in the ReadFile implementation that if I am sending bytes up (always according to same packet structure, its a simple communication to say the least) that the only way it would not return is if not enough packets were sent on the hardware end?  I am just skeptical because with the API i'm using i've read a lot of other people having problems with this occurring.  I could also potentially believe that the API was double-reading (not the top level GUI I have) and that would be the source of others experiencing this...  It couldn't be ANYTHING else?

Also, for perspective, my device is a TI MSP430 and the HID drivers are unmodified TI driver code.

[Jan Axelson]

It can be not enough packets or just the wrong number of bytes (not a valid report). If the report fits in one packet/transacation, and the firmware mostly works, it's probably not the wrong number of bytes.

The host application doesn't request packets.

Instead, the lower-level HID driver requests the host controller to request packets from the device.

The HID driver stores the received packets as reports, which may consist of one or more packets depending on the report descriptor.

The host application requests reports from the HID driver. The driver sends a previously received report if available or if the driver's buffer if empty, waits for a report to arrive.

If the host application requests a report and the device isn't sending any, ReadFile will hang unless using a timeout.

If the ReadFile buffer is big enough to hold multiple reports and multiple reports are available from the driver, ReadFile will return as many reports as will fit in the buffer. So you could miss a report in that situation.

A protocol analyzer would show what is happening on the bus.

[bm.nJoi]

Can you suggest a good analyzer for HID analyzing?  I used a trial of USBLyzer in the past but it was for something different and since it has expired, I am trying to find one that's as user-friendly as possible because I'm going to be having an associate with less knowledge than me assisting me in debugging this issue.

Thanks!

[Jan Axelson]

See

http://www.lvr.com/development_tools.htm#analyzers

Software-only analyzers can be useful, but to see what is on the bus (which can save much time!), you need a hardware analyzer.