Re: SystemPowerState messed up after reboot ...



There is not such thing as "user space" in a Pocket PC device, so your
theory is flawed from the start.

This may be a platform-specific issue, but since you've decided to
explicitly not check other platforms you have no way of knowing if the issue
lies in your code or the platform code.


--

Chris Tacke, Embedded MVP
OpenNETCF Consulting
Giving back to the embedded community
http://community.OpenNETCF.com


<leobone@xxxxxxxxx> wrote in message
news:33f3375a-bc70-4ddd-92ca-070abc647cf3@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Hi, thanks to everyone who responded.

Just to sum up, i finally refrain from resetting the PPC.
Obviously there is no safe way to reset the device from user space, at
least on the platform in question.
Software resets from user space are causing arbitary system
instabilitys afterwards, quite the opposite of the intended effect.
Also SetSystemPowerState() seems not very safe to be used by user
space applications at least for suspending and resetting.
GwesPowerOff() for suspend is my choice.

ciao larry





On May 17, 8:06 pm, leob...@xxxxxxxxx wrote:
The more I look, the more i think the problem could be caused by not
properly acting upon the notification event when the device is waking
up.
The reset works fine as long the device wasn't suspended. Though when
the device wakes up, no matter if it was suspended via the powerbutton
or a call to GwesPowerOff(),
I run in those problems.

Can someone point me maybe to resources that illustrate how to
properly act upon a notification while the system is resuming from
suspend. So far i thought once the notification system triggers my
event everything is up and running and i am free to go and do what i
need to do.
But maybe there are some steps that are required to be done by me. Are
there any guidelines to that procedure.

tx larry

On May 17, 6:20 pm, leob...@xxxxxxxxx wrote:

Hi Chris,

If you mean other Device but same model, yes.
If you mean differrent Model or OEM, no i haven't.
Since I need it to get working on this hardware, it would not help me
much to know
that it is working on some other device. It would only proof my fear
that it is a bug in the OEM's OS implementation.
I then still need to find a workaround.

tx larry

On May 17, 5:56 pm, "Chris Tacke, eMVP" <ctacke.at.opennetcf.dot.com>
wrote:

Have you tried this on any other hardware as a sanity check?

--

Chris Tacke, Embedded MVP
OpenNETCF Consulting
Giving back to the embedded communityhttp://community.OpenNETCF.com

<leob...@xxxxxxxxx> wrote in message

news:c14a819c-44f3-4063-9abd-7abab02fd7ab@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Hi Bruce,

actually i tried many,many thinkable and unthinkable combinations and
approches.
Also the two that you describe on your blog.
To confirm if i hadn't done somthing wrong i tried

SetCleanRebootFlag();
KernelIoControl(IOCTL_HAL_REBOOT, NULL, 0, NULL, 0, NULL);

again. Well it does not change anything. Actually for the moment i
believe using the in the registry defined OEM PowerState "ColdReboot"
to
be working the most reliable. Using any other method even
ExitWindowsEx causes the notification system not to trigger any
CNT_TIME events after the reboot. At least if
i am using CNT_TIME notifications with named events. But thats
another issue.

In my investigations i found that when the system wakes up, right
after the call to GwesPowerOff(), if i was to put the system straight
into "on"-state the call would either
take about 5-6 seconds and really put the device into "on"-state,
everything how it should be, or would only take ~50ms, report
success, and if you call GetSystemPowerState also report "on" BUT the
PPC
would still be in some unknown state, screen still turned off and
such. It all looks that there are moments while resuming the
PowerManager seems to think the device is full on while it is not. If
in that situation i do a reset,
next reboot everything is quer. Therefore the idea with the second
suspend, wich was a wild guess but actually causes the PowerManger to
get back on track. Only that it has sideffects wich are not
feasible.
I also tried many different versions of how to suspend the device,
from VK_OFF , PPN_POWER_BUTTON_PRESSED, PowerOffSystem(),
SetSystemPowerState(NULL,POWER_STATE_SUSPEND,NULL) the described
symptoms
stay the same.

So maybe there are some restrictions to those apis that i am not aware
of, as i say i have no more ideas.

tx larry

On May 17, 4:33 pm, leob...@xxxxxxxxx wrote:

The reset I do via

SetSystemPowerState(NULL,POWER_STATE_RESET,NULL);

when I handle the wakeup event.

On May 17, 4:21 pm, "Bruce Eitman [eMVP]"

<bruce.eitman.nos...@xxxxxxxxxxxxxxxxxxx> wrote:
How are your rebooting the system? The code you show, doesn't do
that.
What you show is asuspendfollowed by asuspend.

Take a look
at:http://geekswithblogs.net/BruceEitman/archive/2008/11/25/windows-ce-r...

--
Bruce Eitman (eMVP)
Senior Engineer
Bruce.Eitman AT EuroTech DOT com
My BLOGhttp://geekswithblogs.net/bruceeitman

EuroTech Inc.www.EuroTech.com

<leob...@xxxxxxxxx> wrote in message

news:297d0e14-4397-40c4-b088-638cd5858e8a@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Hi everyone, as a last resort i got to ask this here.

I am working on an at first sight trival looking application.
All it
has to do, put the PPC at a certain time to sleep and at
antother
certain time wake it up and reboot the system.

It uses SetUserNotificationEx and a named event to accomplish
that.
Now there is one big mystery which i can't get resolved.

After the reset wich is done via SetSystemPowerState the system
boots
very often into a state where all kinds of devices seem to be in
a
wrong power state and do not work any more.
False battery values, no working gps reciver and such. If the
PPC is
in such state and you put it intosuspend, the screen goes blank
but
the backlight stays on and keeps flickering.

I tracked the problem down so far that this depends on the state
of
PPC when i issue the reset. It seems some other party, like
repllog.exe, puts the device in some "magic" state and if i
issue the
reset while beeing in that "magic" state this happens. The big
problem
is i can't know if the device is in that "magic" state.
GetSystemPowerState reports normal states like on,unattended or
resuming.

The only "close to a solution" thing i found working was to have
code
like this.

----- snipp ---

GwesPowerOff(); //turn the device off

// as soon as the PPC wakes up again and the thread starts
running
//this call,strangly enough, seems to make the PowerManager to
get
it's things kinda right
//it wontsuspendthe device!
SetSystemPowerState(NULL,POWER_STATE_SUSPEND,NULL); //

//wait for my event
WaitForSingleObject(hEvt,INFINITE);

---- snip -----

"close to a solution" because this hack breaks other things.

Important to point out is, that the hardware reset button always
reboots the system into a sane state. All I am wondering is, if
i can
achive the same thing via software.

This is happening on aHPiPAQrx5720 WindowsMobile 5.0

Any ideas or information about when and how to savely reset a
PPC is
greatly appreciated.

larry



.


Loading