cancel
Showing results for 
Search instead for 
Did you mean: 

WICED Smart Bluetooth

Contributor II

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?

1 Solution
Employee

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?

View solution in original post

0 Likes
Reply
3 Replies
Contributor II

Maybe it is not actually entering HIDOFF mode.

Under what circumstances will a call to

  bleprofile_PrepareHidOff();

fail to enter HIDOFF?

0 Likes
Reply
Employee

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?

View solution in original post

0 Likes
Reply
Contributor II

Thank you, Shawn.  This was indeed the problem.

0 Likes
Reply