SD shutdown & Gatt Queue & Discovery

[Shockel]

Hello ! I have a few questions related to shutting down (disabling) the soft device, and the effects on the gatt queue and discovery:

Question 1: The gatt queue module performs a lot of actions in the background and I haven't quite figured it all out.  If the soft device is disabled, does that automatically clear the gatt queue ? Should it ? And how would I go about it if I "manually" wanted to do so ?

Question 2: The example project ble_app_gzll shows some steps to perform when shutting down the soft device, and what to do when you re-enable it. For example, it shows that you don't want to re-initiablize nrf_ble_qwr_init(), while other init()'s you do. But other examples use quite a few more modules/services. Can you advise what to do with the following:

gap_params_init()

gatt_init()

peer_manager_init()

Do they need care on shutdown or re-enabling ? Especially the peer manager seems to call gcm_init() and runs out of memory ? So maybe not re-init the peer manager ? I am just concerned about lingering states that shouldn't survive a soft device shutdown.

Question 3: Is the DB discovery properly terminated when disabling the soft device ?

As I debugged the DB discovery, I found a few peculiarities. It appears that the module is designed such that you can have multiple instances. Yet when you call 

ble_db_discovery_close()

it seems to "brutally" set m_num_of_handlers_reg=0. Not sure if that should be the case. (this is really only for your internal purposes, I don't have multiple instances).

But I do see that the above ...close() call, which I figured I had to call when shutting down the soft device, it doesn't set

p_db_discovery->discovery_in_progress = false;

And since the discovery module is created as a static variable via a macro with initialization, when re-enabling the soft device, it thinks that the discovery is still in progress.

Could be a bug, or it is supposed to be like that ... Maybe you can share your thoughts.

Thanks a lot.

[bjorn-spockeli]

Hi Shockel,

Question 1: The gatt queue module performs a lot of actions in the background and I haven't quite figured it all out.  If the soft device is disabled, does that automatically clear the gatt queue ? Should it ? And how would I go about it if I "manually" wanted to do so ?

 The GATT module handle the connection parameter for the active Bluetooth connections and handle events like BLE_GATTS_EVT_EXCHANGE_MTU_REQUEST and BLE_GAP_EVT_DATA_LENGTH_UPDATE_REQUEST, see nRF5 SDK v16.0.0: Experimental: GATT Module. When the SoftDevice is disabled, then all the connections are terminated and you will no longer receive any BLE events from the SoftDevice. So in short, there is no queue or similar that needs to be cleared. 

Question 2: The example project ble_app_gzll shows some steps to perform when shutting down the soft device, and what to do when you re-enable it. For example, it shows that you don't want to re-initiablize nrf_ble_qwr_init(), while other init()'s you do. But other examples use quite a few more modules/services. Can you advise what to do with the following:

gap_params_init()

gatt_init()

peer_manager_init()

Do they need care on shutdown or re-enabling ? Especially the peer manager seems to call gcm_init() and runs out of memory ? So maybe not re-init the peer manager ? I am just concerned about lingering states that shouldn't survive a soft device shutdown.

gap_params_init() and gatt_init() should be called after you re-enable the SoftDevice, i.e. after you call nrf_sdh_ble_enable() 

 The Peer Manager should only be initialized once. 

 

Question 3: Is the DB discovery properly terminated when disabling the soft device ?

As I debugged the DB discovery, I found a few peculiarities. It appears that the module is designed such that you can have multiple instances. Yet when you call 

ble_db_discovery_close()

it seems to "brutally" set m_num_of_handlers_reg=0. Not sure if that should be the case. (this is really only for your internal purposes, I don't have multiple instances).

But I do see that the above ...close() call, which I figured I had to call when shutting down the soft device, it doesn't set

p_db_discovery->discovery_in_progress = false;

And since the discovery module is created as a static variable via a macro with initialization, when re-enabling the soft device, it thinks that the discovery is still in progress.

Could be a bug, or it is supposed to be like that ... Maybe you can share your thoughts.

 The SoftDevice is does not touch any of the software modules used in the application. The DB discovery module simply calls the SD API to start service/characteristic and descriptor and handles the received events indicating that a service, characteristic or descriptor has been found, e.g.

• BLE_GATTC_EVT_PRIM_SRVC_DISC_RSP
• BLE_GATTC_EVT_CHAR_DISC_RSP
• BLE_GATTC_EVT_DESC_DISC_RSP

The SoftDevice does not keep track of if there was a service discovery in progress when it was disabled and then resume this when the SoftDevice is re-enabled.

Also note that when using more than one DB Discovery instance, the ble_db_discovery_close function should be called for each instance.

Best regards

Bjørn

[Shockel]

Thanks, Bjorn, maybe I wasn't using the right terminology. In Question 1, I was referring to the m_ble_gatt_queue that many services use in the example apps (for example ANCS). I believe it is for queued writes. looking at nrf_ble_gq.c it uses a number of queues internally. I was wondering if that needs special attention to "clean up". And whether some queue content may still exist when I restart the SoftDevice.

Question 2: clear. Thanks.

Question 3: So you think I should just manually set "discovery in progress" to false after closing ?

ble_db_discovery_close(&m_db_disc);
m_db_disc.discovery_in_progress = false;

BTW. Do I need to disconnect before shutting down the SoftDevice ? (I am the peripheral)

[bjorn-spockeli]

Shockel said:

Thanks, Bjorn, maybe I wasn't using the right terminology. In Question 1, I was referring to the m_ble_gatt_queue that many services use in the example apps (for example ANCS). I believe it is for queued writes. looking at nrf_ble_gq.c it uses a number of queues internally. I was wondering if that needs special attention to "clean up". And whether some queue content may still exist when I restart the SoftDevice.

 Ah, now I understand. Yes, the Gatt Queue Module is used by some of our central examples. The SoftDevice does not keep track of requests through a re-initialization, but it seems that the GATT Queue module may try to process a queued item later if the SD returns NRF_ERROR_BUSY to one of the relevant API calls. If the SoftDevice is disabled when such a retry is attempted, then you'll enter the request_err_code_handle. Looking at the GATT Queue code, it seems that you could check the nrf_ble_gq_t::p_req_queue with nrf_queue_is_empty. If the queue is empty then you can disable the SD without risking the GATT queue module attempting to process a request when the sd is disabled. 

Shockel said:

Question 3: So you think I should just manually set "discovery in progress" to false after closing ?

No, I would call  ble_db_discovery_close() when you get the BLE_GAP_EVT_DISCONNECTED. Then the discorvery module will handle the discovery_in_progress flag internally. 

static void on_disconnected(ble_db_discovery_t       * p_db_discovery,
                            ble_gap_evt_t      const * p_evt)
{
    if (p_evt->conn_handle == p_db_discovery->conn_handle)
    {
        p_db_discovery->discovery_in_progress = false;
        p_db_discovery->conn_handle           = BLE_CONN_HANDLE_INVALID;
    }
}

 

Shockel said:

BTW. Do I need to disconnect before shutting down the SoftDevice ? (I am the peripheral)

 Yes, I would disconnect all active connections before disabling the Softdevice. 

Best regards

Bjørn