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

  • I found the issue. We have a python script that generates a header file with a memory map. This memory map is referenced throughout our code, including our bootloader. The internal flash area that I am trying update stores the execution address for the main code. When I call sd_flash_erase(), the value for the execution address is temporarily all FF's. When the softdevice generates the flash operation event it caused the bootloader to feed a bogus address to the interrupt handler causing the program counter to go off into the weeds. I hard coded the address in the bootloader and was able to get past this problem.

    We can close the issue. 

Reply
  • I found the issue. We have a python script that generates a header file with a memory map. This memory map is referenced throughout our code, including our bootloader. The internal flash area that I am trying update stores the execution address for the main code. When I call sd_flash_erase(), the value for the execution address is temporarily all FF's. When the softdevice generates the flash operation event it caused the bootloader to feed a bogus address to the interrupt handler causing the program counter to go off into the weeds. I hard coded the address in the bootloader and was able to get past this problem.

    We can close the issue. 

Children
No Data
Related