![]() |
Coming soon |
1. Introduction
Flash management proposes a simple interface to the upper layers to execute operations in FLASH. It manages synchronization between flash operations and the RF activity. Thus, users do not have to bother with RF timing and flash operations.
2. Concepts
This chapter deals with the major concepts and features of the Flash management. The flash management is a multi-layer organization and rely on different concepts. Among these concepts, here are the most important ones:
2.1. Organization
Flash management is based upon a 5 layers distribution composed by:
- Simple NVM Arbiter
- Specific flash interface that emulates the behavior of multiple NVMs.
- Flash manager
- Main user interface for flash operation (Flash write, flash erase, etc.).
- RF Timing synchro
- Module that realizes synchronization between BLE LL and Flash operations by activating or deactivating the dedicated flash control status.
- Flash Driver
- Low level driver abstraction layer. Controlled by the flash control statuses.
- HAL Flash
- Low level driver that interacts directly with the Flash HW.
2.2. Asynchronous Operations
The whole flash operations are either executed via the Flash Manager interface or via the Simple NVM Arbiter interface. Both work on an asynchronous behavior, which means that the user is requesting operations to be performed and is notified later on, once the operation is over.
However, since the operation is asynchronous, during write operation, the user shall hold his buffer allocation as long as the write operation is not done. In case of a content change in this buffer, the user shall restart a brand-new flash operation.
2.3. Synchronous flash access with RF
Flash operations achieved with Flash manager or Simple NVM Arbiter are synchronized with RF activity. Meaning that flash operations are achieved only during free RF activity time slot.
This feature is transparent to the user and is fully handled by the Flash manager or the Simple NVM Arbiter. Therefore, the user does not have to bother with RF and Flash synchro. This is all, already, managed.
2.4. Flash Access
In this Flash management implementation, the Flash access is protected at two distinct levels:
- Flash semaphore
- A semaphore is required to share the flash interface between several SW modules. The owner of the semaphore is the only one that can request flash operations. The semaphore is attributed to the first requester and released once its operation is over.
- Flash control statuses
- Independently from the flash semaphore, the flash driver provides flags – Flash Control Status – to prevent flash operation depending on the system activity. These flags/statuses are checked before any flash operation by the flash driver.
2.5. Typical use case
A classic flash operation routine is represented in the following schema:
According to the RF state, the flash manager adapts its behavior. During RF activity, it will request the help of the RF timing synchro to synchronize flash operation and radio activity. Otherwise, the flash manager will simply execute the flash operation until all work is done.
3. Modules
3.1. Flash Driver
The Flash Driver is an overlay of the HAL driver with a flash access management. Here are its main features:
- HAL driver abstraction for flash operations - i.e.: Write and Erase
- Flash access protection based on different flags
Flash operations are not intended to be achieved with this modules. Since no RF synchronization is achieved at this level, you may have a a look at the Flash Manager and the Simple NVM Arbiter parts for a better approach regarding flash operations. And manage the accesses of the Flash.
However, this module is mandatory for any flash access management. There are three flags managing the flash access:
- LL_RFTS:
- Flag managed by the RF Timing Synchro module. It shall always be set to DISABLE at the start of the application and during RF activity.
- When a time slot is granted by the LL, the RFTS module enables this flag leading to the possibility to access the Flash without any risk of breaking the RF activity.
- When the time slot is about to close, the RFTS module disable this flag leading to no more flash operation possible - RF activity protection.
- LL_RFTS_BYPASS:
- Flag managed by the user. It allow the user to bypass the impact of the above mentioned flag leading to the possibility to directly access the flash even if the LL_RFTS flag is disabled.
- This flag is intended to be used as an optimization flag. For instance, it can be set or reset at ends and restarts of RF activities.
- SYSTEM:
- This flag is updated based on any other request than the SNPS FW LL. When it is set to DISABLE, the Flash Driver will stop any flash operation and wait for the the flag to go back to ENABLE.
The following schema highlights the typical check of flash access:
3.2. RF Timing Synchro
The RF Timing Synchro is the manager of the synchronization between the flash operations and the RF activity. It is managed by the Flash manager and rely on the RF LL to determine whether or not flash operations can be achieved. This module is not intended to be managed by the user. Concepts are here presented for pure user understanding.
To achieve the synchronization between the RF and the Flash domains, the RF Timing Synchro set up timing slots during which flash operations can be proceed without harming the RF activity.
These timing slots are the only moment when the flash access is authorized by the LL_RFTS flag - See the Flash Driver. The RFTS module enables the flag at the start of the timing slot and disables it at the end of the slot - Whether the timing slot is over or the Flash manager released the slot before its end.
3.3. Flash Manager
TBD.
3.4. Simple NVM Arbiter
The Simple NVM Arbiter is a different interface for flash operations. It relies on the flash manager but adds the possibility to create and manage NVMs – Up to 32 NVMs.
NVMs are identified by a unique ID and are composed of multiples banks - at least 2, 1 for restore and 1 ready for write. Banks have a sector boundary.
The user can register up to 4 buffers in 1 NVM. During write operation, all the registered buffers are written in Flash – a whole bank update – and during restore operation, the user restores only one identified buffer.
The classic “way of use” of the Simple NVM Arbiter is like the schema below:
- Initialize the SNVMA
- Register the buffer to work with
- Execute, as many times as you want, write or restore operation
4. Interfaces
Here comes a list of the available functions for the different Flash management modules:
4.1. Flash Driver
4.1.1. Flash driver error codes
Error code | Description |
---|---|
FD_FLASHOP_SUCCESS | Flash operation success |
FD_FLASHOP_FAILURE | Flash operation failure |
4.1.2. Flash driver functions
FD_SetStatus |
---|
Description
|
FD_WriteData |
---|
Description
|
FD_EraseSectors |
---|
Description
|
4.2. RF Timing Synchro
4.2.1. RF Timing synchro error codes
Error code | Description |
---|---|
RFTS_CMD_OK | The RF Timing synchronization command was successfully executed |
RFTS_WINDOW_REQ_FAILED | The RF Timing synchronization module failed to register the window request |
RFTS_WINDOW_REL_ERROR | An error occurred during the window release procedure |
4.2.2. RF Timing synchro functions
RFTS_ReqWindow |
---|
Description
|
RFTS_RelWindow |
---|
Description
|
4.3. Flash Manager
4.3.1. Flash manager error codes
Error code | Description |
---|---|
FM_OK | The Flash Manager is available and a window request is scheduled |
FM_BUSY | The Flash Manager is busy and the caller will be called back when it is available |
FM_ERROR | An error occurred while processing the command |
4.3.2. Flash manager functions
FM_Write |
---|
Description
|
FM_Erase |
---|
Description
|
FM_BackgroundProcess |
---|
Description
|
FM_ProcessRequest |
---|
Description
|
4.4. Simple NVM Arbiter
4.4.1. Simple NVM Arbiter error codes
Error code | Description |
---|---|
SNVMA_ERROR_OK | No error code |
SNVMA_ERROR_NOK | Error that occurred before any check |
SNVMA_ERROR_NOT_INIT | Error code for a module not yet initialized |
SNVMA_ERROR_ALREADY_INIT | Error code for a module already initialized |
SNVMA_ERROR_CMD_PENDING | Error code for a command pending |
SNVMA_ERROR_NVM_NULL | Error code for a NULL NVM pointer |
SNVMA_ERROR_NVM_NOT_ALIGNED | Error code for a not aligned NVM address |
SNVMA_ERROR_NVM_OVERLAP_FLASH | Error code for a NVM size that overlaps flash capacities |
SNVMA_ERROR_NVM_BUFFER_FULL | Error code for a full NVM Buffer |
SNVMA_ERROR_NVM_BANK_EMPTY | Error code for an empty NVM Buffer |
SNVMA_ERROR_NVM_BANK_CORRUPTED | Error code for a corrupted NVM Buffer |
SNVMA_ERROR_CRC_INIT | Error code for a CRC initialization fail |
SNVMA_ERROR_BUFFERID_NOT_KNOWN | Error code for an unknown Buffer ID |
SNVMA_ERROR_BUFFERID_NOT_REGISTERED | Error code a non-registered Buffer ID |
SNVMA_ERROR_BUFFER_NULL | Error code for a NULL Buffer pointer |
SNVMA_ERROR_BUFFER_NOT_ALIGNED | Error code for a not aligned Buffer address |
SNVMA_ERROR_BUFFER_SIZE | Error code for a Buffer size that is not OK |
SNVMA_ERROR_BUFFER_CONFIG_MISSMATCH | Error code for a mismatch between the registered buffer and the buffer to restore |
SNVMA_ERROR_FLASH_ERROR | Error code for a flash error |
SNVMA_ERROR_UNKNOWN | Error code for an unknown error |
4.4.2. Simple NVM Arbiter functions
SNVMA_Init |
---|
Description
|
SNVMA_Register |
---|
Description
|
SNVMA_Restore |
---|
Description
|
SNVMA_Write |
---|
Description
|
5. How to
- FM erase
- FM write
- FM write / no RF
- SNVMA config
- SNVMA register
- SNVMA write
- SNVMA restore - after reset ?
6. Revisions