This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Enable/Disable BLE Stack and Softdevice -- SDK 15.3 S132

Have an application that configures a wifi SOC using spim before enabling BLE scanner.

When it is running there are 4 timer events running and the main loop check status and sends data using the wifi soc.

All that works fine until there is a socket error or other issue with the wifi soc.

In order to recover from those errors, you have to stop/start the soc well beyond what the softdevice can tolerate.

So I need to disable the softdevice and scanning and then reconfigure the wifi soc.

I use   ble_stack_stop();, nrf_drv_clock_lfclk_request(NULL);

to stop the softdevice and get the clock going again.

I had to re-init the spim interface but that worked out ok.

But the timer events are not being triggered. Do they need to be re-initialized as well ?

What is the best/correct way to temporarily disable the softdevice while  allowing the application with spim and app_timers to run as they were when the softdevice was enabled ?

This also allows for debugging functions after startup that don't require the softdevice by disabling it and then having full debug capability.

I used the GAZELL/BLE example and added a timer to switch between modes and that worked so I will have to re-visit how/why the timer continued to work in that application but not in my application.  

So the key questions are:

1) Based on the use of spim and timer events, am I disabling the softdevice and stack right ?

2) What should be needed to get the spim interface and timers working other than the lfclk_request referenced above ?

3) Then what is needed to go back to the original environment with the softdevice and stack operational ?

Parents
  • Hi,

    Are you sure that you need to completely disable the Softdevice? I think it should be sufficient to stop scanning/advertising. That said, if you need to disable the Softdevice you can call nrf_drv_clock_lfclk_request() before ble_stack_init(). This will tell the clock driver that there is another user/module that relies on the LF clock so it won't be released when you disable the Softdevice. 

    1. I think it should work if you keep the LF clock running. Sounds like the SPIM and RTC may have to be re-initialized otherwise (have not verified it here). 

    3. Would it be acceptable to perform a soft reset to recover instead of disabling the Softdevice? 

  • If I just stop the scanning (and stack ?) will that allow blocking functions that take >100ms to run without causing an exception ? I will certainly change the lfclk per your suggestions, thanks. Sorry, I am not following/understanding what you mean by performing a soft reset. Does that take the system back to a state where all the variables are still intact but all the modules need to be re-initialized ? I will research but would appreciate a little more info on what you have in mind in that area.

    Thanks so much for the help.

Reply
  • If I just stop the scanning (and stack ?) will that allow blocking functions that take >100ms to run without causing an exception ? I will certainly change the lfclk per your suggestions, thanks. Sorry, I am not following/understanding what you mean by performing a soft reset. Does that take the system back to a state where all the variables are still intact but all the modules need to be re-initialized ? I will research but would appreciate a little more info on what you have in mind in that area.

    Thanks so much for the help.

Children
  • Can you clarify what you mean by blocking? Is the function running in an interrupt context with priority '0' (highest)? The Softdevice should not assert if it's not doing any timing critical (maintaining a BLE connection, advertising, etc). Have you seen any errors from the Softdevice when running this function? 

    A soft reset (call to nvic_systemreset() from the code) will make the device reboot and everything will be re-initialized. 

  • The soft reset will not leave your variables intact.  The variables will be reset to their power-up state and the modules will be re-initialized.

    As long as your are not connected, not advertising and not scanning, a blocking function (Ints disabled) will not interfere with the stack scheduling of those BLE events (since they are not running).

Related