How can I wake BCM20737S up by using GPIO interrupt?

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

cross mob
Anonymous
Not applicable

I saw the following thread, but I couldn't wake BCM20737S up from DEEP SLEEP mode.

How can I make bcm20732s sleep and wake it up by GPIO interrupt?

Are there any mistakes in my code? Please tell me what to do.

I imitated the code of i2c_temperature_sensor sample and added following code in create function.

**************************************************************************************************************************************************

{

     devlpm_init();

     devlpm_enableWakeFrom(DEV_LPM_WAKE_SOURCE_GPIO);

    gpio_registerForInterrupt(interrupt_handler_mask, abc_gpio_interrupt_handler, NULL);

    gpio_configurePin(GPIO_DS_INT_PIN/16, GPIO_DS_INT_PIN%16, GPIO_EN_INT_RISING_EDGE | GPIO_PULL_DOWN, GPIO_PIN_OUTPUT_LOW);

}

**************************************************************************************************************************************************

Then, I implemented abc_gpio_interrupt_hndler function.I want BCM20737S to advertise again just like before it enters deep sleep mode when GPIO_DS_INT_PIN(P4) rises up.

**************************************************************************************************************************************************

void abc_gpio_interrupt_handler(void* parameter, UINT8 arg)

{

    ble_trace0("Wake up!\n");

    gpio_clearPinInterruptStatus(GPIO_DS_INT_PIN/16, GPIO_DS_INT_PIN%16);

// If disconnection was caused by the peer, start low advertisements

    bleprofile_Discoverable(HIGH_UNDIRECTED_DISCOVERABLE, NULL);

}

****************************************************************************************************************************************************

1 Solution

I just solved this problem with deep sleep and having the device wake up by a GPIO interrupt using the BCM20737S.

The trick was to unplug the USB connection from the device.   With USB connected, the device would go to deep sleep and never wake up.  With USB disconnected, the device woke up from a GPIO interrupt.  The problem however with not using USB is that I cannot see any tracing.

I hope this helps.

View solution in original post

16 Replies
Anonymous
Not applicable

Thank you for your response and teaching me these threads, boont .

However, I have not been able to resolve my problem.

I can't wake my board up by interruption using GPIO(P4).

Please point out any errors to my code.

#define GPIO_DS_INT_PIN 4

In create function:

{

     UINT16 interrupt_handler_mask[3] = {(1 << GPIO_DS_INT_PIN),0,0};

     devlpm_init();

     devlpm_enableWakeFrom(DEV_LPM_WAKE_SOURCE_GPIO);

    gpio_registerForInterrupt(interrupt_handler_mask, info_float_gpio_interrupt_handler, NULL);

   

     gpio_configurePin(GPIO_DS_INT_PIN/16, GPIO_DS_INT_PIN%16,

    GPIO_EN_INT_RISING_EDGE | GPIO_PULL_DOWN | GPIO_INPUT_ENABLE, GPIO_PIN_OUTPUT_LOW);

   

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

}

In application_timer_1s function:

{

     UINT16 interrupt_handler_mask[3] = {(1 << GPIO_DS_INT_PIN), 0, 0};

     devlpm_init();

     devlpm_enableWakeFrom(DEV_LPM_WAKE_SOURCE_GPIO);

    gpio_registerForInterrupt(interrupt_handler_mask, application_gpio_interrupt_handler, NULL);

    devLpmConfig.disconnectedLowPowerMode = DEV_LPM_DISC_LOW_POWER_MODES_HID_OFF;

    gpio_configurePin(GPIO_DS_INT_PIN/16, GPIO_DS_INT_PIN%16, GPIO_EN_INT_RISING_EDGE | GPIO_PULL_DOWN | GPIO_INPUT_ENABLE, GPIO_PIN_OUTPUT_LOW);

    devlpm_enterLowPowerMode();

}

void application_gpio_interrupt_handler(void* parameter, UINT8 arg)

{

     gpio_configurePin(GPIO_PIN_B_LED/16, GPIO_PIN_B_LED%16, GPIO_OUTPUT_ENABLE, 0);

     gpio_setPinOutput(GPIO_PIN_B_LED/16, GPIO_PIN_B_LED%16, 0);

}

When I let my application enter Deep Sleep mode, the state of pins are retained.

So, LED keeps emitting during Deep Sleep mode (When LED pins is low, LED emits).

However, although I make P4 HIGH after I confirm that P4 is LOW, GPIO_PIN_B_LED(for blue LED) doesn't emit.

Of cause, GPIO_PIN_B_LED works correctly in active mode.

Sincerely

0 Likes

You may want to add some tracing to see where could be the issue.

For example, add the following line just before "devlpm_init();":

ble_trace0("Call devlpm_init and Config GPIO Wakeup\n");

Add the following line to just before you enter deep sleep (bleprofile_PrepareHidOff())

ble_trace0("Entering DeepSleep \n");

Btw, P0 is the default in platform.h and you are using P4.

The below thread discussed the state of the GPIO after entering deep sleep. You may want to try out the callbacks in your case.

GPIO state in deep sleep

0 Likes
Anonymous
Not applicable

Thank you for your response, boont.

>You may want to add some tracing to see where could be the issue.

Sure. I have already checked my code by using bletracen etc.

>Add the following line to just before you enter deep sleep (bleprofile_PrepareHidOff())

ble_trace0("Entering DeepSleep \n");

I have already done this.This ble_trace function was called properly.

I cannot find any problems when devlpm_enterLowPowerMode(); is called.

Then, I have already checked this thread (GPIO state in deep sleep) and

the states of pins are held properly after my board enters Deep sleep mode.

I checked the states of pins by using a tester.

>Btw, P0 is the default in platform.h and you are using P4.

Yes. I want to use P4 to wake up from Deep sleep but the interruption of both P0 and P4 work correctly in active mode.

P0 interruption calls application_interrupt_handler which is generated automatically by WICED Smart.

P4 interruption calls  application_gpio_interrupt_handler which is a self-made function and registered as the second parameter of gpio_registerForInterrupt. 

The both interruptions work correctly in active mode.

However, in deep sleep mode, they does not work.

In short, in deep sleep mode, void application_gpio_interrupt_handler(void* parameter, UINT8 arg)

is not called but in active mode.

Are there any mistakes in settings before board enters Deep sleep mode?

If there are some mistakes in my English, I apologize.

0 Likes

Register for the entering/aborting hid-off/deep-sleep callbacks and return without doing anything in these callbacks. From SDK 2.2.x, wiced_sense sample code:

void app_create(void)

{

.....

    bleprofile_regAppEvtHandler(BLECM_APP_EVT_ENTERING_HIDOFF,(BLECM_NO_PARAM_FUNC)wiced_sense_enter_hidoff);

    bleprofile_regAppEvtHandler(BLECM_APP_EVT_ABORTING_HIDOFF,(BLECM_NO_PARAM_FUNC)wiced_sense_abort_hidoff);

...

}

void wiced_sense_enter_hidoff(void)

{

  // Do nothing

}

void wiced_sense_abort_hidoff(void)

{

  // Do nothing

}

0 Likes
Anonymous
Not applicable

Thank you for your response, arvinds.

I have already those codes.

By reading this thread (GPIO state in deep sleep) and adding those coeds,

I could get to hold the state of GPIO in Deep Sleep mode but I have not been able to wake my board up from Deep Sleep.

Which function is called when GPIO interruption is detecteds?

What is the relationship between wiced_sense_abort_hidoff(void) and application_gpio_interrupt_handle(void* parameter, UINT8 arg) called in gpio_registerForInterrupt?

0 Likes

Let's take a step back. What is your test environment? Are you verifying your code on the tag3 or your own board? If it's your own board, have you verify with the ref applications in the sdk, eg hello-sensor?

0 Likes
Anonymous
Not applicable

Thank you for your kindness, boont.

>What is your test environment? Are you verifying your code on the tag3 or your own board?f it's your own board, have you verify with the ref applications in the sdk, eg hello-sensor?

I'm using my own board.

I confirmed that hart_rate_monitor and hello_sensor sample work properly in my own board.

My environment is like following:

OS:Window7 64bit

SDK: WICED-Smart-SDK-2.2.0

BOARD: my own board

0 Likes
Anonymous
Not applicable

To add to this thread, I'm trying to do the same thing (wake BCM20737S) from deep sleep via GPIO/button-press.  To keep things on a known platform, I'm using the WICED Sense kit running the wiced_sense app in SDK 2.2 (with the crystal warm-up fix).  Out of the box, this app will go to deep sleep on its own and will not wake up, neither by timer or by GPIO interrupt - I don't think it's ever worked correctly.

I don't believe the lack of a pullup on P0 on the WICED Sense board is an issue with this; that issue is supposed to *prevent* HIDOFF but that isn't what I'm seeing.

Changing this made no difference:

    // Configure the wake time in mS.
   devLpmConfig.wakeFromHidoffInMs = 7200; //72000000;

Changing this made no difference:

    //devLpmConfig.wakeFromHidoffRefClk = HID_OFF_TIMED_WAKE_CLK_SRC_128KHZ;
   devlpm_enableWakeFrom(DEV_LPM_WAKE_SOURCE_GPIO);

Adding this code made no difference (although it did successfully trigger an interrupt via P4 button push prior to entering HIDOFF):

gpio_configurePin(GPIO_PIN_P4 / 16, GPIO_PIN_P4 % 16, GPIO_EN_INT_RISING_EDGE, GPIO_PIN_INPUT_LOW);

I'm not sure if this is the cause but in digging into this, despite the numerous posts on the matter, there doesn't seem to be a clear HOWTO or document describing how to select between internal and external 32K oscillators while in sleep.  In particular, in bleapp.h, what are the exact definitions of the following code:

enum

{

    LPO_CLK_INTERNAL,   

    LPO_CLK_EXTERNAL,

    LPO_CLK_CRYSTAL,

    LPO_NO_SELECTED,

    LPO_32KHZ_OSC,

    LPO_MIA_LPO

};

These are used by the following function in bleapputils.h, again which isn't clearly documented:

/// Change the current LPO source to use in sleep. Internal, not for application use.

void bleapputils_changeLPOSource(UINT8 pmu_clkSrc, BOOLEAN selSlaveLPOSrc, UINT16 driftRate);

0 Likes
Anonymous
Not applicable


>Out of the box, this app will go to deep sleep on its own and will not wake up, neither by timer or by GPIO interrupt - I don't think it's ever worked correctly.


Oh....

Is there anyone who can solve this problem?

If waking up by GPIO interruption doesn't work, I'm at a loss.

As for me, there is no clue to solve this problem....


Could anyone show us the simple program which can wake up by GPIO interruption?



0 Likes
Anonymous
Not applicable

I have some applications using deep sleep.

But it takes some time to remove unnecessary(or confidential) code.

If you can wait for a while, I'm trying providing it to you late next week.

0 Likes
Anonymous
Not applicable

Thank you for your heartful support, dmiya.

>If you can wait for a while, I'm trying providing it to you late next week.

I can wait. I have no one to depend on, except you in this problem now.

Best regards.

0 Likes

I just solved this problem with deep sleep and having the device wake up by a GPIO interrupt using the BCM20737S.

The trick was to unplug the USB connection from the device.   With USB connected, the device would go to deep sleep and never wake up.  With USB disconnected, the device woke up from a GPIO interrupt.  The problem however with not using USB is that I cannot see any tracing.

I hope this helps.

Excellent !  Thanks for sharing bcarey

gell - could you try this and see if it helps ?

0 Likes
Anonymous
Not applicable

Thank you so much, bcarey!

I could solve this problem with USB disconnected!! I didn't notice the effect of USB to board.


bcarey and mwf_mmfae - By any chance, are there any other functions affected by USB? Do you know?

If your answer is yes, please let me and other users know about all functions as far as you know in other threads.

Anyway, thank you, bcarey!!

0 Likes

gell bcarey d-yama andrew997

Here's the explanation for why unplugging the USB allows the device to appear to come out of Deep Sleep, when really something completely different occurs..

Essentially, when coming out of Deep Sleep, or HIDOFF, the device reboots. When rebooting, the firmware knows to look at the HCI Rx line to see if its high, or if there is an external host attached.  When the USB cable is attached, the HCI UART Rx line is indeed high by design (handled by the FTDI bridge chip).

Therefore, when plugged into USB, the firmware senses this HCI Rx high state, it puts the part into programming mode (or HCI mode as it is sometimes referred to in the documentation).

So while it is not technically in Deep Sleep anymore, it appears that way.  In reality, the part is in programming mode.

Unplugging the USB cable removes the external high signal on HCI Rx, hence when the part reboots coming out of deep sleep as directed by the application, it never goes into programming mode.

0 Likes