NVM on 52840 with Bluetooth

[Dermot Murphy]

Hi,

I am porting a product from SDK 15 to SDK 17 and to Nrf Connect.

We need to maintain code combability as far as possible between products using SDK 15/17 and products using nRF Connect as the Nordic bootloader is not compatible.

Devices in the field based on SDK 15 need to be upgraded in the field and I understand that the memory layout of binaries build using nRF Connect is not compatible with the older bootloader.  Hence the need to maintain two code bases.

The product uses the soft Device S140 for Bluetooth.

On SDK 15 we used commands like:

nrf_sdh_is_enabled

sd_flash_page_erase

sd_flash_write

sd_evt_get

to check if the soft device is running, erase a page of flash, write a page of flash, and check if the flash operation requested has completed.

I understand the functions had to be called via the soft device to prevent the soft device faulting when Bluetooth was running, and a NVM page needed to be erased/written.

The functionality used on BLE is simply to advertise, allow a mobile to connect, and open a UART type channel for data transfer.

Does the soft device with nrf Connect still control access to erasing and writing flash memory, and if so, what are the equivalent functions to use?  Are these functions non-blocking in the same way as in SDK 15/17?

I wish to use a Nordic function set, rather than use the Zephyr layout so that I can maintain source code compatibility as far as possible for builds using SDK15/17.  I therefore do not wish to use the Zephyr NVM system.

Thanks

Dermot

[Kenneth]

Hello,

The overall answer to your question is that the non volatile memory controller in all nRF5x variants will block the CPU during erase and write to flash, the software implementation might be slightly different based on the SDK, but the underlying low level implementation will schedule this with other ongoing activities (e.g. for BLE is will possibly be skipping some advertisement or connection intervals to ensure it can have the ~100ms period it for instance need to erase a flash page).

To get familiar with storing data to flash please check out for instance the settings modules: 
https://docs.nordicsemi.com/bundle/ncs-latest/page/zephyr/services/storage/settings/index.html 

How to implement DFU: 
https://academy.nordicsemi.com/courses/nrf-connect-sdk-intermediate/lessons/lesson-9-bootloaders-and-dfu-fota/ 

Kenneth

[Dermot Murphy]

Hi Kenneth,

Thank you for your reply.

With regard to DFU, are you suggesting that the nrfConnect build with Zephyr can be flashed via a bootloader for the SDK V15/17?  My understanding is that this is not possible, which means that we will must different builds of firmware for products in the field which use the bootloader from SDK 15, and newer products which will use the bootloader from nrfConnect/Zephyr.  We must generate these builds from the same source code, apart from small changes wjere the use of Nordic specific functions have changed.

As we have different builds from the same source, we need to be able to reproduce the feature we used to write to NVM in SDK 15 which involves erasing and writing to flash by page.  We do not need file storage or write by pairs etc.  The methods referenced in the link do not include the nrfx functions which we will need to erase a 4K page, and write a 4K page without affecting Bluetooth.

Does nrfConnect/Zephyr SDK use a SoftDevice to implement BLE?  If so, how can we prevent a page erase crashing the soft device unless we can use functions through the Soft Device interface to schedule to the page erase and write?  Alternatively does the nrfx functions request the Soft Device to skip an advertisement directly?

Thanks

Dermot

[Kenneth]

Hello,

Dermot Murphy said:

With regard to DFU, are you suggesting that the nrfConnect build with Zephyr can be flashed via a bootloader for the SDK V15/17?  My understanding is that this is not possible, which means that we will must different builds of firmware for products in the field which use the bootloader from SDK 15, and newer products which will use the bootloader from nrfConnect/Zephyr. 

Not possible no.

Dermot Murphy said:

We must generate these builds from the same source code, apart from small changes wjere the use of Nordic specific functions have changed.

I am not sure I understand this sentence, but the difference is so significant that I don't expect you can reuse pretty much anything in nRF5 SDK -> nRF Connect SDK. If you haven't already please go through the BLE course we have for nRF Connect SDK just to get some introduction to have different it is:
https://academy.nordicsemi.com/courses/nrf-connect-sdk-fundamentals/ 
https://academy.nordicsemi.com/courses/bluetooth-low-energy-fundamentals/ 

The softdevice controller is significantly different also.

Edit: What you are looking for is the bare-metal option we have for the nRF54L-series, however that one doesn't support the nRF52-series: https://www.nordicsemi.com/Products/Development-software/nRF-Connect-SDK/Bare-Metal-option-for-nRF54L-Series 

From the link: "It brings the popular SoftDevice to nRF Connect SDK, offering architecture and API similarity to nRF5 SDK that eases migration of an existing codebase from nRF52 Series to nRF54L Series."

Unfortunately, what you want to do is not possible for the nRF52840.

Kenneth

[Dermot Murphy]

Hi Kenneth,

"I am not sure I understand this sentence, but the difference is so significant that I don't expect you can reuse pretty much anything in nRF5 SDK -> nRF Connect SDK."

We have already ported Bluetooth, UART, PPI, SPI, I2C, Timers, GPIO and WDT using nrfx libraries used in NRF Connect and in SDK 17.  The remaining item to port is NVM.

The code base builds using Segger and SDK 17 to build code for our existing products in the field.  The same code base builds using VSCode and nRfConnect.  Differences between the source are very minor apart from GPIO.

We just need to know what functions to call to erase and write a page of flash, and whether or not those functions will interfer with Bluetooth.

Thanks

Dermot

[Kenneth]

Hi Dermot,

Some time ago there was a softdevice controller api to do this, this is no longer the case. I have with the help of AI made a summary here that I hope explain how things are done today.

Kenneth

---

In the nRF Connect SDK, flash erase/write operations are synchronized with the BLE radio using Multi-Protocol Service Layer (MPSL)-managed timeslots (when MPSL is enabled). In practice, this means that if you use the standard Zephyr flash API on an nRF52840 (e.g. flash_erase()/flash_write() or higher-level storage like NVS/Settings) while BLE is running, the system will not perform the flash operation immediately in the middle of a radio event. Instead, the operation is deferred and executed in a radio idle window obtained via the Multi-Protocol Service Layer’s timeslot mechanism. MPSL essentially coordinates flash access with the BLE stack to avoid timing conflicts, much like the old SoftDevice would delay flash writes until safe.

MPSL Timeslot Coordination: Under the hood, when a flash operation is requested, the nRF Connect SDK’s flash driver (soc_flash_nrf) will interact with MPSL to schedule that operation in a timeslot. A timeslot is a period when the BLE radio is temporarily paused or not scheduled for critical activities, giving the CPU freedom to access restricted resources (like the NVMC for flash). The driver (via an internal module often referred to as “flash_sync”) does the following: it requests a timeslot from MPSL of sufficient length, gets a callback when the timeslot starts, performs as much of the flash operation as it can within that slot, and if the operation isn’t finished, it will request another slot, and so on. This continues until the flash write/erase is complete. By doing this, the flash controller (NVMC) is only active when the radio is idle, preventing BLE packet drops or connection interrupts. The MPSL library manages these requests using the SoftDevice Controller’s internal scheduling. In fact, the nRF Connect SDK code calls mpsl_timeslot_request(...) to begin a flash operation timeslot session. (The MPSL timeslot API was originally intended for user-provided 2.4 GHz protocols, but it’s also used internally here to schedule flash safely.)

Kconfig options and modes (MPSL vs None): The flash driver’s radio synchronization is configurable, but enabled by default whenever a BLE controller is in use. There is a Kconfig choice CONFIG_SOC_FLASH_NRF_RADIO_SYNC_MPSL.

MPSL sync (CONFIG_SOC_FLASH_NRF_RADIO_SYNC_MPSL): This is chosen when using Nordic’s SoftDevice Controller (the closed-source BLE Link Layer provided via nrfxlib, which requires MPSL). In this mode, flash ops are synchronized via the MPSL library as described (using MPSL’s timeslot service). The MPSL library essentially requests a low-level radio timeslot from the SoftDevice controller to perform the flash operation safely. (Internally, MPSL may also use the SoftDevice controller’s SoC flash APIs on your behalf. For you as a developer, it’s transparent – you just call flash_write/erase and it handles the rest.)

No sync (CONFIG_SOC_FLASH_NRF_RADIO_SYNC_NONE): This essentially disables the coordination – meaning flash operations occur immediately, without regard for radio activity. This is not safe to use while BLE is active. It’s really only there for scenarios like non-BLE projects or if you absolutely know you won’t do flash writes during BLE events. By default, the SDK will not use “NONE” when BLE is enabled, so you’d have to explicitly force it (not recommended).

Impact on developers (Zephyr API vs nrfx direct): For most use cases, you should use Zephyr’s flash APIs (or subsystems like LittleFS, NVS, etc. which use them). These will automatically leverage the radio-synchronized driver, so you can call them freely during BLE operation and not worry about timing issues. The driver will block the calling thread until the operation is done (from your perspective), but under the hood it might have waited a bit for a timeslot – this is all handled transparently. For example, writing to NVS during a BLE connection is safe, because NVS uses flash_write() internally which the driver executes via MPSL sync. What you want to avoid is directly invoking low-level flash writes in a way that bypasses this mechanism. For instance, calling nrfx_nvmc_PageErase() or NRF_NVMC->ERASEPAGE on your own while BLE is active is dangerous – those functions will indeed erase the page immediately (stalling the CPU), and if the radio was supposed to run in that window, you’ll likely drop the connection or hit a runtime assert. 

Summary of current architecture: The Multi-Protocol Service Layer (MPSL) is indeed responsible for arbitrating flash access in BLE scenarios. It achieves this by using the SoftDevice Controller’s timeslot interface to schedule flash writes/erases between radio events. In the Zephyr integration, this is largely hidden behind the scenes in the soc_flash_nrf driver and its helper (which call MPSL or the controller as appropriate). For application developers, the takeaway is that flash operations and BLE can safely coexist – you do not need to stop BLE advertising or connections just to write to internal flash, nor do you need to call any special SoftDevice APIs yourself. Simply use the Zephyr flash API, and internally the operation will be synced to the radio timeline.