If each report is sent synchronously and each report fits in the devices input buffer, how could the buffer get overwritten?
Here's one way: Some of the reports are received back to back. The report includes a setup and data packet. Once the report is received, the device starts decoding the setup packet. During this time, the next report is received which overwrites the previous data packet before the device has decided what to do with the data.
There is an obvious timing issue involved here but I'm confused as to why synchronous writes appear to have an asynchronous quality to them. The offending command consists of 4 hid reports of the same size. I send each of the 4 reports synchronously. It appears that when I write the 4 reports one after the other, they clobber each other. In theory, I should not be getting control back in my driver to send the next report until the first report has finished.
What component is performing the blocking and reporting to the OS that the write has been performed?
Ok, before I get to the next questions. I'm not a windows programmer. Although, we may use windows a bit, we really use a real time linux usb stack that we wrote. Second, I'm on the other side. Designing the device and FW for it. I've helped the application programmers a bit, but am standing on less firm ground.
Your reports are being sent out fine. All four of them are there. Even get back an Ack saying it was received. But some of that is really low level and done in HW.
Let's say your application is really low level. As far as your application is concerned, everything is fine. Data was sent out and received fine. The device is where the probelm is. It received the data just fine.
With Windows though are you even that low enough of a level. Aren't you merely sending it to the next buffer or part in the OS or even the stack that says, I'll take it from here. The HW or Stack would probaby do a retry a couple of times before it complains to you that there is a problem.
Kind of like file I/O. Just because you write a file out, doesn't mean it is actually on the disk. It could be in some cache or temp storage getting ready to be written, but the OS or HW is taking care of that for you.
Some of that is simplified to get my point across, but should be correct in general.
Just out of curiosity, I'd like to see the analyzer dumps. This is my first venture into USB devices so you've got me interested in fully understanding this. The workaround will suffice for now though.
Sorry that last part was meant for Randy. I'm assuming he'd give you permission, but just want to make sure. The part I'll clip out isn't too terribly exciting, but will show the offending part. I'm going to see if I can borrow an OHCI card to get a capture of that as well.