use code sections in the external flash

[Lavanya_Manohar]

We are currently working on a project using the Nordic nRF5340 and nRF7002 DK, which includes 1MB of internal flash and 2MB of external SPI flash. Our application codebase has grown substantially and is now utilizing approximately 900KB of the internal flash, leaving limited space for adding new features.

To address this constraint, we are exploring the feasibility of moving selected read-only data or less frequently used code sections to the external flash at runtime.

Project Setup:

External Flash Interface: SPI (non-memory-mapped)

SDK Version: nRF Connect SDK v2.6.4

Our Questions:

1. Is it possible to store certain parts of the code or read-only data in SPI-connected external flash while keeping the main application executing from internal flash?

2. What is the recommended approach to structure this setup, given that the external flash is not memory-mapped?

3. Is it necessary to load the contents from external flash into RAM before they can be executed?

4. Are there any example projects or documentation that demonstrate best practices for accessing code/data modules stored in SPI flash at runtime?

Our Goals:

1. Optimize Internal Flash Usage: Free up internal flash by relocating infrequently used code or read-only data to external flash.

2. Maintain Performance: Ensure critical code continues to run from internal flash or RAM for optimal performance.

We would appreciate it if you could share any relevant documentation, examples, or best practices for achieving this configuration using the nRF Connect SDK.

[Turbo J]

Non memory mapped SPI means you need to read the data into RAM before you can use it at all.

Software development sounds a bit difficult (but technically possible) - consider adding the QSPI flash chip from the DK to your design. That one can be used as additional flash memory as it is memory-mapped. 

[Lavanya_Manohar]

We are currently in the production phase of our device based on the nRF7002 DK. The hardware is finalized, and we are not using QSPI flash — only SPI-based external flash for storage, which is non-memory-mapped. Therefore, we cannot make hardware changes or switch to QSPI flash at this stage.

Current Setup:

Internal Flash: 1 MB (nRF5340)

External Flash: 2 MB SPI flash (non-memory-mapped)

Protocols in use: BLE + Wi-Fi (currently implemented)

Internal flash usage: ~87% (approx. 783,768 bytes)

SDK Version: nRF Connect SDK v2.6.4

OpenThread: Not yet included

Our Goal:

1. We now need to include OpenThread alongside BLE and Wi-Fi in the same firmware. Given the current flash usage, we must reduce internal flash footprint to make room for the OpenThread stack.

Constraints:

1. No QSPI flash support; field updates are not possible.

2. All three protocols (BLE, Wi-Fi, OpenThread) must co-exist in the internal flash.

We are looking for guidance and support on the following:

1. Any Recommended steps or configurations to reduce internal flash usage while retaining BLE and Wi-Fi functionality.

2. Any modular or optional components in the BLE/Wi-Fi stacks that can be safely disabled or reduced.

3. Best practices to include OpenThread with minimal flash overhead.

4. Any example configurations where BLE + Wi-Fi + OpenThread are combined within 1MB internal flash on the nRF5340.

5. Any help on optimizing the build (e.g., Kconfig, linker changes, optional features to remove) would be greatly appreciated to help us move forward without hardware changes.