This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Big primary image prevents FOTA

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

Parents
  • 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 

  • 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.

  • 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

Reply Children
Related