Re: Bug in OHCI2 driver for Windows CE 5.0?

CE's USB stack is not derived from any of the desktop Windows stacks; you
cannot assume that they will always work similarly. In particular,
misfeatures from the desktop are probably not present in CE.

Be very careful with short packets. A short packet (i.e., a packet smaller
than the endpoint's maximum packet size) ALWAYS ends a transfer.
SHORT_TRANSFER_OK only controls whether the transfer status will be success
or error when that short packet results in the whole transfer being shorter
than what was specified when the transfer was Issued.

Zero-byte control transfers do work; several of the standard control
operations lack data stages (e.g., SET_ADDRESS). In what way do you see them
not working?

- Jeff.

"Elad Raz" <elad@xxxxxxxxxxxxx> wrote in message
news:1147550679.368799.267770@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Hi all,

I'm in a middle of porting USB device-driver from Windows NT/2k/XP...
to Windows CE, and I have few questions:

Did anyone knows why I can't transfer zero byte vendor-transfer? (It's
failed immediatly)

That was the easy question. Now for my serious one, we have couple of
hardwares and firmware versions which the driver should work upon:
1. A low-speed device (Contains couple of firmware versions)
2. A full-speed device (Contains couple of firmware versions)

The low-speed device and the first firmware version of the full-speed
device are working ok
(Except for the 0 byte transfer which we had to put a dummy byte
instead... We have try virtually every possibility for argument
cominations.)

However we got some problems in the second full-speed device and a
special version of the low-speed device.
After poking in the hardware and in the driver code, we have found that
a time-out occured for a control transfer (Vendor transfer).
The timout was caused due to the following:
- For all hangs versions (both full-speed and high-speed), the
firmware version sends short-packets. The USB transaction
is closed before all accpeted bytes are transfered. Since we
have used the USB_SHORT_TRANSFER_OK flag, we assumed
that the OHCI device stack will act like the 2k WDM stack.
- The tranasction is hung only if the number of recive bytes are
lower then the USB transaction length.
- Sometimes the previous rule is not completly applied (We
couldn't figure out the reason for that)

Anyway here are my questions:
1. Did anyone encounter these bugs before?
2. If so, do you know about a standard solution for it (QFE maybe, we
installed the latest)?

Thanks for advance,
Elad.



.

Relevant Pages