NRF91 SLM FOTA from NCS 1.9.1 to NCS 2.0.0 failing

[Konstantin Klitenik]

We are seeing FOTA fail when updating from SLM using NCS 1.9.1 to SLM using NCS 2.0.0.

In summary, it appears that when NCS 2.0.0 image boots up, it never confirms and is then reverted back to NCS 1.9.1.

Details:

1. Start OTA download. Download completes successfully. I can see new image in the secondary slot.

2. Restart SLM using XRESET AT command. The new application boots up but does not report XOFTA=5,x status.

3. Reading FOTA=6 status, only shows NCS 2.0.0 image in the primary slot. It also results in the `slm_fota: failed in area 7 banker header: -5` message.

4. After waiting several minutes and issuing another XRESET, the SLM reboots back into NCS 1.9.1 image and sends XFOTA=5,-9 status. Doing XFOTA=6, shows NCS 1.9.1 image in the primary slot and NCS 2.0.0 image in the secondary slot.

00> [00:03:31.328,826] <inf> dfu_target_mcuboot: MCUBoot image upgrade scheduled. Reset device to apply
00> *** Booting Zephyr OS build b05b8ad63acf  ***
00> I: Starting bootloader
00> I: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
00> I: Secondary image: magic=good, swap_type=0x2, copy_done=0x3, image_ok=0x3
00> I: Boot source: none
00> I: Swap type: test
00> I: Bootloader chainload address offset: 0x10000
00> I: Jumping to the first image slot
00> *** Booting Zephyr OS build v3.0.99-ncs1  ***
00> 
00> [00:00:00.463,958] <inf> slm: Serial LTE Modem
00> [00:00:00.563,781] <inf> silvertree: SLM AT ST Init
00> [00:00:00.569,396] <inf> slm_at_host: at_host init done
00> [00:00:31.202,606] <wrn> slm_fota: failed in area 7 banker header: -5
00> *** Booting Zephyr OS build b05b8ad63acf  ***
00> I: Starting bootloader
00> I: Primary image: magic=good, swap_type=0x2, copy_done=0x1, image_ok=0x3
00> I: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
00> I: Boot source: none
00> I: Swap type: revert
00> I: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
00> I: Bootloader chainload address offset: 0x10000
00> I: Jumping to the first image slot
00> *** Booting Zephyr OS build b05b8ad63acf  ***

We are able to successfully OTA from NCS 2.0.0 image to another image also using NCS 2.0.0. But OTAing from NCS 1.9.1 image fails.

[AHaug]

Hi,

There has been a change in MCUBOOT from NCS v1.x.x to NCS v2.0.0 including reduction of the mcuboot partition such that v2.0.0 firmware expects that the new image is placed at a different address than in v1.9.1 and the other way around. This leads to firmware upgrade and/or downgrade (v2.0.0 -> 1.x.x) not beeing succesful.

I will check around if there are any simple workarounds to make this work.

Ps: I see that my statement about the version changes are not documented on the infocenter pages for MCUboot yet, so I will ask the developers about this aswell.

Kind regards,
Andreas

[AHaug]

Hi again,

I've verified the things from above and have a suggestion for you to try:

• The default size of MCUBOOT is 48KB on both v1.9.1 and v.2.0.0
• The change from v1.9.1 to v2.0.0 is the replacement of SPM (64KB) to TF-M minimal (48KB). This makes start offset of application different
  • On V1.9.1 the application start address is 0x20200
  • On V2.0.0 the application start address is 0x1c200

This is what causes the application to revert back to the original image.

You can try to enable CONFIG_TFM_CMAKE_BUILD_TYPE_DEBUG=y to make TF-M size 64KB. This should make the start addresses the same.

Let me know if this works out,

Kind regards,
Andreas

[Konstantin Klitenik]

Thanks, AHaug. We made a decision to just create a static partition table to keep the address offset the same. From our point of view, we can consider this resolved. But I imagine (and hope) we're not the only ones using SLM so you may want to have some sort of update to the repo.

[AHaug]

Hi,

Noted, then we will consider this as resolved from a tech support view as well.

Regarding information about an update of the repo, you will need to contact your local Regional Sales Manager for more information about future plans and road maps for feature/development of the SDK unless the information is publically available on our web pages. Send me a PM if you need the RSMs contact information and I'll send it to you.

Kind regards,
Andreas