Bug in OHCI2 driver for Windows CE 5.0?

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.

Jeff
Sun May 14 05:06:08 CDT 2006

Elad Hi

I have heard of this problem in the past. Unfortunately I know of no
ready fix for it. Thee is some rumor about a new technology on the
market ... BLUE something. You might want to look into it.

Jeff

Elad Raz wrote:
> 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.

Jeffro
Sun May 14 06:58:29 CDT 2006

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@raztech.co.il> wrote in message
news:1147550679.368799.267770@j73g2000cwa.googlegroups.com...
> 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.
>

Elad
Sun May 14 11:29:21 CDT 2006

About the zero-byte control transfer. The USB stack does send zero-byte
transaction as you said, we saw that in our USB logger.
What I meant was I cannot use this feature with the IssueVendorTransfer
API. Whenever I put a zero-length or/and null-pointer buffer the method
failed before the USB stack sends the command down to the root-hub.

About the CE's USB stack: The hardware ends the transaction (We saw it
in the USB logger), but the SHORT_TRANSFER_OK flag, as you said doesn't
work with this praticular stack implementation. When I saied the
SHORT_TRANSFER_OK doesn't work was the following:
- Our device send the information and close the transaction (We can
verify that using a simple logger, and we did)
- The driver (invoking the IssueVendorTransfer with SHORT_TRANSFER_OK)
doesn't get any result from the USB stack and keep waiting
- A timeout occured, and the USB return faliure code.
- The buffer for the TD description doens't contains ANY information
sent by the device.
We cannot change the firmware itself since its operational over
thousands of users.
We must make the USB stack to work.

Thanks for the reply.
Elad.

David
Mon May 15 15:59:11 CDT 2006

IssueVenderTransfer should work with zero length data. Do you have any debug
output or captured USB bus data to show this problem.
Thanks
David Liao
"Elad Raz" <elad@raztech.co.il> wrote in message
news:1147624161.129276.97060@j33g2000cwa.googlegroups.com...
> About the zero-byte control transfer. The USB stack does send zero-byte
> transaction as you said, we saw that in our USB logger.
> What I meant was I cannot use this feature with the IssueVendorTransfer
> API. Whenever I put a zero-length or/and null-pointer buffer the method
> failed before the USB stack sends the command down to the root-hub.
>
> About the CE's USB stack: The hardware ends the transaction (We saw it
> in the USB logger), but the SHORT_TRANSFER_OK flag, as you said doesn't
> work with this praticular stack implementation. When I saied the
> SHORT_TRANSFER_OK doesn't work was the following:
> - Our device send the information and close the transaction (We can
> verify that using a simple logger, and we did)
> - The driver (invoking the IssueVendorTransfer with SHORT_TRANSFER_OK)
> doesn't get any result from the USB stack and keep waiting
> - A timeout occured, and the USB return faliure code.
> - The buffer for the TD description doens't contains ANY information
> sent by the device.
> We cannot change the firmware itself since its operational over
> thousands of users.
> We must make the USB stack to work.
>
> Thanks for the reply.
> Elad.
>