Big primary image prevents FOTA

[Paul Kajdewicz]

Hey there,

while developing a rather huge application (~97% FLASH used) for the nRF9160, we encountered the problem, that when triggering a FOTA via lwm2m, it fails.

The updatefile is downloaded correctly, but it's the update process which fails when executing after reboot with a  W: Not enough free space to run swap upgrade error.

The issue seems to be, that there is no completely free sector to swap (We are using the default CONFIG_BOOT_SWAP_USING_MOVE.updatescheme). So far this is the expected behaviour, but is it possible to recognise this state at compile time and throw an warning or even abort compiling when having FOTA activated?

This issue can be quite harmful to devices used in the field.

Thanks for your help :)

using:
nRF9160
ncs v.1.5.1
zephyr v.2.4.99

[Håkon Alseth]

Hi,

 

I double-checked internally with the developers.

You are correct. the last page is reserved for swap/move operations. 

but is it possible to recognise this state at compile time and throw an warning or even abort compiling when having FOTA activated?

This is a great suggestion, which was also supported by the developer I talked to. I'll make a internal bug report/feature req on this matter. Thank you very much for reporting this issue back to us and making us aware of this restriction. I hope you have a wonderful weekend!

 

Kind regards,

Håkon 

[Stephan Walter]

Hi Håkon,

Any news on this?

We just ran into the same problem of accidentally uploading an image that is too large for SWAP_USING_MOVE.

Due to another issue in mcumgr, the secondary slot cannot be cleared if it is already set to pending: https://github.com/apache/mynewt-mcumgr/issues/157

Best regards,

--Stephan W.

P.S. I just realized that a workaround is to define (in pm_static.yml) an empty partition of size 1 sector placed at the end of the primary slot. This will then cause the auto-generated partition "app" be one sector shorter. This latter size is what is seemingly used by the linker to determine if the code will fit. But this is hardly intuitive.

[S Biezeman]

Hey Stephan,

We ran into the same problem as you did and to prevent it from happening we would like to implement your work around but this seems to cause the partition manager to signify data overlapping issues and/or shrink the bootloaders accecable partition.

Could you share some of your configs so we might be able to better define ours

Thanks in advance!

regards,

S Biezeman

[Stephan Walter]

Hi,

simply add a partition to pm_static.yml at the end of the flash address space:

unused:
  address: 0xfe000
  size: 0x2000

The partition manager will automatically resize the "app" partition to the available space.

We ended up reserving 2 flash sectors, to account for the image trailer but I don't remember the details.