Re: WinCE 5.0 USB connection issues

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

I state this several time. It looks like the Device does not recover from
Reset quick enough.
The Windows CE 5.0 certainly retry 3 times when GetDescript failed. You can
look at the code by yourself in (CHub::AttachDevice())cdevice.cpp

David Liao.

"Darren Steadman" <darren.steadman@xxxxxxxxxxxxxxx> wrote in message
news:1178102351.570979.54850@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
On Apr 26, 8:08 pm, "David Liao \(MS\)" <d...@xxxxxxxxxxxxxxxxxxxx>
wrote:
I am not sure whether your statement is right. The best way to find it
out
is using USB Analyzer which capture the USB data on the bus. If we can
take
look at data on USB bus, we may have more clues

The intialization code for power on the device is located at
Cdevice.cpp
HubStatusChangeThread.

David Liao."Darren Steadman" <darren.stead...@xxxxxxxxxxxxxxx> wrote in
message

news:1177600359.884910.133870@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx



On 25 Apr, 22:06, "David Liao \(MS\)" <d...@xxxxxxxxxxxxxxxxxxxx>
wrote:
Probably problem is power on procedure.(Connect and Disconnect)
USB 1.1 or USB 2.0 specify how USB Host and Function should behave
during
power on procedure. I think windows CE follows this specficiation.
If one side fail to follow the specification, you enumeration coulde
fail
and

Document I referring here is USB Specification Revision 2.0 (7.1.7.3
Connect
and Disconnect Signaling)

if you have device can monitor the signal on USB wire(D+,D- and VBus),
you
probably know which side has the problem.

David Liao

"Darren Steadman" <darren.stead...@xxxxxxxxxxxxxxx> wrote in message

news:1177499262.861991.257160@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

We are currently having issues with the USB drivers under WinCE 5.0
as
far as detecting that a device has been connected when our nk.bin
image is compiled in release mode.

Here is the following setup

VIA EPIA-ML board with latest BIOS
Latest VIA BSP for the specific board
Two identical USB devices (our custom built boards) that use FTDI
usb
controllers, chip ID is FT232RL (batch number 0642-A).

The problem we are having:

Recently we had a new batch of out custom boards made and we started
to integrate them into our enclosures with the VIA EPIA-ML
motherboards. We connect the custom boards to the motherboard using
correctly shielded cables to the internal USB header.

While testing we found that a certain number of the custom boards
were
not being detected by WinCE 5.0 when they were connected. For
testing
we also tried using the external USB ports and they also failed.

We talked to VIA about the problem and they requested that we sent
them a setup that they could test, so we sent (to their German
office)
one of our EPIA-ML boards and two of our custom boards, one that
worked and another that didn't. The German arm of VIA could not find
anything wrong with the hardware interaction and so offered to send
the whole kit to Korea to be tested at their manufacturing plant.
The
Koreans verified that there wasn't any problem with their hardware.

At this point I started to investigate the WinCE drivers. After
testing and placing RETAILMSG output statements I found that the
device was failing on

DEVICE_CONFIG_STATUS_SCHEDULING_GET_DEVICE_DESCRIPTOR_TEST

in cdevice.cpp (UHCD version) It was attempting to get the
descriptor
of the device and fails when calling IssueTrasfer on the control
pipe
in GetDescriptor (same .cpp file) It comes back with dwErrorFlags
set
to 4 which translates to USB_STALL_ERROR.

Now if I put a RETAILMSG call or a Sleep into the IssueTransfer
(Control Pipe) (C:\WINCE500\PUBLIC\COMMON\OAK\DRIVERS\USB\HCD\UHCD
\cpipe.cpp) function at the top before any other code is executed
then
everything works fine. (If the Sleep is too large it breaks other
stuff). The point is it seems to be a timing issue.

From what I can see if a stall is encountered then there is no retry
mechanisum to try and get everything working again.

So the basic questions are:

Why am I getting the stall in the first place?
How should it be handled to give the device a chance to work?
Why does it work in Debug but not in Release? (What I observed above
might answer that)
How can I fix it?

I've already previously had problems with USB devices and WinCE that
was kindly fixed by someone of these boards regarding WinCE not
handling Over current correctly.

It seems that every time we managed to fix and issue with WinCE USB
drivers another appears.

Just as a note it also seems that the same problem as above occurs
under WinCE 6.0 as far as I can remember. I havn't done anything
with
6.0 for at least a month now. So this could be an on going issue
across CE in general.

Help with this would be greatly appreciated as it could potentially
become a big problem for us. We have invested a lot of time and
money
developing our application to run under CE and if these final USB
issues can not be sorted out then it might force us away from CE.

Darren- Hide quoted text -

- Show quoted text -

The device is self powered so it wouldn't be a power problem as far as
I can see, however I'll get our hardware guys to take a look into it.

Have you got any ideas as to code to solve the problem? These boards
work fine under Win XP and 2000 so it looks like CE isn't handling the
stall properly.- Hide quoted text -

- Show quoted text -

It gets through HubStatusChange ok and moves onto AttachDevice where
it fails at the
DEVICE_CONFIG_STATUS_SCHEDULING_GET_DEVICE_DESCRIPTOR_TEST test. So it
knows the device has been plugged in but when it calls GetDescriptor
the control pipe fails with the error code USB_STALL. It looks like
this state isn't being handled correctly and some kind of re-try
should be being done.

Darren



.

Relevant Pages