Advertisements do not resume after RF is paused using bleprofile_configureGpioForSkippingRf()

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

cross mob
Anonymous
Not applicable

Using the mybeacon sample application as a reference, we designed our BCM20736 based hardware to use P0 as the input to pause RF.

Our GPIO0 settings in platform.h are identical to the tag boards:

#define GPIO_PIN_RADIO_OFF      0

#define GPIO_SETTINGS_RADIO_OFF (GPIO_INPUT | GPIO_INIT_LOW | GPIO_BUTTON | GPIO_INT)

And our application's create() function calls:

bleprofile_configureGpioForSkippingRf(GPIO_PIN_P0, GPIO_PIN_INPUT_HIGH);

However, when we drive GPIO0 high, the advertisements stop and do not resume when we drive it back low. I am wondering that the application may have crashed.

The one difference from mybeacon is that our application uses bleprofile_Discoverable() to control advertisements, not blecm_startAdv().

Is there another way to pause RF using the GPIO that I must use if I use this API?

I am using SDK v2.2.2

Thanks

0 Likes
1 Solution
Anonymous
Not applicable

There was a hardware issue with our design which was causing this not to work. With the fix in place RF is inhibited correctly.

We have since moved to a different approach so I did not test exhaustively.

View solution in original post

11 Replies
JacobT_81
Employee
Employee
250 replies posted 100 replies posted 50 replies posted

What type of application have you built around this feature? This feature is not recommended for connectable devices, but rather beacons. If you cease RF in the middle of a connection you'll destabilize the system.

There shouldn't be any need to configure the pin before passing it as a parameter, the function takes care of the configuration. You should remove the configuration code just to be safe--no need to set it up as an interrupt.

Jacob

0 Likes
Anonymous
Not applicable

Thanks for your prompt response.

The device is intended primarily as a beacon. I understand the concern about ceasing RF in the middle of a connection.

I am not sure what you mean by no need to configure the pin... I am on a custom board and we have created our own version of platform.h which reflects the way we have connected the GPIOs.

In my application I have:

const BLE_PROFILE_GPIO_CFG beacon_gpio_cfg =

{

    {

        GPIO_PIN_RADIO_OFF,        /* BT Radio off */

        GPIO_PIN_WP,              /* NVRAM write protect */

        GPIO_PIN_TP123,

        GPIO_PIN_TP117,

        GPIO_PIN_TP118,

        -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1

    },

    /*.gpio_flag =*/

    {

        GPIO_SETTINGS_RADIO_OFF,

        GPIO_SETTINGS_WP,

        GPIO_SETTINGS_TP123,

        GPIO_SETTINGS_TP117,

        GPIO_SETTINGS_TP118,

        0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0

    }

};

which I 'register' in my call:

    bleapp_set_cfg( (UINT8 *)beacon_gatt_database,/* GATT Database */

                    sizeof(beacon_gatt_database),   /* GATT Database size */

                    (void *)&beacon_cfg,/* BLE Profile Configuration */

                    (void *)&beacon_puart_cfg,      /* PUART Configuration */

                    (void*)&beacon_gpio_cfg,    /* GPIO Configuration */
                    beacon_create              /* App Create function */

                  );

Should I not be doing so?

I will try your suggestion to not set the pin up as interrupt.

Thanks!

0 Likes

Yeah, just to be safe remove it from that configuration macro.

When you call the API it configures it an input and polls it--no interrupt.

It's dangerous to configure as an interrupt in that macro because that macro actually sets up it's own callback behind the scenes and executes code. Even though the GPIO config is overwritten in the meantime, not worth the risk that that the callback is somehow getting called.

I'll look into whether the different advertising APIs are affecting anything.

Jacob

0 Likes
Anonymous
Not applicable

Changing the definition to not set up the pin as interrupt did not help

#define GPIO_PIN_RADIO_OFF      0

#define GPIO_SETTINGS_RADIO_OFF (GPIO_INPUT | GPIO_INIT_LOW | GPIO_BUTTON)

0 Likes

bleprofile_Discoverable calls blecm_startAdv internally. The only real difference is that bleprofile_Discoverable sets up timers to kill the advertising after the user specified amount of time.

Given, that you're developing a beacon and advertisements should never turn off, you're safe to use the blecm_startAdv directly like mybeacon does. It's going to be a more stable solution when paired with the button/GPIO solution you want.

If you're still unable to use the bleprofile_configureGpioForSkippingRf API, one reasonable way to implement this same thing would be to register a GPIO as an interrupt, and in it's callback control advertising via calls to bleprofile_Discoverable(NO_DISCOVERABLE, NULL) and bleprofile_Discoverable(HIGH_UNDIRECTED_DISCOVERABLE, remote_addr).

Jacob

0 Likes
Anonymous
Not applicable

Thanks for the detailed explanation. I will try reverting to blecm_startAdv and see if that helps. Is there no blecm_ API to suspend or stop advertisements?

0 Likes

Hi okhwaja​,

These are the blecm function to enable/disable advertising:

blecm_setAdvEnable( HCIULP_ADV_MODE_ON );

blecm_setAdvEnable(HCIULP_ADV_MODE_OFF);

Under the surface they don't do anything different than the bleprofile_Discoverable functions. You simply take control away from any timers on the advertisement duration you may have set in your configuration macros.

Jacob

Anonymous
Not applicable

Thanks... will try and let you know!

0 Likes
Anonymous
Not applicable

There was a hardware issue with our design which was causing this not to work. With the fix in place RF is inhibited correctly.

We have since moved to a different approach so I did not test exhaustively.

MichaelF_56
Moderator
Moderator
Moderator
250 sign-ins 25 comments on blog 10 comments on blog

Make sure you understand the limitations of P0 in certain scenarios: How does P0 and keyscan affect deep sleep?

Anonymous
Not applicable

Thanks for the pointer. We are integrating the chip into a powered device and have sleep completely disabled so I think this will not be an issue.

0 Likes