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.
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 */
-1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1
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.
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.
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)
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).
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.
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?
2 of 2 people found this helpful
These are the blecm function to enable/disable advertising:
blecm_setAdvEnable( HCIULP_ADV_MODE_ON );
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.
Thanks... will try and let you know!
1 of 1 people found this helpful
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.