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.