- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
My application invokes HIDoff to go into a deep sleep, and works fine on the BCM20732S.
When I try to enter HIDoff mode, at first it seems to work - the current draw drops to near 0.
But then, about 6 seconds later, the current rises to 2mA and stays there. The chip does not wake up at this point - it still appears to be sleeping, and will wake up later from an interrupt just fine. But it is drawing a lot of power.
I am analyzing this using a power meter that logs the current draw over time.
I've attached screen shots with annotations.
In the first image you can see the device running, then there is a burst of current when it enters HIDoff, and then it is off.
Then, after about 6 seconds, something happens that leaves it running at a fairly high level.
The second image shows a continuation where I then press a button to wake up the device and it indeed wakes up and resumes normal operation.
The identical board design and firmware works fine with the 20732S.
Any ideas?
Solved! Go to Solution.
- Labels:
-
Sleep Modes
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Broadcom support suggested adding the following to the end of the app_create() function. This seems to fix the issue.
===
In application_create(), register for callbacks that are invoked before entering hid-off/deep-sleep (yes, they are the same).
void application_create(void)
{
...... all other initialization here....
bleprofile_regAppEvtHandler(BLECM_APP_EVT_ENTERING_HIDOFF,(BLECM_NO_PARAM_FUNC)app_enter_hidoff);
bleprofile_regAppEvtHandler(BLECM_APP_EVT_ABORTING_HIDOFF,(BLECM_NO_PARAM_FUNC)app_abort_hidoff);
}
Then implement the callbacks as a NOP:
void app_enter_hidoff(void)
{
// Do nothing
}
void app_abort_hidoff(void)
{
// Do nothing
}
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
j.t will be looking into this with the developers next week and will let you know if he is able to determine the root cause.
You may also want to take a look at this thread: BCM20736S Sleep Example Firmware
I know that we found instances where P0 was also triggering HIDOFF and preventing the device from remaining asleep, but I cannot find samples to those threads to reference. I think here, it was beneficial to connect P0 to a pullup if not used.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks, mwf_mmfae,
I was aware of the issue with P0 and in fact we have a pull-up on that line.
I had run into the failure to enter HIDoff for this reason previously, leading us to add the pull-up.
However, this seems to be a different situation because it really DOES enter HIDoff, for 6 seconds.. that is, the processor really is off and current drops to a few microamps for a fairly long time, before getting into this state.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I believe I have tracked down the source of this problem.
My board has a flash chip with an active-low chip select line.
Before entering HIDoff, I make sure to set this line to be high (i.e. to keep the chip off).
It appears that sometime after I enter HIDoff, the line goes low and the flash turns on.
I am using P8 for the chip select.
I am not sure whether other pins behave the same way or not.
This is the code I use to configure and drive the GPIO:
#define __SLAVE1_CS_PORT 0
#define __SLAVE1_CS_PIN 8
// configure flash CS line
gpio_configurePinWithSingleBytePortPinNum(8, GPIO_OUTPUT_ENABLE, 1);
// disable flash CS (active low)
gpio_setPinOutput(__SLAVE1_CS_PORT, __SLAVE1_CS_PIN, 1);
On the 20732S, GPIO state definitely was retained during HIDoff, and I assume it should be on the 20736S as well?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes, it should be maintained. Can you try input and output disabling P33?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I just tried this, but it did not seem to help:
// enter deep sleep
gpio_configurePin(2,1,GPIO_OUTPUT_DISABLE | GPIO_INPUT_DISABLE, 0);
bleapputils_delayUs(500);
bleprofile_PrepareHidOff();
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Broadcom support suggested adding the following to the end of the app_create() function. This seems to fix the issue.
===
In application_create(), register for callbacks that are invoked before entering hid-off/deep-sleep (yes, they are the same).
void application_create(void)
{
...... all other initialization here....
bleprofile_regAppEvtHandler(BLECM_APP_EVT_ENTERING_HIDOFF,(BLECM_NO_PARAM_FUNC)app_enter_hidoff);
bleprofile_regAppEvtHandler(BLECM_APP_EVT_ABORTING_HIDOFF,(BLECM_NO_PARAM_FUNC)app_abort_hidoff);
}
Then implement the callbacks as a NOP:
void app_enter_hidoff(void)
{
// Do nothing
}
void app_abort_hidoff(void)
{
// Do nothing
}
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
Leaving app_enter_hidoff() and app_abort_hidoff() NOP, is this requisite or optional? Is it OK to print some debug trace inside?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Please create a new thread as nobody on the AE team is looking for new questions added to closed/answered threads.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks Wataru.