USB Interrupt pipe time out problem
- From: Hans <kuykens@xxxxxx>
- Date: Thu, 14 Aug 2008 23:20:39 -0700 (PDT)
Hi ,
We experience a mind boggling problem during development of a USB
driver for a monitor running WinCE 5.0.
Our host computer is an ETX board Pentium Mobile 800 Mhz which
includes a USB controller.
Other hardware is developed in-house.
Our monitor communicates with an in-house developed sensor via USB
1.1, passing data at 200 Hz over an interrupt pipe. This has been
working satisfactory for some time.
We now want to add a 3rd party USB device that also uses USB 1.1 to
pass data at 2000 Hz to the monitor. Data communication with this
device falls into two stages:
a. a small header is sent over an interrupt pipe.
b. actual data samples are collected from a bulk pipe. The header
indicates how many samples to receive on the bulk pipe.
Capturing the data is done through a thread in a stream driver
implementation by ping-ponging between querying the 2 pipes for data.
The monitor application in return has a thread running to scoop out
the acquired data to the application.
Thread priorities are set such that:
Priority Driver thread > Priority Application Thread > Priority
Application GUI thread
Running both sensors at the same time in a normal state works OK.
However, if we stress the host computer by creating a lot of GUI
activity (signal drawing) the connection with the 3rd party device at
a particular point interrupts. Our own device keeps functioning as
normal.
When we inspect the signals in our USB protocol analyzer it appears
that the querying process to the 3rd party device suddenly stops.
We added some logging code in our driver which, together with USB
logging output, reveiled the following:
1. Our reading thread in the driver still loops after the interruption
of collecting sample data
2. In the driver, at some point we see a time out on an IN transfer on
the interrupt pipe
3. After that the interrupt IN pipe keeps returning time outs ( to the
driver )
4. the last 1 or 2 packes observed in the USB log are non-corrupt
interrupt IN transfers
5. the host does not flip to reading the associated bulk pipe packet,
possibly caused by the failing read (i.e. the time out on the
interrupt package)
6. if a 2nd package IN transfer is fired after the first time out it
comes after the time out period that we specified in the
interruptreadpipe function
Our conclusion is that even though a complete interrupt package was
transferred through the interrupt IN pipe (as we saw in the USB log)
WinCE did not "recognize" it as a valid transfer and fired a timeout.
Our driver code is designed to continue attempting to read the
interrupt IN pipe. We see the loop running and thus expect continuing
Interrupt IN transgers. However, after that point no additional
transfers are detected in the USB analyzer log. The driver keeps
receiving time outs...
My questions are:
- is it possible that the USB driver stuff in WinCE comes into a state
where a request to initiate an IN transfer is not passed to the lower
level drivers / hardware after such time out?
- can heavy load on the CPU (even when present in a lower priority
threads) indeed jeoperdize USB stability
We would appreciate your help....
Hans
.
- Follow-Ups:
- Re: USB Interrupt pipe time out problem
- From: Michel Verhagen (eMVP)
- Re: USB Interrupt pipe time out problem
- Prev by Date: Re: Question about activesync connection
- Next by Date: Re: Program memory usage in Windows CE 5.0
- Previous by thread: 3.5inch display problem
- Next by thread: Re: USB Interrupt pipe time out problem
- Index(es):
Relevant Pages
|
