Non-simultaneous multi-image DFU OTA over WiFi? Rollback capabilities?

[Amira R.]

Hello,

I'm looking for answers and some explanation for two main questions - is it possible to perform non-simultaneous multi-image FOTA over WiFi? Is it possible to support update rollback for both cores on the nRF5340?

For context, I'm currently working with a custom board that features the nRF5340 (running custom application on application core, HCI IPC sample on network core), nRF7002, and external SPI-NOR flash (where all new images are being stored and swapped). The company I work for maintains a private server from which images are downloaded via HTTPS, and we're looking to support rollback functionality for at least the application core, but ideally for the network core, as well. 

I've seen some threads, such as this one, that suggest that this capability is not supported at all due to the reason mentioned in the documentation for simultaneous multi-image updates. Additionally, in taking the complete DevAcademy NCS Intermediate course (being sure to read through the DFU lessons multiple times), I saw it mentioned why non-simultaneous updates are discouraged for the nRF5340.

So, if simultaneous multi-image updates prevent rollback capability, and the usage of BLE for DFU prevents non-simultaneous updates from being feasible for the nRF5340, I feel the resultant predicament begs the question, wouldn't a non-simultaneous multi-image update work fine in my use case? Since the network core is only running the HCI IPC sample and DFU is taking place over WiFi via the nRF7002, in the event that the interface between the cores changes, the host MCU would still be able to download and apply the network core's update despite not being able to communicate with it, right? Or are there other interactions between the cores that are necessary for the host's operation and would prevent it from updating the network core? 

I'm not seeing much more documentation on the topic of non-simultaneous multi-image updates other than them not being recommended for FOTA, so I can't tell if this is a lost cause, but if they are feasible, then wouldn't update rollbacks for either core also be feasible? 

Thank you!

[Menon]

Hello,

Is non-simultaneous multi-image FOTA over WiFi possible on the nRF5340?

Yes, non-simultaneous multi-image FOTA over Wi-Fi on the nRF5340 is possible, as long as the update image is correctly placed in the secondary application slot. MCUboot will then handle distributing the firmware to the appropriate cores (Application and Network).

Whether non-simultaneous DFU is suitable depends on which cores are involved:

• If only one core needs updating, then non-simultaneous DFU is fine.

• If both cores need to be updated, then a simultaneous DFU is recommended to avoid interrupting the Wi-Fi transport during the process.

  Another thing to check : Is this DFU meant for both the nRF5340 and the nRF7002 companion chip? And which core on the nRF5340 is managing Wi-Fi?

This matters because if the core handling Wi-Fi is being updated, you must ensure the connection stays stable during the DFU. In that case, a simultaneous update may be necessary.

Can rollback functionality be supported for both cores (application and network) on the nRF5340?

Take a look at the section on downgrade prevention and also refer to this older DevZone ticket.
In the "Simultaneous Multi-Image DFU" section, there's a note that, although placed there, seems relevant to this topic.
Rollback support for the network core is not available.

Kind Regards,

Abhijith

[Amira R.]

Hi Abhijith,

Thank you for your response! My apologies, I realize I forgot to include some details that I think would provide more clarity.

With the way our deployment process is set up, only one image would be downloaded at a time, so if both cores (and/or the companion chip) needed to be updated, the updates would be applied sequentially rather than simultaneously. And to avoid potentially bricking a unit, the order in which images would be available on the server would be determined based on firmware interdependencies.This was the motivation behind this question:

Amira R. said:

Or are there other interactions between the cores that are necessary for the host's operation and would prevent it from updating the network core? 

In the event that the application core gets updated with firmware that changes the interface with the network core (so they can no longer communicate), will the application core still be able to download the network core's new image via WiFi and then perform the network core's update? 

Menon said:

Is this DFU meant for both the nRF5340 and the nRF7002 companion chip?

Yes, we'd like to support update capability for the nRF7002, as well (also non-simultaneously).

Menon said:

And which core on the nRF5340 is managing Wi-Fi?

The application core is currently managing WiFi.

Menon said:

In the "Simultaneous Multi-Image DFU" section, there's a note that, although placed there, seems relevant to this topic.

I mentioned this note in my original post, but I realize my actual question may have not been apparent - is this reversion issue a byproduct of simultaneous updates? What exactly is meant by "the reversion process fills the network core with the content currently in the RAM that PCD uses"?

Regarding downgrade prevention, I understand its use and purpose, but for my work's use case, version control is carefully managed internally - though downgrading is never part of the plan, having the ability to roll back any deployed firmware is critical, which is why I'm interested in knowing the feasibility of rollback support for this chip.

Thank you!