Flash memory API

The System on Chip (SoC) flash memory Application Programming Interface (API) provides the application with flash write, flash erase, and flash protect support through the SoftDevice. Asynchronous flash memory operations can be safely performed during active Bluetooth® Low Energy connections using the Flash memory API of the SoC library.

The flash memory accesses are scheduled to not disturb radio events. See Flash API timing for details. If the protocol radio events are in a critical state, flash memory accesses may be delayed for a long period resulting in a time-out event. In this case, NRF_EVT_FLASH_OPERATION_ERROR will be returned in the application event handler. If this happens, retry the flash memory operation. Examples of typical critical phases of radio events include connection setup, connection update, disconnection, and impending supervision time-out.

The probability of successfully accessing the flash memory decreases with increasing scheduler activity (i.e. radio activity and timeslot activity). With long connection intervals, there will be a higher probability of accessing flash memory successfully. Use the guidelines in Behavior with Bluetooth Low Energy traffic and concurrent flash write/erase to improve the probability of flash operation success. The table assumes a flash write size of four bytes. LE 1M PHY is assumed unless another PHY is specified.

Note: If the SoftDevice is run on nRF52810, flash page (4096 bytes) erase can take up to 85 ms and a 4-byte flash write can take up to 41 µs. If the SoftDevice is run on nRF52832, flash page (4096 bytes) erase can take up to 89.7 ms and a 4-byte flash write can take up to 338 µs. A flash write must be made in chunks smaller or equal to the flash page size. Make flash writes in as small chunks as possible to increase the probability of success and reduce chances of affecting Bluetooth Low Energy performance.
Table 1. Behavior with Bluetooth Low Energy traffic and concurrent flash write/erase
Bluetooth Low Energy activity Flash write/erase
High Duty cycle directed advertising Does not allow flash operation while advertising is active (maximum 1.28 seconds). In this case, retrying flash operation will only succeed after the advertising activity has finished.
All possible Bluetooth Low Energy roles running concurrently (connections as a Peripheral and Advertiser) Low to medium probability of flash operation success

Probability of success increases with:

  • Configurations with shorter event lengths
  • Lower data traffic
  • Increase in connection interval and advertiser interval
1 connection as a Peripheral
The active connection fulfills the following criteria:
  • Supervision time-out > 6 x connection interval
  • Connection interval ≥ 25 ms
High probability of flash operation success
4 connections as a Peripheral
All active connections fulfill the following criteria:
  • Supervision time-out > 6 x connection interval
  • Connection interval ≥ 115 ms
Medium to high probability of flash operation success.

The scheduling of connections as Peripheral is done by the peer devices. The Peripheral does not influence this scheduling, which means that the connection events may collide and result in flash operations being blocked. With multiple connections as Peripheral, choose connection intervals and connection event lengths in a way that leaves enough free time to handle collisions and other activities.

Connectable Undirected Advertising

Nonconnectable Advertising

Scannable Advertising

Connectable Low Duty Cycle Directed Advertising

High probability of flash operation success
No Bluetooth Low Energy activity Flash operation will always succeed