Check if currently advertising

RE: Check if currently advertising

Chandi — Sat, 14 Nov 2020 11:12:17 GMT

As a simplified method, at the first advertising instance, I would start a one-shot timer with a timeout value equal to advertising duration (APP_ADV_DURATION) and check if timer expired before issuing subsequent ble_advertising_start(). If timer not expired, sd_ble_gap_adv_stop() can be issued.

RE: Check if currently advertising

Oleg Z — Fri, 12 Jun 2020 16:33:55 GMT

4. BLE_GAP_EVT_ADV_SET_TERMINATED is fired. Then advertising is stopped. You can also be more specific and take different actions regarding the reason for the event (p_ble_evt->evt.gap_evt.params.adv_set_terminated.reason)

for some odd reason BLE_GAP_EVT_TIMEOUT is never fired for me on the advertising timeout.

RE: Check if currently advertising

Ulrich Myhre — Thu, 26 May 2016 20:11:40 GMT

If the advertising stops, and you have not yet pulled the event stating this, then I think you should be safe. I'm not 100% sure on the internals, but as far as I know, all states are "pending" until you pull them with sd_ble_evt_get(). From then on, the stack assumes that you have dealt with the consequences of the event.

I'm not well-wersed in the current SDK, so someone should correct me - but I think the correct way is to simply make an

if ((err_code != NRF_SUCCESS) && (err_code != NRF_ERROR_INVALID_STATE)
{
    APP_ERROR_CHECK(err_code);
}

RE: Check if currently advertising

Boaz — Wed, 25 May 2016 14:31:24 GMT

Thanks. Am I right to say that first option (using a volatile the flag) does not solve the race condition? Come to think of it, you will always have race conditions in a communication protocol, e.g. you call disconnect() at the exact same moment as your peer disconnects. The device must not reset in these situations.

I'm opting for the second option, and be tolerant to 'Invalid State' errors, hence:

Do you see any problems with this approach I might have missed?
What is the correct way to ignore the NRF_ERROR_INVALID_STATE code? Should I override app_error_fault_handler()?

RE: Check if currently advertising

Ulrich Myhre — Wed, 25 May 2016 14:08:03 GMT

The safe way is to create a (possibly volatile) flag like is_advertising, which is set to true whenever adv_start() returns NRF_SUCCESS, and set to false when any of the three conditions above are hit. Never call adv_stop() unless the flag is true, and adv_start() unless it is false. The easier way is to simply handle or ignore the NRF_ERROR_INVALID_STATE return code, accepting that you do not really keep track of the state yourself.

What I meant about race conditions is in the hypothetical case where you had a function to retrieve state. Then you could look at the state, see that it is advertising, then call adv_stop(). If advertising stops by itself between the two last steps, you would have the same problem as now. There are no such problems in the current implementation, unless you are changing your own application states in higher interrupt levels.

RE: Check if currently advertising

Boaz — Wed, 25 May 2016 13:07:23 GMT

Thanks Ulrich. Some thoughts:

Can you please suggest a safe way to stop advertising in case: 1) Advertising timeout is finite 2) Advertising is forever?
You mentioned race conditions. Assuming I only call SD methods from the main thread, will using the application scheduler and SOFTDEVICE_HANDLER_APPSH_INIT mitigate those?

RE: Check if currently advertising

Ulrich Myhre — Wed, 25 May 2016 11:52:28 GMT

Hi,

First I want to mention that it is not the SD that asserts. It simply returns an error code. The APP_ERROR_CHECK macro is the one that will reset the device, unless you choose to handle it in a different way. You can call any API functions with any parameter, at any time, and as long as you do not lie about the length of any buffers you provide, the SD shall never assert or crash. The functions will return an error code stating what happened.

And for your question, you are right in your assumption that you have to remember the state in your application. If sd_ble_gap_adv_start() returns NRF_SUCCESS, the device will advertise until

BLE_GAP_EVT_CONNECTED event is received, i.e. a connection is made (in the case of connectable advertisement). If you are trying to use the central to connect at the same time, you need to check the role flag of the connection. If BLE_GAP_ROLE_PERIPH, you are no longer advertising.
BLE_GAP_EVT_TIMEOUT event is received (in the case where you set a timeout, or use high duty-cycle directed advertisements) and the src field is BLE_GAP_TIMEOUT_SRC_ADVERTISING.
sd_ble_gap_adv_stop() has been called.

There are no commands to check the current state, and it would be prone to race conditions if we had one. Instead, our stack relies on application events to tell you when the internal state changes.