How to stop softdevice so I can write to flash

RE: How to stop softdevice so I can write to flash

David Andresky — Tue, 08 Jan 2019 17:42:17 GMT

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.

RE: How to stop softdevice so I can write to flash

wpaul — Thu, 03 Jan 2019 23:25:15 GMT

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.

RE: How to stop softdevice so I can write to flash

David Andresky — Thu, 03 Jan 2019 22:13:47 GMT

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.

RE: How to stop softdevice so I can write to flash

wpaul — Thu, 03 Jan 2019 20:24:05 GMT

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.

RE: How to stop softdevice so I can write to flash

David Andresky — Thu, 03 Jan 2019 17:35:55 GMT

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.

RE: How to stop softdevice so I can write to flash

Einar Thorsrud — Thu, 03 Jan 2019 09:27:55 GMT

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