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).

  • Thanks Einar,

    My first attempt at this was to use sd_flash_erase() and sd_flash_write(). After sending my question yesterday I went back to this and stopped trying to disable the softdevice.

    The problem I have been running into is the app_error_handler keeps getting called and the code locks up. Let me give a little more detail on what I am doing. 

    The legacy code I am working with has a function that updates an area of internal flash by calling nrf_nvmc_page_erase() and nrf_nvmc_write_words(). After calling those functions it continues on to erase a sector of flash in an external SPI flash chip. This worked until I added the softdevice and switched to sd_flash_erase() and sd_flash_write(). Now it locks up. I am getting a call to nrf_assert_callback() with the 0xDEADBEEF message when I attempt to read the status register of the external flash chip.

    My thought process now is that I need to hold erasing the sector on the SPI chip until the update of internal flash completes. Maybe one is stepping on the other or interfering in some way. I don't understand why but it is the only thing I can think of.

Reply
  • Thanks Einar,

    My first attempt at this was to use sd_flash_erase() and sd_flash_write(). After sending my question yesterday I went back to this and stopped trying to disable the softdevice.

    The problem I have been running into is the app_error_handler keeps getting called and the code locks up. Let me give a little more detail on what I am doing. 

    The legacy code I am working with has a function that updates an area of internal flash by calling nrf_nvmc_page_erase() and nrf_nvmc_write_words(). After calling those functions it continues on to erase a sector of flash in an external SPI flash chip. This worked until I added the softdevice and switched to sd_flash_erase() and sd_flash_write(). Now it locks up. I am getting a call to nrf_assert_callback() with the 0xDEADBEEF message when I attempt to read the status register of the external flash chip.

    My thought process now is that I need to hold erasing the sector on the SPI chip until the update of internal flash completes. Maybe one is stepping on the other or interfering in some way. I don't understand why but it is the only thing I can think of.

Children
  • One clarification: the nRF52 flash is not an "external flash chip" or "SPI chip." It's internal to the device and is not accessed via SPI bus. (If your flash was accessed via SPI bus, you wouldn't be having this problem.)

    If other SoftDevice calls in your application work ok, then I don't know why the flash APIs wouldn't work too. One thing to note is that the sd_flash_write() and sd_flash_page_erase() APIs causes the SoftDevice to generate an event to indicate completion. See nrf_soc.h for more info. The event to expect is either NRF_EVT_FLASH_OPERATION_SUCCESS or NRF_EVT_FLASH_OPERATION_ERROR. The SoftDevice generates an interrupt via the SD_EVT_IRQn vector, and software must call sd_evt_get() to read the event info (this is for SoC events only -- there is a separate sd_ble_evt_get() API for BLE events). I don't know if you're using the Nordic SDK framework or your own custom code, but somewhere there should be a handler registered to drain and capture these events in order for things to work right.

Related