nRF9160 modem firmware update OTA

[pemar13]

Hi!

Previous tickets 234795 and 231307 asked about the status of field updates of the nRF9160 modem firmware. Some solution is coming, but unclear when.

Are there any news on this crucial issue? Most importantly, will the coming solution be "backwards compatible" with what we deploy now (perhaps with some extra step, but not requiring any physical action)?

Best regards,

Per

 

[stevenminnick]

This is probably a stupid question but how do I find tickets 234795 and 231307?  If I search for them I get this one only.  And I can't edit the URL because the URL doesn't seem to contain the case ID. 

I'm looking for information about updating radio firmware and application code OTA and right now it's a big question for me.

[jbrzozoski]

Not a dumb question at all.  I can't figure it out either.  I answered based on the fact that modem FOTA has been a priority in our design and I actually check-in on the forum every few days and try to skim all newly updated topics, so assumed I had *probably* read them at some point in the past.

What are some of your questions/concerns about FOTA?

[jbrzozoski]

The primary example of how Nordic expects this all to work (which is mostly how my company's application also works) can be found in the sample application under nrf/samples/nrf9160/http_application_update in the NCS workspace.

Some key concepts of this method:

- internal flash is divided into 5 regions: a smallish area for the bootloader (mcuboot), two biggish regions for two alternate copies of your application and SPM, one small region for persistent NVS configuration items, and one small scratch region that mcuboot uses when swapping the two big regions (note there is no region for modem firmware, i'll get to that later)

- your application is always running out of the first big slot.  when you want to do an upgrade, your application has to push the new version into the second big slot along with some control flags that mcuboot will notice on the next reboot

- on a reboot, mcuboot will look at both slots to decide what it should do.  normally it will just validate the first slot looks good and boot into it.  alternatively, if it finds the control flags set, it will swap the contents of the two slots and *then* boot the first slot.  finally, if mcuboot is run after a swap-upgrade but without the application readjusting the control flags to say the upgrade was succesful, mcuboot will consider the swap-upgrade bad, and move the prior good code back from the second slot into the first slot and reboot.

The http_application sample uses a few libraries that automate a lot of these steps.  download_client is a library that knows how to download a file from an HTTP(S) server.  img_manager is a library that knows how to adjust the mcuboot control flags in flash. and fota_download is a supervisor library that knows how to coordinate the other libraries to take care of almost everything for you.  Once you trigger it, it will begin a download directly into the second slot, adjust the flags, and reboot when done.

Modem firmware upgrades aren't totally ready yet, but it looks like the fota_download library should be able to handle them in a very similar manner from the application point of view.  Instead of being written to flash, however, the download is handed off to the modem processor a chunk at a time and it will handle it from there.

[stevenminnick]

Thank you so much for walking through this, it's very helpful.  I did start looking at that http_application_update. 

If you would indulge me with some follow up questions.

The internal flash that's divided, that's the 1MB correct?  It's divided into those section?  So for round numbers, there is 2 "bigish" regions that are 500KB each, and my application code and SPM will need to reside in that space?  It's not that there are 2 1MB chunks that you switch between, it's 1 1MB.  I'm assuming so but just wanted to be sure.

If my code grows beyond 500K, does the application software update no longer apply?  Is it just not possible to grow the code beyond 500K?  I'm not saying I want to make a huge application, I was just curious what happens.

[jbrzozoski]

That is the 1MB region that is divided into 5 chunks, yes.  The default sizes of the regions appear to be:

#define PM_MCUBOOT_SIZE 0xc000
#define PM_MCUBOOT_PRIMARY_SIZE 0x69000
#define PM_MCUBOOT_PRIMARY_APP_SIZE 0x68e00
#define PM_MCUBOOT_SECONDARY_SIZE 0x69000
#define PM_MCUBOOT_SCRATCH_SIZE 0x1e000
#define PM_MCUBOOT_STORAGE_SIZE 0x4000

Note the differentiation of PRIMARY_SIZE and PRIMARY_APP_SIZE ... the mcuboot configuration flags actually exist at the tail end of the two big slots, and that's trying to show how your app has to be a tiny bit smaller than the slot.

I'm not sure what happens if your application gets bigger than the slot size. These regions are configurable, but I haven't figured out how yet.  In a pinch you could probably ditch the STORAGE region if you aren't using NVS, or you can shrink the SCRATCH region although it will wear out faster if you do too many mcuboot swap-upgrades.

[jbrzozoski]

I suspect builds will fail if you get too big, based on the size reports generated when compiling.

[72/81] Linking C executable zephyr\zephyr_prebuilt.elf
Memory region         Used Size  Region Size  %age Used
           FLASH:      332984 B     380416 B     87.53%
            SRAM:       97180 B       128 KB     74.14%
        IDT_LIST:         168 B         2 KB      8.20%

I'll let you know when I hit it.  Looks like I'm getting close, but I've got a lot of unnecessary debug prints and asserts in there, so...

[lobaro-theo]

if your application gets bigger than the slot the mcu-boot sign python script will fail so this is save.