Disable Softdevice from observer crashes; "don't do that" should be documented?

[butch]

I tried to disable Softdevice from within an observer (kind ble_observer.) It seems to crash. Instead, I just schedule another task to run (and disable the Softdevice) after the observer completes. That seems to work better. Should it be stated in the documentation: you shouldn't disable the SD from within an observer?

I can't say whether the call to nrf_sdh_disable_request() returned an error, since my code is not checking the result.  But a following  assert(!nrf_sdh_is_enabled()) did not assert, so I presume no error was returned.

The example/multiprotocol/ble_gzl... does not exercise this problem, since it disables SD from the main context.

My application is multiprotocol. As soon as a user uses BT to find, connect, and write some characteristic, they are done with BT, which I observe, and then want to disable SD.

[Sigurd]

Hi,

Thank you for reporting this.

What is happening is that we are pulling events from the SoftDevice in nrf_sdh_ble_evts_poll(), and are forwarding them to the observers. We do this until we no longer have any new events from the SoftDevice to process, and sd_ble_evt_get() returns NRF_ERROR_NOT_FOUND. But if we disable the SoftDevice in one of the observers, the next call to sd_ble_evt_get() will return NRF_ERROR_SOFTDEVICE_NOT_ENABLED, and we will enter the error-handler because only NRF_ERROR_NOT_FOUND and NRF_SUCCESS are considered valid return codes.

[Keith Wakeham]

Just adding a note to this old post. Butch's solution works after days of pulling my hair out on this. Keep in mind that even in SDK 17 examples like buttonless DFU is written with the nrf_sdh_disable_request() inside the event that Sigurd said causes a bug. 

The reason it works in their examples is because they go to system power off BEFORE the observer runs nrf_sdh_ble_evts_poll() thus causing the crash. So basically, the examples are a bit "buggy" here.

[Sigurd]

Hi,

This has unfortunately not been fixed in SDK 17.0.2. nrf_sdh_soc_evts_poll and nrf_sdh_ble_evts_poll functions may cause reset if nrf_sdh_disable_request is called from observer. Proposed fix is to add an exception for NRF_ERROR_SOFTDEVICE_NOT_ENABLED in nrf_sdh_soc.c and nrf_sdh_ble.c

 

    if (ret_code != NRF_ERROR_NOT_FOUND && ret_code != NRF_ERROR_SOFTDEVICE_NOT_ENABLED)
    {
        APP_ERROR_HANDLER(ret_code);
    }

[ask6483]

Hi,

This bug will also happen when NRF_PWR_MGMT_CONFIG_USE_SCHEDULER is enabled. System power off is delayed then and nrf_sdh_ble_evts_poll() runs causing the crash. I was incredibly lucky to find this post ;)