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.
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 the chance of affecting Bluetooth Low Energy performance. The table below assumes a flash write size of four bytes. LE 1M PHY is assumed unless another PHY is specified.
The time required to do a flash memory operation using the flash memory API depends on which Integrated Circuit (IC) is being used. For the exact timing numbers, see the relevant product specification (Additional documentation). In the table below, a flash page erase is assumed to last for 90 ms.
| 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:
|
| 1 connection as a Peripheral The active connection fulfills the following
criteria:
|
High probability of flash operation success |
| 4 connections as a Peripheral All active connections fulfill the following
criteria:
|
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 |