Tim Roberts wrote:
Have you considered changing your interrupt endpoint descriptor to
specify the period as 1ms instead of every 8ms? Unless your device
clock is synchronized to the USB clock (which it probably is not), you
always have the possibility that the timing will come in just a bit
off.
The bInterval in the endpoint descriptor is set to 1. This should cause the USB host controller to poll every single micro frame (125?s).
We use a FX2 chip in slave FIFO mode. The timing is controlled by our FPGA (and there is really no way our FPGA could not get timing right!). The FPGA continuously writes data to the endpoint and flushes the buffer every 8ms (the FX2 processor isn’t doing anything). We used the same hardware with our non WDF driver and we had no problems at all. As I said, the timing even works out if I use a manual continuous reader in WDF terms (request create, send, reuse).
Most programmers would not detect this problem as throughput is the prime concern for the majority of applications. Since no data is lost in the end, its very hard to see this bug if you are not watching the timing carefully. On receiving data, we send new data to our hardware. The hardware watches the timing very strictly, so we detected the problem.
How does your device react if the interrupt endpoint request comes
in a microsecond before data is ready? Do you reject it, or do you hold
off?
Have you hooked up a USB analyzer to see what the actual traffic looks like?
Yes, I watched the timing using various USB analyzers. I am not exactly sure where the USB analyzer hooks on. My feeling is it observes the requests between the MS framework and the host controller (rather than hardware to host controller). The problem seemed to be the same but I’ll have another go at this.
I would be less convinced that the bug is somewhere in the WDF continuous reader if the data would just come a little bit to late (say 1ms or so). However, the old data arrives just exactly when the new data is due. The reader seems to loose the request on its way to the USB host controller.
Thanks a lot,
Johannes
Spinneken, Johannes wrote:
Our hardware sends relatively short blocks of data (say 300 bytes)
with a rate of 128 Hz (about 8ms). An interrupt endpoint is used.
The timing of the data is crucial for our application.
The WdfUsb continuous reader seemed to be ideal solution, as data is
received as long as the device is attached. However, the following
problem occurs:
- The reader operates fine most of the time
- every now and than (say about 1 in 1000) the reader seems to drop a
call, the block of data is not read from the device
- the “lost” block of data is read in the next time slice
Thus, the timing would be (example)
…
time+0 ms data
time+8 ms data
time+16ms continuous reader does not call back
time+24ms data (from +16ms) and current data
…
This delay is not acceptable for our application. Using a manual
request mechanism (create, send and reuse a request for continuous
read) works out.