Tiny210 WinCE 6.0 Touch not responding

AlexAG
Hi!
I'm trying to work with WinCE 6.0 on a Tiny210 board and encountered this
problem:
Few seconds after booting, touch screen becomes unresponsive - system is
still working, but no touch. If I connect any working device to the USB
(flash drive, keyboard, mouse, etc) - touch screen becomes alive and starts
working normally till this device is connected... As soon as USB device
becomes disconnected - everything starts from the beginning, few seconds
and touch goes away.
Also, when touch screen is unresponsive - ADC doesn't work too. I've tried
to launch AdcDemo application and when touch screen becomes unresponsive,
all ADC values changing are ignored (old value is being shown in AdcDemo)
until any USB device will be connected.

Is there any way to solve this issue without any USB device?

AlexAG
Update: Removing all USB packages from the WinCE image solves the problem -
without them touch screen works perfectly.

TheRegnirps
This also affects Activesync. Apparently the USB section of the BSP
supplied by Samsung is a mess. I talked to them yesterday and the
FriendlyARM engineers are working on this now.

AlexAG
Anyway, I don't need USB in my project, so this solution allows me to
continue development. If you'll get some way to solve this issue other way
- please, post it here.

Duong
Thank for your Solve,that's is useful experience!

Ozmik
Hi All,

I've done a lot of work on Tiny210 OS build and App building and this
problem is still outstanding & very frustrating.

There’s more to this bug, it’s not the touch going to sleep, it’s the
device going to sleep as the screen stops updating until a USB key or mouse
or keyboard etc. is plugged into the USB hub. You can prove this to
yourself by writing a small App with something that changes on the screen,
like a time clock etc. or toggle the module LEDs. It stops updating, so the
OS goes to sleep. Touching the screen does not wake it up.

The problem relates to the USB hub chip, U11 on the SDK (TinySDK2-1148).
This problem does not occur on SDK V1.0 PCBs as there is no hub on that
PCB. However, if you plug in an external USB hub with no devices on it, the
problem will come back.

The symptom is that with no USB devices connected to a hub (but hub still
connected to the 210 module), the display stops several seconds after boot.

Plug USB device in and she comes alive.

Here's a silly work around for those in this boat:

Remove Resistors R76 & R77. Desolder resistors R110 & R112 but slide them
towards the USB socket "HOST3" so that you can solder some hookup wire to
the ends of the unsoldered resistors. Jumper from the pads nearest the USB
Xtal Y3 over to the resistors R110 & R112 that you moved and this will
bypass the USB hub altogether (keeping the 22R res in series) and presto,
the unit will not go to sleep, even if the single USB is disconnected.

Active stink (pardon the expression) still works with this mod.

This is NOT a permanent fix if you need a hub in circuit, but at least it
gets your SDK running again.

The problem will most likely be deep in the USB code that sends the module
to sleep when the hub tells the OS that it has no devices and possibly goes
into a low power state as per the USB spec.

Enjoy, hope this helps some of you.

Michael.
"from down under"

Reggie
Just to add some more fuel to this fire, I'm seeing other issues with the
usb and the 3.0.8 kernel on ubuntu for the mini210S.

USB and touchscreen are all fine for the first cold boot but if you do a
warm reboot, the USB fails to enumerate correctly, it looks like the
echi/ohci system initialises itself but doesn't find my usb hub or
individual items(mouse/keyboard) that I have plugged in.  The only way to
get my hub/devices to show up again is to either power off and on again, or
reboot and just hit the reset button to do a real power cycle.

I suspect it is probably unrelated but thought it worth mentioning.

TheRegnirps
The latest from FriendlyARM is that they have not been able to fix this. It
is somewhere deep in the BSP code supplied by Samsung. Their only solution
at this point is to remove the USB controller chip so that the driver is
never loaded.