The System on Chip (SoC) NVM Application Programming Interface (API) provides the application with NVM write support through the SoftDevice. Asynchronous NVM operations can be safely performed during active Bluetooth® Low Energy connections using the NVM API of the SoC library.
The NVM accesses are scheduled to not disturb radio events. The SoftDevice uses timeslots to schedule NVM access. See Timeslot API timing for details. If the protocol radio events are in a critical state, NVM accesses might be delayed for a long period resulting in a time-out event. In this case, NRF_EVT_FLASH_OPERATION_ERROR is returned in the application event handler. If this happens, retry the NVM 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 NVM decreases with increasing scheduler activity (that is, radio activity and timeslot activity). With long connection intervals, there is a higher probability of accessing NVM successfully. Use the guidelines in Behavior with Bluetooth Low Energy traffic and concurrent NVM write to improve the probability of NVM operation success.
Make NVM writes in as small chunks as possible to increase the probability of success and reduce the chance of affecting Bluetooth Low Energy performance. The following table assumes an NVM write size of four bytes. LE 1M PHY is assumed unless another PHY is specified.
The time required to do an NVM operation using the NVM API depends on which Integrated Circuit (IC) is being used. For the exact timing numbers, see the relevant datasheet in Recommended reading.
| Bluetooth Low Energy activity | NVM write |
|---|---|
| High Duty cycle directed advertising | Does not allow NVM operation while advertising is active (maximum 1.28 seconds). In this case, retrying NVM operation only succeeds after the advertising activity has finished. |
| All possible Bluetooth Low Energy roles running concurrently (connections as a Central, Peripheral, Observer, and Broadcaster) | Low to medium probability of NVM operation success Probability of success increases with:
|
| Extended scanner | Medium to high probability of NVM operation success. When receiving extended advertising events with secondary channel packets, the scanner cannot choose when the secondary channel timing-events will occur. Probability of success increases with:
Probability of success might increase with:
|
Extended scannable advertiser with the following configurations:
|
High probability of NVM operation success |
| 8 high bandwidth connections as a Central 1 high bandwidth connection as a Peripheral All active connections fulfill the following criteria:
|
High probability of NVM write success |
| 1 connection as a Peripheral The active connection fulfills the following
criteria:
|
High probability of NVM operation success |
| 4 connections as a Peripheral All active connections fulfill the following
criteria:
|
Medium to high probability of NVM 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 might collide and result in NVM 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 NVM operation success |
| No Bluetooth Low Energy activity | NVM operation always succeeds |