Overview

  • The FTL (Flash Translation Layer) is a system software layer specifically designed for the Bluetooth protocol stack. Its purpose is to make Flash more convenient to use as a data storage medium. Therefore, applications are not recommended to use FTL for storing information directly; alternative solutions are advised.

  • NOR Flash read/write operations are performed in units of pages, but erase operations must be performed in units of blocks, and the target block must be erased before writing. Since the memory range for erase operations differs from that of read/write operations, the overall performance of the Flash storage system can degrade significantly.

  • The FTL maintains a mapping table from logical addresses to physical addresses, translating logical address requests from the upper-layer file system into physical address requests for Flash memory. This not only improves the read/write performance of Flash memory but also extends its lifespan through wear-leveling strategies.

The architecture of the Flash storage system is illustrated below:

../../rst_rtos/0_ftl/figures/architecture_of_flash_memory_system.svg

The FTL algorithm provides the following core functionalities:

  • Mapping from logical addresses to physical addresses.

  • Power-loss recovery: Even if an unexpected power loss occurs during FTL operations, the FTL’s data structures should remain intact to ensure data consistency.

  • Wear leveling: Distributes erase/write cycles as evenly as possible across all storage blocks.

As shown in the figure below, when writing data to the logical mapping, the FTL generates data packets in a specific format and stores them in Flash.

  • When modifying logical mapping data, a new data packet is generated and appended to the end of the physical mapping. When a physical page is nearly full, garbage collection is triggered to reclaim old pages (which are subsequently erased).

  • When reading data from the logical mapping, the FTL searches the physical mapping to locate the latest data packet containing the specified address.

../../rst_rtos/0_ftl/figures/ftl_overview.svg

FTL working principle

Note

When using the FTL, users do not need to concern themselves with the physical mapping, as its maintenance is handled automatically by the FTL.

Features

Physical Mapping

  • Physical page size: 4096 bytes.

  • Number of physical pages configurable.

  • Total size of physical mapping: 4096 × number of physical pages.

Logical Mapping

  • The maximum capacity of the logical mapping is determined by the size of the physical mapping, calculated as: \([511 \times (\rm physical\_page\_number -1)-1] \times 4\)

How to Use FTL

Precautions

For Typical BLE Applications

  • The Bluetooth Host protocol stack uses 344 bytes of FTL by default. The SDK maintains information for 4 BLE connections by default, with each connection requiring 216 bytes of FTL. The number of BLE connections can be configured via RTK_BLE_GAP_MAX_LINKS.

For Typical BLE Mesh Applications

  • BLE Mesh applications require additional FTL calculations on top of the FTL used by the Bluetooth Host protocol stack and BLE connection information.

  • For Mesh devices:

    • The Mesh protocol stack uses 1752 bytes of FTL by default.

    • The SDK maintains a Mesh network with 20 nodes by default. Each additional node increases the RPL (Replay Protection List) count (consuming 16 bytes of FTL).

    • The RPL count can be configured via bt_mesh_rpl_num.

  • For Mesh provisioners:

    • The Mesh protocol stack uses 1280 bytes of FTL by default.

    • The SDK allows provisioning 20 nodes by default. Each additional provisionable node increases both the Device Key count (consuming 20 bytes of FTL) and the RPL count (consuming 16 bytes of FTL).

    • The Device Key count can be configured via bt_mesh_dev_key_num, and the RPL count via bt_mesh_rpl_num .

  • For both Mesh devices and provisioners:

    • The Mesh application uses 3000 bytes of FTL by default.

    • If the calculated FTL size exceeds 3000 bytes, the bt_mesh_flash_size parameter must be used to allocate additional FTL space.

Example

The table below lists three typical BLE application scenarios and their corresponding FTL size requirements. Configure the FTL physical address appropriately based on recommendations.

Scenario

Calculation

FTL size

3 BLE connections, No Mesh usage

344 + 216 * 3 = 992

992 bytes

4 BLE connections, Mesh device (50 nodes in network)

Since 1752 + 16 * 50 <= 3000, 344 + 216 * 4 + 3000 = 4208

4208 bytes

5 BLE connections, Mesh provisioner (50 provisionable nodes)

Since 1280 + (20 + 16) * 50 > 3000, 344 + 216 * 5 + 1280 + (20 + 16) * 50 = 4504

4504 bytes

Configuration Steps

  1. When BT is enabled, FTL is automatically enabled. Please refer to the BT Application Note (AN) for details.

  2. The address range of FTL is defined in the ameba_flashcfg.c file.

    The default configuration for logical and physical mappings is as follows:

    • Physical address range: 0x08620000~ 0x08622FFF

    • Logical mapping size: 4084 bytes