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

NRF54L20
I had been looking at https://www.nordicsemi.com/-/media/Publications/WQ-Product-guide/Nordic-Product-Comparison-table-WQ-Dec-2024.pdf so was not aware the NRF54L20 was released! That's great that its been released! We could consider it - how do i get hold of an EVK? Mouser etc show no stock.

Flash savings:

overlay-memory-optimized.conf used marginally more flash (so confirms that its mostly RAM optimizations)

FYI - some flash saving measures I've found - and for others reading the thread in future:

CONFIG_WIFI_NM_WPA_SUPPLICANT_WPA3=n # 17KB flash saving

CONFIG_NET_IPV6=y # saves 36KB, a problem if we want thread/matter? breaks fota, but may be solvable (downloader fails).

Of course disabling the shell is also significant (around >30KB). Inconvenient for development though.

XiP / Wifi Patches


Do you know why XIP not supported on the EVK?

Do you know how much RAM will be used using externally stored patches loaded into RAM? I'd like to know this before trying it as it's a dead end if its the full 83KB thats stored in flash.

Regards

Dan

CONFIG_TFM_PROFILE_TYPE_MINIMAL=y fails for IOT core example - the SSL relies on it. The options selected for the example use basically the full 128KB (122KB) and you can't really save the rest because of the alignment restrictions - less of a problem on the 54 series, so thanks for sharing that link too.

[Elfving]

Hope you've had a nice week-end Dan,

ddavson said:

I had been looking at https://www.nordicsemi.com/-/media/Publications/WQ-Product-guide/Nordic-Product-Comparison-table-WQ-Dec-2024.pdf so was not aware the NRF54L20 was released! That's great that its been released! We could consider it - how do i get hold of an EVK? Mouser etc show no stock.

Please contact your local RSM for that, or let me know if you need her contact info. For that though I would need to make the case private, since I do not want to spread that info into the open.

ddavson said:

Do you know why XIP not supported on the EVK?

I believe this is because the flash on that is connected with SPI, and you need QSPI for XiP.

ddavson said:

Do you know how much RAM will be used using externally stored patches loaded into RAM? I'd like to know this before trying it as it's a dead end if its the full 83KB thats stored in flash.

You can transfer it in configurable chunk sizes.

ddavson said:

CONFIG_TFM_PROFILE_TYPE_MINIMAL=y fails for IOT core example - the SSL relies on it. The options selected for the example use basically the full 128KB (122KB) and you can't really save the rest because of the alignment restrictions - less of a problem on the 54 series, so thanks for sharing that link too.

Glad it works on devices with a larger flash. So yeah, if I understood you correctly, that was not really a question

Regards,

Elfving

[ddavson]

I have successfully configured WiFi firmware patches to be stored in external flash (MX25R64) and managed by MCUboot as a multi-image setup. The device boots and runs correctly with the patches in external flash. I can perform FOTA updates of the application, but am unsure of the best approach for updating the FW patches.

CONFIG_NRF_WIFI_FW_PATCH_DFU remains disabled despite all documented dependencies being met.

I have tried CONFIG_NRF_WIFI_FW_PATCH_DFU=y in both:
- prj.conf
- boards/nrf7002dk_nrf5340_cpuapp_ns.conf

✓ CONFIG_NRF_WIFI_PATCHES_EXT_FLASH_STORE=y
✓ CONFIG_PARTITION_MANAGER_ENABLED=y  
✓ CONFIG_BOOTLOADER_MCUBOOT=y
✗ CONFIG_NRF_WIFI_FW_PATCH_DFU=y (set in prj.conf but shows as "not set" in build/.config)

After building, the generated .config shows:
# CONFIG_NRF_WIFI_FW_PATCH_DFU is not set

Partition Layout (pm_static.yml):
---------------------------------
- mcuboot_secondary (0x0, 0xe4000) - App secondary
- nrf70_wifi_fw_mcuboot_pad (0xe4000, 0x200)
- nrf70_wifi_fw (0xe4200, 0x20000)  
- mcuboot_primary_1 (0xe4000, 0x21000)
- mcuboot_secondary_1 (0x105000, 0x21000)

Questions:
----------
1. Why is CONFIG_NRF_WIFI_FW_PATCH_DFU not being enabled? Are there hidden dependencies?

2. How should I configure FOTA updates for WiFi firmware patches when using AWS IoT FOTA library? Currently, AWS FOTA treats all updates as application updates (image 0), causing WiFi patch binaries to be written to the wrong slot.

3. Should I be trying to get MCUboot to handle it, or do I need to intercept download and overwrite it in the application? Is there documentation I'm missing?

4. Is there example code or documentation for performing OTA updates of WiFi patches stored in external flash with MCUboot multi-image support?

Files available upon request:
-----------------------------
- Complete prj.conf and board configs
- pm_static.yml  
- sysbuild.conf
- Build logs showing config resolution

Thank you for your assistance.

[Elfving]

Thanks for the patience

ddavson said:

1. Why is CONFIG_NRF_WIFI_FW_PATCH_DFU not being enabled? Are there hidden dependencies?

Could be some missing dependency. Does the build log mention it? It typically says something along the line of "trying to set the config to this, but it got that value instead".

ddavson said:

2. How should I configure FOTA updates for WiFi firmware patches when using AWS IoT FOTA library? Currently, AWS FOTA treats all updates as application updates (image 0), causing WiFi patch binaries to be written to the wrong slot.

This, and the rest regarding OTA for patches I am not sure about, I've forwarded this to the relevant R&D team to see if they have an idea. I'll let you know once I hear from them.

Regards,

Elfving

[Elfving]

ddavson said:

2. How should I configure FOTA updates for WiFi firmware patches when using AWS IoT FOTA library? Currently, AWS FOTA treats all updates as application updates (image 0), causing WiFi patch binaries to be written to the wrong slot.

The wifi fw patch FOTA process is same as app and net images. The device can use nrf FOTA library to finish firmware download and MCUBoot to do swap afterwards. Looks some customer has made this work with their http server: https://devzone.nordicsemi.com/f/nordic-q-a/122242/nrf5340-nrf7002-multi-image-https-fota. AWS should be able to handle this as http sever.

ddavson said:

3. Should I be trying to get MCUboot to handle it, or do I need to intercept download and overwrite it in the application? Is there documentation I'm missing?

Have a look here.

ddavson said:

4. Is there example code or documentation for performing OTA updates of WiFi patches stored in external flash with MCUboot multi-image support?

You do for instance have this matter sample.

Regards,

Elfving

[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