Not enough free space to run swap upgrade

RE: Not enough free space to run swap upgrade

Achim Kraus — Sun, 19 Oct 2025 14:09:48 GMT

[quote userid="9456" url="~/f/nordic-q-a/116293/not-enough-free-space-to-run-swap-upgrade/511281"]It can happen during development, but it should never happen with your end users, in the sense that the new image should be tested extensively before deployment.[/quote]

Just to add about the "tested extensively":

I currently saw some device reporting:

I: Starting bootloader
I: Primary image: magic=good, swap_type=0x2, copy_done=0x1, image_ok=0x1
I: Secondary image: magic=good, swap_type=0x2, copy_done=0x3, image_ok=0x3
I: Boot source: none
I: Image index: 0, Swap type: test
I: Starting swap using move algorithm.
W: Not enough free space to run swap upgrade
W: required 425984 bytes but only 421888 are available
I: Bootloader chainload address offset: 0xc000
I: Jumping to the first image slot

while other applied that update without issues.

In both cases I used the same application version before and the same application version to update to. The only difference was, that some devices have been for longer in the field. My analysis showed then, it occurs with the McuBoot of NCS 2.6.4 (this devices will not be able to update the application without updating the McuBoot), but using the McuBoot of NCS 2.9.2 the bigger image works.

Conclusion:

It's not enough to only test, if the image could be applied to the previous version ... you will need to test it with all McuBoot version in field ;-(.

And if you have McuBoot of 2.6.4 (or earlier) in the field, you will need to check you maximum image size with that.

RE: Not enough free space to run swap upgrade

Hieu — Wed, 20 Nov 2024 12:32:54 GMT

Hi,

I will continue to support you on this case.

[quote user="JH7"]

I'm thinking in the scenario where my product is released and the only way to update it is over BLE.

[...]

Can this be executed over BLE?

[/quote]

Yes, it can. Please try to do so with our Device Manager app.

[quote user="JH7"]If I understand your suggestions, there will always be the possibility of having a bigger image that would lead to this problem, no matter how I adjust the application and partitions, right?[/quote]

It can happen during development, but it should never happen with your end users, in the sense that the new image should be tested extensively before deployment.

[quote user="JH7"]It looks like the options are: change the MCUBoot code to check the size[/quote]

I believe what Susheel recommended was to change the application code to check the size, rather than MCUboot.

[quote user="JH7"]make it erase the secondary partition[/quote]

This is a reasonable approach.

[quote user="JH7"]try to control the access to the BLE OTA (let only authorised apps to update firmware).[/quote]

For most applications, this is recommended regardless. The only exception I can think of is a hacking/development platform.

[quote user="JH7"]Do you have any other idea?[/quote]

Your mobile app can also pre-emptively erase the flash area after a failed attempt, depends on the failure reason.

Obviously, this doesn't help the end-user having to sit through the entire download time. However, this issue should be circumvented altogether by testing the new application before deployment to end-users, like I mentioned above.

Hieu

RE: Not enough free space to run swap upgrade

JH7 — Tue, 12 Nov 2024 21:36:07 GMT

Hi Susheel, thanks for your reply.

I'm thinking in the scenario where my product is released and the only way to update it is over BLE.

mcumgr -t 5 -c <connection_type> flash erase <secondary_slot_offset> <size>

Can this be executed over BLE?

If I understand your suggestions, there will always be the possibility of having a bigger image that would lead to this problem, no matter how I adjust the application and partitions, right?
I could make sure to test a new image everytime before releasing it, but I'm thinking this can also be a vector of attack as a malicious user could prevent updates only by uploading an invalid image that is too big. Does it make sense?

It looks like the options are: change the MCUBoot code to check the size, make it erase the secondary partition, and/or try to control the access to the BLE OTA (let only authorised apps to update firmware).

Do you have any other idea?

Thank you!

RE: Not enough free space to run swap upgrade

Susheel Nuguru — Tue, 12 Nov 2024 08:17:03 GMT

I am not expert in this, but searching for some info here are my few thoughts

Considering the constraints of flash memory and the issues with OTA updates when larger apps (like app3 with CONFIG_SHELL=y) push memory usage to its limit, here are some ways to address each question:

[quote user=""]1 - If there's no space to swap, why the bootloader lets the upload to start? How to prevent that?[/quote]

The bootloader, MCUboot in this case, doesn't automatically verify available swap space before beginning an upload. To mitigate this, you might look into two possible approaches:

Configure a Pre-Upload Check in the Application: Adding a check within the application using mcumgr commands or a custom routine to assess available swap space before initiating a DFU update could help. Keep in mind that this requires custom logic, as MCUboot doesn’t currently halt uploads based on space limitations.
Expand the Swap Partition (if feasible): Adjusting your partition setup to enlarge the swap area might make larger uploads possible, depending on the available flash space. You can modify pm_static.yml to reallocate memory for secondary images if needed.

[quote user=""]2 - If an image fails to upload completely for any reason, how to erase it from flash so it does not block future updates?[/quote]

To clear a failed image from flash:

Erase the Secondary Slot Using mcumgr: The mcumgr tool has commands that can erase sectors or flash regions. You could run the following command to erase the secondary slot:
```
mcumgr -t 5 -c <connection_type> flash erase <secondary_slot_offset> <size>
```
Replace <secondary_slot_offset> and <size> with values from your partition layout; for instance, mcuboot_secondary begins at 0x51000 and spans 0x2F000 (188kB) in your case.
Reboot and Retry the Upload: After erasing, reboot the device to let MCUboot clear any flags related to the prior upload, then try uploading a smaller image like app2.

[quote user=""]3 - If this is something related to a specific NCS/Zephyr/MCUboot version, could you point an older version that doesn't show this issue?[/quote]

This is likely due to partition size rather than a specific bug in recent versions. Still, some potential options include:

Testing a Smaller Application Version: Temporarily reducing the app size by disabling some features could make DFU uploads more manageable.
Trying nRF Connect SDK v2.6.x: This version may handle partitions and memory slightly differently. Running a test build with v2.6.x could highlight any improvements in memory management.

Implementing these strategies should help manage space limitations during DFU updates. Also, fine-tuning your partition layout and reducing the application’s footprint may prevent similar issues in future updates.