Display xscale

Hi all,
Hardware details
1) xscale board
2) LG philips 6.4" 640 * 480 TFT VGA lcd panel
3) ads 7843 touch panel controller

We have loaded win CE on to the board, everything is fine i can see
the kernel loading in the KITL o/p...and also i see the display on the
LCD, the desktop the icons.everything no distortion, no flickering
nothing. Cool....BUT, the display remains like this for 5 to 6 secs
and then vanishes, it reappears and stays for a few seconds, vanishes
again and this repeats.

I put some break points in the Power manager files, drv.c and saw the
PowerThread calls PmUpdatePowerStatus every few seconds. THis looks
ok, because in power status of the system is not changing, it remains
constant.

Also i noticed that in PmFindState there is a switch case
switch(POWER_STATE(dwFlags)) where i see POWER_STATE_ON,
POWER_STATE_OFF, POWER_STATE_IDLE, POWER_STATE_SUSPEND. But right from
the begining till the kernel loads and all the services starts
running, the code never goes inside this switch case. Could this be
the reason for the problem i am facing.

thanks and regards
prasanna

Steve
Thu Dec 04 07:53:22 CST 2003

Sounds to me like something is flipping the power/enable GPIOs used for your
LCD. You'll have to track that down. I'd recommend putting all GPIO bit
modification in the OAL and protecting it with a critical section to prevent
interference between threads on a read - modify - write cycle.

--
Steve Maillet (eMVP)
Entelechy Consulting
smaillet_AT_EntelechyConsulting_DOT_com

pachu_um
Fri Dec 05 00:16:06 CST 2003

Hi steve,
thanks for the reply. I checked for any other part of the
code changing the LCD GPIO's. But no, nothing like that. By the way i
just want to try once by disabling the PM. I saw that i need to set
BSP_NOPM for this.

I tried doing that in %wince%\platform\xsc1bd\xsc1bd.bat. But still i
could see that the pm.dll was loaded and running.

Or are there other ways to disable the PM. Some registry entries for
instance.

Thanks and regards
prasanna

"Steve Maillet \(eMVP\)" <nospam1@EntelechyConsulting.com> wrote in message news:<e0VKD4muDHA.2520@TK2MSFTNGP10.phx.gbl>...
> Sounds to me like something is flipping the power/enable GPIOs used for your
> LCD. You'll have to track that down. I'd recommend putting all GPIO bit
> modification in the OAL and protecting it with a critical section to prevent
> interference between threads on a read - modify - write cycle.

Yannick
Fri Dec 05 07:49:36 CST 2003

It might be a power issue on your display. Can you check the power signals ?

--
----------------------------------------------------------------
Yannick Chamming's
ADESET
Windows Embedded Manager
ychammings_AT_adeset_DOT_com>
http://www.adeset.com
Tél : +33 (0)4.72.18.57.77
Fax : +33 (0)4.72.18.57.78
----------------------------------------------------------------

"Steve Maillet (eMVP)" <nospam1@EntelechyConsulting.com> wrote in message
news:e0VKD4muDHA.2520@TK2MSFTNGP10.phx.gbl...
> Sounds to me like something is flipping the power/enable GPIOs used for
your
> LCD. You'll have to track that down. I'd recommend putting all GPIO bit
> modification in the OAL and protecting it with a critical section to
prevent
> interference between threads on a read - modify - write cycle.
>
> --
> Steve Maillet (eMVP)
> Entelechy Consulting
> smaillet_AT_EntelechyConsulting_DOT_com
>
>

pachu_um
Fri Dec 05 08:31:24 CST 2003

Hi all,
Say i have to add an entry for some new physical to virtual
mapping in xsc1bd.h, xsc1bd.inc and memmap.inc How do i calculate the
virtual address. For instance below, 0x14000000 is mapped to
0x9f800000. Say like that i need to map 0x17C00000 to a virtual
address, how do i calculate the virtual address.

#define SA1111_BASE_PHYSICAL 0x10000000
#define SA1111_BASE_C_VIRTUAL 0x9F700000
#define SA1111_BASE_U_VIRTUAL(SA1111_BASE_C_VIRTUAL +
CACHED_TO_UNCACHED_OFFSET)


#define XDC_BASE_PHYSICAL 0x14000000
#define XDC_BASE_C_VIRTUAL 0x9F800000
#define XDC_BASE_U_VIRTUAL (XDC_BASE_C_VIRTUAL +
CACHED_TO_UNCACHED_OFFSET)

In the above instance, the difference between 0x14000000 and
0x10000000 is not same their virtual address difference, ie
0x9f700000 and 0x9f800000.

So how to calculate the virtual address.

thanks and regards
prasanna

Steve
Fri Dec 05 08:42:32 CST 2003

There is no mathematical relationship between an actual physical and virtual
address. That depends entirely upon the mapping established in
OEMAddressTable and is entirely arbitrary and dependent on the OEM (Actually
the MS documentation says that the base of RAM is required to be mapped at
0x80000000)

--
Steve Maillet (eMVP)
Entelechy Consulting
smaillet_AT_EntelechyConsulting_DOT_com

pachu_um
Sat Dec 06 01:59:00 CST 2003

Hi folk,

Thanks for the reply guys,

I too felt it must be something related to the power.
The thing is, PowerThread keeps running constantly, and it calls
PmUpdatePowerStatus every now and then. THis is fine. Now if put a
break point, in PmUpdatePowerStatus, and i stop there without stepping
in, then the display stays like that continuously, I can see the
desktop, icons everything.
once i step in and continue, it starts behaving like how i have
mentioned in my previous posts. ie, the display stays for some 2 to 3
secs, disappears and reappears again, this continues till i switch off
the board.

Strange, but i tried printing the previous power state and the current
power state, i seems that there was not change in the power state
atall...

By the way how to handle the backlight in windows ce. could that be a
problem ?

thanks regards
prasanna

"Yannick Chamming's" <ychammings_nospam@adeset.com> wrote in message news:<eOnZiazuDHA.2148@TK2MSFTNGP12.phx.gbl>...
> It might be a power issue on your display. Can you check the power signals ?
>
> --
> ----------------------------------------------------------------
> Yannick Chamming's
> ADESET
> Windows Embedded Manager
> ychammings_AT_adeset_DOT_com>
> http://www.adeset.com
> Tél : +33 (0)4.72.18.57.77
> Fax : +33 (0)4.72.18.57.78
> ----------------------------------------------------------------
>
> "Steve Maillet (eMVP)" <nospam1@EntelechyConsulting.com> wrote in message
> news:e0VKD4muDHA.2520@TK2MSFTNGP10.phx.gbl...
> > Sounds to me like something is flipping the power/enable GPIOs used for
> your
> > LCD. You'll have to track that down. I'd recommend putting all GPIO bit
> > modification in the OAL and protecting it with a critical section to
> prevent
> > interference between threads on a read - modify - write cycle.
> >
> > --
> > Steve Maillet (eMVP)
> > Entelechy Consulting
> > smaillet_AT_EntelechyConsulting_DOT_com
> >
> >

Steve
Sat Dec 06 09:15:10 CST 2003

I think you are chasing a red herring here. When you stop at a breakpoint
the whole system stops so whatever is triggering your display tripping isn't
running - not just the pm thread you broke into. Unless you implemented the
appropriate DrvEscape code handling in the display driver the PM will have
no effect. This still sounds like something is accidentally modifying the
control bits managing the power for the display. If you have a JTAG ICE with
trace capabilities you can possibly use the power signals to the display as
a trigger to stop the trace so that when it gets turned off you can have a
trace of "Who done it"

--
Steve Maillet (eMVP)
Entelechy Consulting
smaillet_AT_EntelechyConsulting_DOT_com

pachu_um
Sun Dec 07 22:48:41 CST 2003

Hello Steve Maillet,
Thanks again, Yeah ICE would have been usefull, but
that is problem, we dont have ICE with us. So debugging at that level
is not possible right now.

Ok i shall try to check out as much as possible. Actually u are right
it has become a red herring chase....:-) :-) :-)

pachu

"Steve Maillet \(eMVP\)" <nospam1@EntelechyConsulting.com> wrote in message news:<#pPhEvAvDHA.640@tk2msftngp13.phx.gbl>...
> I think you are chasing a red herring here. When you stop at a breakpoint
> the whole system stops so whatever is triggering your display tripping isn't
> running - not just the pm thread you broke into. Unless you implemented the
> appropriate DrvEscape code handling in the display driver the PM will have
> no effect. This still sounds like something is accidentally modifying the
> control bits managing the power for the display. If you have a JTAG ICE with
> trace capabilities you can possibly use the power signals to the display as
> a trigger to stop the trace so that when it gets turned off you can have a
> trace of "Who done it"