BCM20736S HIDOFF problem

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
lock attach
Attachments are accessible only for community members.
legic_1490776
Level 5
Level 5
25 likes received 10 likes received First like received

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

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
Moderator
250 sign-ins 25 comments on blog 10 comments on blog

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

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

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?

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

0 Likes

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

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

}

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

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

0 Likes

Thanks Wataru.

0 Likes