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

How to stop softdevice so I can write to flash

Hi,

I am working from an existing code base where I had to add the s130 softdevice and BLE scanning capabilities. I have an area of flash that stores application data that I need to update but the existing code base uses nrf_nvmc which locks up the firmware once the softdevice is enabled.

I am developing in SDK 12.3 with the S130 softdevice.

I have looked at the fstorage module but it would require me to make significant changes to the code and I need release quickly. I had hoped I could just shutdown or disable the softdevice and then write to flash using the existing code (nrf_nvmc) but I keep getting assert errors from the softdevice.

I have tried sd_softdevice_disable and softdevice_handler_sd_disable to no avail. In a similar situation I had to write to UICR and disabling the softdevice was sufficient, but I can't write to any other area of flash without the assert error.

How can I shutdown the softdevice so that I can write to flash with nrf_nvmc? I do not need to restart it as I will be resetting the device after I finish all flash operations.

Thanks

Parents
  • Hi,

    As you have noted, the only way to access the NVMC directly is to disable the SoftDevice. That should not cause any problems, as long as you stop any active connections and stop scanning and advertising before you call sd_softdevice_disable().

    A (better?) alternative could be to modify your code so that you call sd_flash_write() instead of disabling the SoftDevice and using the NVMC directly.That should should not introduce a lot of changes in your code. Essentially you do the same thing as before, but you let the SoftDevice schedule the raw flash writes to happen when it has time (between BLE events).

  • Update - the nrf_assert_callback was occurring due to a bug unrelated to the softdevice. I was running a self test on the SPI flash chip that was leaving it in a sleep state. When I tried to erase sectors there was an assert that was failing because it was asleep.

    I still have an issue trying to update the internal flash. When I call the sd_flash_erase() function a sys event is not being received. Instead, a couple seconds after calling sd_flash_erase(), the call stack goes to 0 and it can't recover. The watchdog doesn't even fire.

Reply
  • Update - the nrf_assert_callback was occurring due to a bug unrelated to the softdevice. I was running a self test on the SPI flash chip that was leaving it in a sleep state. When I tried to erase sectors there was an assert that was failing because it was asleep.

    I still have an issue trying to update the internal flash. When I call the sd_flash_erase() function a sys event is not being received. Instead, a couple seconds after calling sd_flash_erase(), the call stack goes to 0 and it can't recover. The watchdog doesn't even fire.

Children
  • I'd be willing to bet that the SoftDevice is trying to deliver an event notification, but somewhere the handling for it isn't set up property. As I said, you should get an SD_EVT_IRQn interrupt. This same vector is used to deliver both BLE protocol events and SoC events. When it triggers, you need to do an sd_evt_get() to read the status. I think for the Nordic SDK this involves using the NRF_SDH_SOC_OBSERVER() macro to install a handler. Somewhere there should be an nrf_sdh.c file in the SDK which contains an SD_EVT_IRQHandler() function (assuming you're using interrupt-driven event dispatching) which calls nrf_sdh_evts_poll(). This should invoke handlers for ble, and or soc events. So if things work correctly, eventually nrf_sdh_soc_evts_poll() should be called and the event should be dispatched to a handler. If you have a debugger connected, I would try to set a breakpoint in one of those dispatch routines and see if you can trace down what happens from there.

Related