Flash Usage Scenarios#

The SiWx917 device family supports multiple ways to connect and use flash memory. Depending on system design, you can operate in common flash mode or single-flash mode (SiWN917x). This section describes typical usage scenarios for firmware execution, data storage, and application-level features such as execute in place (XIP), encryption, and filesystem selection.

Typical Use Case 1: Common Flash Mode#

In common flash mode, both processors—the Network Wireless Processor (NWP) and the Arm® Cortex®-M4—share a single flash device.

The shared flash may be:

  • Stacked flash (connected through Pinset 0), or

  • External flash (Pinset 2).

Workflow Overview#

Common flash mode is suitable when:

  • Both processors need to execute firmware stored in the same device.

  • The system requires a single storage location for configuration, keys, or logs.

  • Memory usage is modest and does not require processor-specific flash layouts.

Steps#

  1. Select a supported flash device (Macronix, GigaDevice, or XMC).

  2. Configure and validate MBR parameters for the selected flash.

  3. Build and flash firmware images for both processors.

  4. Ensure the Trusted Application (NWP) Bootloader can detect the correct pinset.

  5. Run firmware directly from flash using XIP.

Benefits#

  • Simplifies memory map management.

  • Reduces bill of materials (BOM) cost—one flash device serves both processors.

Typical Use Case 2: Single-Flash Mode (SiWN917x)#

Workflow Overview#

  1. Select the flash device and confirm its MBR parameters.

  2. Program the MBR and application image into flash.

  3. Boot directly from the NWP Bootloader; it auto-detects the pinset.

  4. Use the flash for firmware, configuration storage, or key material.

Benefits#

  • Simplified architecture.

  • Lower-cost designs suitable for NWP-only products.

Typical Use Case 3: Encrypted XIP (Inline Decryption)#

The QSPI controller supports inline AES decryption, protecting firmware confidentiality.

Implementation Highlights#

  • Firmware stored in flash is encrypted.

  • The QSPI controller decrypts instructions on-the-fly during execution.

  • Only encrypted firmware is readable outside the device.

Workflow Overview#

  1. Generate encryption keys using secure provisioning tools.

  2. Encrypt firmware images.

  3. Store encrypted images in flash using the correct layout.

  4. Enable inline decryption in the QSPI controller (configured through MBR).

  5. Boot the device to confirm successful secure XIP.

Benefits#

  • Protects intellectual property.

  • Secure firmware execution for IoT deployment.

Typical Use Case 4: Storage (Internal and External)#

Flash devices can attach to one of two pinsets:

  • Pinset 0 (GPIO 0–5) → Stacked flash

  • Pinset 2 (GPIO 46–51) → External flash

Workflow Overview#

  1. Choose the required pinset in hardware.

  2. Ensure the MBR configuration matches the selected pinset.

  3. Use flash for:

    • Firmware

    • Configuration

    • Non-volatile memory (NVM)

    • Filesystem storage

    • Key storage

Typical Use Case 5: Wear Leveling#

Wear leveling distributes write and erase cycles across flash sectors.

Notes:

  • Supported through selected software frameworks only.

  • Requires a filesystem for managing wear leveling.

Workflow Overview#

  1. Choose a wear‑leveling filesystem (such as LittleFS).

  2. Configure its storage region in flash.

  3. Use SDK APIs to read/write files.

  4. Use logs to validate file and block allocation patterns.

Typical Use Case 6: NVM3 vs. LittleFS#

The choice between NVM3 and LittleFS depends on your storage needs.

NVM3#

  • Optimized for key-value pairs.

  • Small overhead and fast access.

  • Ideal for configuration data or parameters.

LittleFS#

  • Hierarchical filesystem.

  • Built-in wear leveling and power-fail safety.

  • Suitable for logs, structured files, or multi-file storage.

Workflow Overview#

  1. Decide whether the application needs keys or records (NVM3) or files (LittleFS).

  2. Reserve a flash region for the chosen system.

  3. Configure the filesystem in Simplicity Studio or manually in the linker script.

  4. Test file creation and wear-leveling behavior.

Application Areas#

  • IoT gateway devices

  • Edge processing nodes

  • Secure firmware deployment

  • Data loggers and sensor hubs

  • Battery-operated systems

  • Multi-processor applications requiring shared flash

  • Wear-leveled data storage

References#

  • SiWx917 Reference Manual

  • SiWx917 Data Sheet

  • WiSeConnect SDK Flash Storage Examples

  • QSPI controller documentation