My device on the Colibri (WinCE7 BSP 2.1b2) should periodically go to suspend mode and wake up (to save electricity). I wrote a simple test and found that with some effort the device hangs and does not wake up any more.
Here is test
#include <windows.h>
#include <pm.h>
#include <Notify.h>
int _tmain(int argc, _TCHAR* argv[])
{
int Count=0;
while(1)
{
printf("Goto suspend %d ... \r\n", Count);
SYSTEMTIME st;
FILETIME ft;
static CE_USER_NOTIFICATION un = {0};
// add 15 seconds to the current time
GetLocalTime(&st);
SystemTimeToFileTime(&st, &ft);
(*((DWORD64*)&ft)) += 10000000 * 15; // 1 unit = 100ns
FileTimeToSystemTime(&ft, &st);
// setup alarm at least 11sec in the future
HANDLE SleepTimerHandle = CeSetUserNotification(NULL, L"", &st, &un);
if(!SleepTimerHandle)
{
printf("Timer Error \r\n");
return 1;
}
// enter suspend mode
DWORD R = SetSystemPowerState(NULL, POWER_STATE_SUSPEND, POWER_FORCE);
if(R!=ERROR_SUCCESS )
{
printf("Goto suspend error \r\n");
return 3;
}
printf("Wake up %d ... \r\n", Count);
Sleep(3000);
Count++;
}
return 0;
}
Sometimes this happens after 5 minutes, sometimes through 20, sometimes after 60 minutes. With this hang, the screen is black, the interfaces are off. The current consumption is some intermediate - much higher than normal suspend mode, but also significantly lower than in the operating mode.
It looks like some bug in the OS. How can I fix it?
We are able to reproduce the issue on our side. Could you please wait for some days, we will get back you soon.
Could you please share debug log messages, there would be some useful information to debug the issue.
Thank you for your patience. We are able to reproduce the issue. We need some more days to really look into the issue and get a solution.
We would like to know use case of suspend and resume. Also, if possible could you please share which all are T20 peripherals will be used in your product. You can share through support@toradex.com for confidential.
Did you set this wakeup source:
[HKLM\System\PM\Suspend]
"WakeupSources" = "rtc"
We are thinking that the problem with suspend/resume might be connected with some driver not resuming or suspending properly all the time, what we could try is to disable all non-essential drivers and repeat the test audio, usb and ethernet drivers are known to be problematic.
- SDIO card
- 2 USARTs (All COM ports close before suspend)
- Module UC20 (http://www.quectel.com/product/uc20.htm) for GPRS+GPS via USB, PPP connection, drivers from Quectel (all connections close, UC20 power off before suspend)
- Video capture via MAX9526 (video also power off before suspend)
- ~30 GPIO pins for simple digital in/out
- 3 channels ADC
- USB-client for debug.
Screen use only for debug out, without keyboard, mouse, touchscreen.
Ethernet is Off, not use.
Thank you for the details.
When will device go suspend? Is it regular 15 seconds? or Suspend and Resume button? Could you please share more information about suspend and resume use cases?
I apologize for the delay in replying, I was away.
I need this scenario: the device works 500-1500 msec then falls asleep for a fixed time of 15-20 seconds, after which the cycle repeats. The scenario is necessary to reduce the power consumption in the passive mode (the device operates on battery power), in active mode the device works without falling asleep.
We have disabled Audio and Ethernet driver and tried the same test. We are not reproduce the issue. Please import this registry and try at your end and let us know your feedback.
Thank you, the test program is working ok now, I will check with the main program.
But I’m worried about disabling the audio driver, I need to play and record audio. Will the bug be fixed in future versions?
We are narrow down the issue, Ethernet driver is the problem. We are looking into but it might take many weeks to conclude it. So, you can enable the audio driver and try to do the same test and disable only ethernet driver as described here.
