nrf9160 always recovers when updating applications

[llly]

Hello,

I used two samples, application_update and SLM, to test and try updating the app from application_update to SLM. I first downloaded the firmware of application_update v1 version to 9160, and the LED 1 on 9160dk lit up to indicate that the v1 version was being used. Then, I renamed the bin file of SLM to app_2RF9160dk_2.50_v2. bin and uploaded it to the server. Next, I pressed the button 1, 9160dk to download the v2 firmware normally (but in reality, it was SLM). After downloading, I pressed the button 1 again to update the app to SLM, 9160dk also successfully ran SLM,but after restarting, the bootloader restored the firmware to application_update, even though I had already called boot_writd_img_confirmed in the main function of SLM. I also try to call boot_is_img_confirmed in the main function of slm to check whether the firmware is confirmed. The return value is 0, indicating that it is normal.

When I tested with application_update, everything was fine. 9160 can switch between v1 and v2 versions without automatically restoring to the previous version, but replacing v2's bin with SLM is not possible. I don't know which step I overlooked or made wrong?

Thank you.

[JyriLehtinen]

The SLM-application is most likely built with a different partition table, as I assume you're not using same pm_static.yml (at least for the relevant parts).

Updating the application does not update the bootloader, so the bootloader in your DK is built with the partitions defined in your application_update build. This defines which address the bootloader will check when determining whether to revert the image or not.
Now, your SLM build probably has a different partition table, so when you call boot_writd_img_confirmed() it writes to a different address, defined by your partition table in that build.

[llly]

Are you referring to the differences here? If so, how should we modify the definition of this section？

[JyriLehtinen]

Well, the easiest solution might be to copy the generated partition file from the project which is originally flashed to the board (in your case, app_update/build/partitions.yml copied to slm/pm_static.yml, then add the following line to the SLM project CMakeLists.txt:

set(PM_STATIC_YML_FILE ${CMAKE_CURRENT_LIST_DIR}/pm_static.yml CACHE INTERNAL "")

Might not compile, but it's quick to try.

I'm not 100 % certain, but I think the main issue there is the mcuboot_primary/secondary, which need to have identical addresses and sizes (there's a trailer with mcuboot data in the end of the flash), but I'd say it's risky having mismatched storage etc.
I think West warns about multi-image builds without a static partition file, and this is why. In the worst case, you can brick devices by doing app updates, which end up editing critical data in the flash, in an unrecoverable manner.

[dejans]

Hi llly ,

Static partitioning is commonly used to ensure consistency between builds. You can read about configuring static partitions in the partition manager documentation. 

Best regards,
Dejan

[llly]

hi  dejans

Thank you for your help. I also think it's a partition issue, but I'm still researching how to adjust it. I tried to copy the content of app_update/build/partitions.yml to slm/pm_static.yml using JyriLehtinen's method, and added set(PM_STATIC_YML_FILE ${CMAKE_CURRENT_LIST_DIR}/pm_static.yml CACHE INTERNAL "") to the SLM project CMakeLists.txt, but there was an error during the build process

[llly]

hi JyriLehtinen

Thank you for your reply. I tried according to your method, but there was an error during the build.

I am now trying to directly port the code of app_update to SLM, so that there is no need to update from app_update to SLM, which can probably avoid partition issues