Diagnosing Idle Mode Problems (Windows CE 5.0)
Problems with idle mode can be caused by one of the following reasons:
- OEMIdle is not being called.
- OEMIdle is being called, but is not putting the CPU and peripherals in idle mode.
First determine if OEMIdle is being called. You can do this by setting a breakpoint in OEMIdle and verifying that it causes execution to stop, or by having the OEMIdle implementation output a debug message.
OEMIdle is not being called
The most common cause of OEMIdle not being called is a thread that runs in a loop and never sleeps. The performance of the target device can be satisfactory even in this case, if the thread is running at a low priority level. You can determine which thread is not sleeping by:
- Using the debugger to stop execution and examining the state of all threads. Then examine the call stacks of threads that have high CPU usage to determine what these threads are doing.
- Running the Platform Builder Target Control gi delta command twice in short succession. The first time you run this command, it prints the CPU time of each thread and then resets the CPU time to zero. The second time you run the command, you can examine its CPU usage output to determine which threads are running and preventing OEMIdle from being called. For more information about gi delta, see Target Control Debugging Commands.
OEMIdle is being called, the CPU is entering idle mode, but power usage is still high
If OEMIdle is being called and the CPU is transitioning between idle and active modes, but power consumption is still high, verify the following:
- The frequency at which the CPU becomes active is not higher than expected. Also verify that the CPU is becoming active due to an expected interrupt or software polling requirement, not for some other, unknown, reason. If this is not the case, use the Platform Builder debugger and call profiler functionality to determine why the CPU is active more than you expect.
- The amount of power used in both idle and active modes is not higher than expected. If the power usage is higher than expected, review the source code and use the debugger to determine if the CPU is actually entering the expected sleep mode, and that peripherals are actually powered down as expected.
If the target device's CPU is active too often, or the target device stays active for too long, you can use CeLogData and the call profiler to determine which code is running when the target device transitions out of idle. Specifically, you can use the event tracking functionality to determine which threads are running, how much time each thread takes, and how the threads interact. After you locate the issue, use the debugger to step through the code and understand the source of the issue.
See Also
Battery Life Debugging Techniques | Debugging and Testing | CeLog Event Logging Reference | Implementing a Custom Event Tracking Library | Remote Call Profiler | Remote Kernel Tracker
Send Feedback on this topic to the authors