AWS IOT example - utilizing ~92.5% flash without configuration changes on 7002DK

[ddavson]

Hi Nordic Support Team,I'm experiencing severe memory constraints with the AWS IoT Core example on the nRF7002DK (nRF5340) that make it impractical for real-world applications requiring WiFi provisioning and custom functionality.

Current Memory Usage:

Memory region         Used Size  Region Size  %age Used
           FLASH:      742308 B       784 KB     92.46%
             RAM:      327392 B       400 KB     79.93%
        IDT_LIST:          0 GB        32 KB      0.00%

I appreciate that the example includes comprehensive crypto and certificate handling, but the current memory footprint makes it challenging to build practical applications on top of it.

The AWS IoT Core example leaves only ~40KB of flash memory available, which is insufficient for adding WiFi provisioning logic and custom application code that would be required in a production scenario. 

Build Configuration:

• SDK: nRF Connect SDK v3.1.1

• Toolchain: nRF Connect SDK Toolchain v3.1.1

• Board target: nrf7002dk/nrf5340/cpuapp/ns

• Extra Kconfig fragments: boards/nrf7002dk_nrf5340_cpuapp_ns.conf

• Optimization level: Use project default

• Build directory: build

• System build (sysbuild):

• Build system default

• Use sysbuild: Yes

• No sysbuild: No

Key Configuration Details:

• Using external flash (mx25r64) for partition manager

• FOTA enabled (required for our use case)

• TF-m optimizations are applied.

Attempts Made:

1. Tried building without /ns suffix: Build failed

3. WiFi Firmware Patches: I understand these could potentially be moved to save space, but I've seen Nordic support advise against relocating them - seems complicated with FOTA, but does give 83KB. I was not able to get this to apply to the project successfuly.

Requirements:

• FOTA capability (non-negotiable)

• WiFi provisioning functionality

• IOT Core shadow states and telemetry.

• Production-ready security (not necessarily using TF-M). but SSL/https required.

Questions:

1. What would be the easiest Flash saving for a project based on this example, given that FOTA is needed.

2. What is the official guidance on building without TF-M (/ns) for production applications? What security implications should we consider?

3. Is there a way to optimize the TF-M memory allocation to reclaim some of the apparent 16KB waste in trustzone storage? Or shrink the 128KB it is taking?
   
   If its not possible to make quite big savings, I'll consider not using IOT core, but it requires doing all the telemetry and much more work on the FOTA manually.

Any guidance on the largest bang for buck memory optimization strategies or alternative starting point would be greatly appreciated.

Kind Regards

Dan

[Elfving]

Hi Dan,

You are right in that flash space can be a problem with the nRF7002 stack, unfortunately. We have some documentations with things that could be tried though, but what you can configure would of course depend on the application. Have you seen this, this and this for instance?

Is switching to the nRF54Ls an option for you?

Regards,

Elfving

[ddavson]

Hi,

Thanks for getting back to me.

Switching to the nRF54L will seemingly have too little RAM (max 256KB and we are at 80% with the example with 512KB+64KB? on the nrf53)? So that doesn't look viable.

Thanks for sharing those links, have come across them. While they do look worth exploring - most of them look like they are RAM saving measures. My expectation is that I'll manage to shave a few KB of flash, not 10s of KB using that alone.

Could you get back to me on XIP for the wifi patches? I can't find any clear documentation on how that interacts with FOTA.

Are my other questions regarding different ways of building (around the TF-M, potentially not using it) worth exploring?

Regards

Dan

 

[ddavson]

Hi, thanks the CONFIG_DFU_MULTI_IMAGE=y dependency was missing. There are still 2 issues I have though:

1. Multi-Image Package Build Error

When we enable:
    SB_CONFIG_DFU_MULTI_IMAGE_PACKAGE_BUILD=y
    SB_CONFIG_DFU_MULTI_IMAGE_PACKAGE_WIFI_FW_PATCH=y

The build fails with:
    FileNotFoundError: build/nrf70.signed.bin

I think sysbuild system tries to create dfu_multi_image.bin before nrf70.signed.bin is generated (build ordering issue).

2. The Matter bridge example demonstrates WiFi patch FOTA, which indicates MCUBoot can handle it, however the in the library used by the IOT core example, the fota_download library hardcodes img_num=0 when calling dfu_target_init() at line 183 of fota_download.c:

    err = dfu_target_init(img_type, 0, file_size, dfu_target_callback_handler);

This means WiFi firmware patches (nrf70.signed.bin) are always written to mcuboot_secondary (image 0) instead of mcuboot_secondary_1 (image 1), causing MCUboot to reject and revert the update.

MCUboot is correctly managing both images (we see "Image index: 0" and "Image index: 1" in boot logs), and application FOTA works fine. The issue is specifically that the FOTA library can't target image 1.

Note: We observed that Matter OTA handles WiFi patch updates using the dfu_multi_image API with combined packages, whereas AWS FOTA uses the fota_download API which hardcodes img_num=0 - is there a recommended way to integrate dfu_multi_image support into AWS FOTA?

[Elfving]

Hi again,

Considering this:

ddavson said:

The build fails with:
    FileNotFoundError: build/nrf70.signed.bin

Could you check if either of these are set?

Regards,

Elfving

[ddavson]

Hi Elfving

Thanks for looking into this - yes,SB_CONFIG_DFU_MULTI_IMAGE_PACKAGE_WIFI_FW_PATCH is set, as per:
https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/app_dev/device_guides/nrf70/nrf70_fw_patch_update.html

Regards
Dan

[Elfving]

Good.

I'm looking it the rest of your argument below. I'm getting the feeling that this could be a bug. I'll try to reproduce it sometime next week.

Regards,

Elfving

[Elfving]

I have someone from the relevant R&D team looking into this, though unfortunately it might take some time. 

So this is a rather complex feature, and currently works only with a one-time programmed firmware. For FOTA, the biggest concern is that if either the application or the nRF70 firmware patch is updated independently, a version mismatch may occur, which can lead to compatibility issues and potentially cause the Wi-Fi functionality to stop working.

What would be easiest by far would be switching to 54LM20. Its FOTA solution combines the application and the nRF70 firmware patch, which prevents such compatibility problems. Is that something you are still considering?

Regards,

Elfving

[ddavson]

Hi Elfving,

I appreciate that complexity - thanks for updating me. For this and other reasons, we've decided to go with a simpler approach, doing the OTA over BLE for the first product (using the 54 series).

Regards
Dan

[Elfving]

Understood. I'll let the R&D guy leave this for the time being then.

Let us know if there is anything else!

Regards,

Elfving