cancel
Showing results for 
Search instead for 
Did you mean: 

WICED Smart Bluetooth

legic_1490776
Contributor II

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?

1 Solution
legic_1490776
Contributor II

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

}

View solution in original post

11 Replies
MichaelF_56
Moderator
Moderator

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.

santol

legic_1490776
Contributor II

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.

0 Likes
legic_1490776
Contributor II

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?

ArvindS_76
Employee

Yes, it should be maintained. Can you try input and output disabling P33?

0 Likes
legic_1490776
Contributor II

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();

0 Likes
legic_1490776
Contributor II

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

}

View solution in original post

WaSu_1697556
New Contributor II

Hi,

Leaving app_enter_hidoff() and app_abort_hidoff() NOP,  is this requisite or optional?  Is it OK to print some debug trace inside?

0 Likes
MichaelF_56
Moderator
Moderator

Please create a new thread as nobody on the AE team is looking for new questions added to closed/answered threads.

0 Likes
MichaelF_56
Moderator
Moderator

Thanks Wataru.

0 Likes