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!

[Menon]

Hello Amira,

Sorry for getting back to you a bit late. It's the summer vacation period here, which caused some delay in following up on this issue.

Thanks for clarifying a few things.

Amira R. said:

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? 

I was thinking about this as well, and I believe you can follow an update sequence like this: first update the network core (nrf5340_cpunet), then the application core (nrf5340_cpuapp), and finally update the 7002_FW. During the network core update, the application core will still be running the old firmware, which is guaranteed to be compatible with the old network core and was also designed to safely handle flashing the new network core firmware. Since you have version control in place and carefully manage which versions work together, you can be confident that the old application firmware can safely perform the update without issues. I'm checking this with my colleague to confirm whether it's correct, but since many people are on vacation, it's taking a bit of time. I'll get back to you once I have a definite answer(Feel free to ping me if I forget, no worries at all). 

Amira R. said:

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"?

On the nRF5340, the application core is responsible for handling the DFU process. The network core firmware is first transferred to a special RAM buffer called the PCD area. This buffer temporarily stores the network core image in RAM before it gets written to the network core’s flash memory. See the section peripheral CPU DFU

Let's consider a case where a DFU process has been triggered, and a rollback occurs. If the new application core image fails to boot, MCUboot may initiate a rollback by restoring the previous application image from flash. However, during this rollback, MCUboot may also attempt to "restore" the network core image using whatever data remains in the PCD RAM buffer. Since this buffer may no longer contain a valid or complete image, MCUboot ends up writing invalid data to the network core's flash, which can lead to a corrupted or non-functional network core. 

Kind Regards,

Abhijith

[Amira R.]

Hi Abhijith,

Thank you for getting back to me! I appreciate the heads up regarding possible delays, that's very good to know!

Menon said:

I believe you can follow an update sequence like this

Something like this is just what I was looking for! I was having some trouble wrapping my head around what sequence would work but what you've outlined makes sense to me. I'll keep an eye out for confirmation!

And thank you for your explanation regarding how the application core utilizes the PCD area in RAM during the DFU process, however my question lies less in how it works and more in why it works that way. 

Menon said:

However, during this rollback, MCUboot may also attempt to "restore" the network core image

What exactly do you mean when you say MCUboot "may" attempt to restore the image? Is it indeterminate behavior? Or would it attempt to do so as a means of following suit with a simultaneous update (i.e. if images are updated simultaneously, they should also be rolled back simultaneously)? In the case you've presented, would the triggered DFU process be a simultaneous update or would it be sequential like what was discussed earlier?

Hopefully my questions make sense within this context, though please let me know if they don't and I can try to rephrase for clarity! 

Thank you again!

[Menon]

Hello Amira,

Amira R. said:

What exactly do you mean when you say MCUboot "may" attempt to restore the image? Is it indeterminate behavior? Or would it attempt to do so as a means of following suit with a simultaneous update (i.e. if images are updated simultaneously, they should also be rolled back simultaneously)? In the case you've presented, would the triggered DFU process be a simultaneous update or would it be sequential like what was discussed earlier?

Hopefully my questions make sense within this context, though please let me know if they don't and I can try to rephrase for clarity! 

Sorry for the confusion. I was trying to explain the process mentioned in the note (linked in one of my responses). I was describing a case of a simultaneous DFU process, specifically, how a rollback during a simultaneous update affects the network core, or simply what that note is trying to convey.

Although the note falls under the topic of simultaneous updates on the nRF5340, it actually highlights a deeper technical detail, the network core does not support rollback. Unlike the application core, the network core doesn’t have a separate flash area to store a backup of its firmware. This means that if you update it and something goes wrong, there’s no way to automatically revert to the previous version.

Amira R. said:

What exactly do you mean when you say MCUboot "may" attempt to restore the image? Is it indeterminate behavior?

If both cores are updated together, they should be rolled back together. In your case, since you're performing a sequential update, a rollback of the application core should be possible, but a rollback of the network core is not supported.

Kind Regards,

Abhijith