- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have a custom board design based on the 20732S, which has a button that allows the system to wake up from HIDOFF mode if the button is held down for more than 3 seconds.
My application enters HIDOFF mode and I see a very low power draw (~2 microamps).
When I press the button briefly, the system wakes up, waits about a second, sees that the button is not pressed anymore, prints a BLE trace message, and re-enters HIDOFF mode.
About half the time, the device enters HIDOFF and the current goes down to 2uA again.
The other half of the time, the device still appears to enter HIDOFF mode (it stops operating) but the current draw rises to 3 MILLIamps and stays there permanently. If I press the button again to wake it up, it wakes up just as normal (a normal boot from HIDOFF) and operates as expected.
What could cause this behavior, and is there anything I can do to prevent it?
Could this be caused by some interrupt input occurring at a bad time when trying to go to sleep?
Solved! Go to Solution.
- Tags:
- hidoff
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
There is a key-scan feature that periodically sniffs GPIO:P0. If P0 is detected low, the device assumes a key is pressed. Since further (key-scan) processing would typically get performed next, the attempt to enter HIDOFF is intentionally aborted.
Customers who are power sensitive and desire to enter HIDOFF, may want to only connect a 10K Ohm pullup to GPIO:P0 so key-scan takes no action.
If you have any circuitry attached to P0, please try moving it to another GPIO to test this theory.
Also, you could test at the application level if the HIDOFF request got aborted, by registering for its callback. Please see this forum posting: How to enter HIDOFF? How to detect if the request is not honored?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Maybe it is not actually entering HIDOFF mode.
Under what circumstances will a call to
bleprofile_PrepareHidOff();
fail to enter HIDOFF?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
There is a key-scan feature that periodically sniffs GPIO:P0. If P0 is detected low, the device assumes a key is pressed. Since further (key-scan) processing would typically get performed next, the attempt to enter HIDOFF is intentionally aborted.
Customers who are power sensitive and desire to enter HIDOFF, may want to only connect a 10K Ohm pullup to GPIO:P0 so key-scan takes no action.
If you have any circuitry attached to P0, please try moving it to another GPIO to test this theory.
Also, you could test at the application level if the HIDOFF request got aborted, by registering for its callback. Please see this forum posting: How to enter HIDOFF? How to detect if the request is not honored?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you, Shawn. This was indeed the problem.