Check if currently advertising

Question

In my application, a host co-processor controls when to start/stop advertising, connect etc.
 I've noticed that soft-device command are state-dependent, e.g. calling ble_advertising_start() while advertising, or calling sd_ble_gap_adv_stop() while not, causes an SD assert which by default soft-resets the device (related question here ). 
 How should I mitigate this? Do I have to keep track of the stack's state (Advertising, Connected, Scanning, etc.), or, better yet, are there API methods to check the state of the stack before issuing a command? 
 Version: nRF5 SDK 11.0.0, s132, with PCA10040 EVB

Ulrich Myhre · Accepted Answer

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.

Chandi · Answer

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.

Check if currently advertising

Top Replies