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.

[AHaug]

Hi,

Lavanya_Manohar said:

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.

This sentence has me worried.

Lavanya_Manohar said:

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

And this even more.

There are no way to currently fit all three protocols + your custom application within the internal flash. Concurrent use of three protocols simultaneously is also not something you can do without designing in proper multi-plexing and/or setting up multiple radios.

Lavanya_Manohar said:

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

WiFi memory optimization

• How locked are you to NCS v2.6.4?
  

  Lavanya_Manohar said:

  2. Any modular or optional components in the BLE/Wi-Fi stacks that can be safely disabled or reduced.
• Wi-fi has some memory optimization you may do. One of them are to store the Wi-Fi firmware patch in external flash as explained here https://docs.nordicsemi.com/bundle/ncs-2.6.4/page/nrf/device_guides/working_with_nrf/nrf70/developing/fw_patches_ext_flash.html 
• There's some general pointers to reducing WiFi memory usage here https://docs.nordicsemi.com/bundle/ncs-2.6.4/page/nrf/test_and_optimize/optimizing/memory.html#thread and here: https://docs.nordicsemi.com/bundle/ncs-2.6.4/page/nrf/protocols/wifi/index.html 

Lavanya_Manohar said:

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

https://docs.nordicsemi.com/bundle/ncs-2.6.4/page/nrf/protocols/thread/index.html does not contain any direct links to optimizing for OpenThread but https://docs.nordicsemi.com/bundle/ncs-2.6.4/page/nrf/test_and_optimize/optimizing/index.html contains some tips found here: https://docs.nordicsemi.com/bundle/ncs-2.6.4/page/nrf/test_and_optimize/optimizing/memory.html#thread 

Lavanya_Manohar said:

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

You say that you intend to have all three protocols on the internal flash. Have you considered two different versions of the application, one with BLE+Wifi and one with BLE+OpenThread that you DFU in from external flash when user boots the application? You can see a variant of this here in the Matter sample: https://docs.nordicsemi.com/bundle/ncs-2.6.4/page/nrf/samples/matter/lock/README.html#testing_switching_between_thread_and_wi-fi 

Maybe this is what you mean with " Is it possible to store certain parts of the code or read-only data in SPI-connected external flash "

Kind regards,
Andreas

[Lavanya_Manohar]

Hi,

1. We are currently using QSPI for the Wi-Fi interface. Is it possible to use the same QSPI peripheral for accessing external flash memory as well?
2. Which Nordic SoCs support using QSPI to interface with external flash memory in XIP (eXecute In Place) mode?

Best regards,
Amirtha N

[AHaug]

Hi,

Lavanya_Manohar said:

1. We are currently using QSPI for the Wi-Fi interface. Is it possible to use the same QSPI peripheral for accessing external flash memory as well?

The short answer to this one is that this is not possible.

This means that you have one QSPI connected from the nrf5340 to two chips (7002 + external flash), which means that you can not use both of them simultaneous. This means that any firmware patch offloading is not possible, and it means that you can not access anything on the external flash while the 7002 is running and v.v cannot use the 7002 while the external flash is using the qspi bus. Furthermore, how will you multiplex the 

If 2 implies that what you will be doing with the qspi in 1 is to execute code from the external flash and/or read/write to an external flash, then the answer is no. XIP is not a catch all solution if you're going over scope. You can only relocate code that can handle to be run slower than on the internal SoC flash. This means that you need to control every entrypoint in your firmware that will be entering into external flash to execute code. None of the code that you relocate can be timing critical or depending on any interrupts.

Lavanya_Manohar said:

2. Which Nordic SoCs support using QSPI to interface with external flash memory in XIP (eXecute In Place) mode?

Execute in place from an external flash over QSPI is only supported for the nRF5340. The nRF54L15 and nRF54H20 has some execute in place features where you can relocate to TCM and/or SRAM that is located on the SoC itself, but not from an external flash device.

Kind regards,
Andreas