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

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

Menon — Wed, 09 Jul 2025 11:15:56 GMT

Hello,

No worries, happy to help.

Kind Regards,

Abhijith

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

Amira R. — Tue, 08 Jul 2025 19:36:55 GMT

Hi Abhijith,

I see now! Thank you so much for your help with my questions, this is the exact information I was looking for!

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

Menon — Tue, 08 Jul 2025 18:19:26 GMT

Hello,

The application core writes directly to the netcore's flash using IPC or shared memory (PCD RAM). So, when you update only the netcore, the old firmware gets overwritten and is no longer available.

This is the default behavior, and currently, netcore rollback is not officially supported. You can check the old DevZone thread I shared earlier for more details.

Also, take a look at this repository, the examples are a bit outdated, but they show how shared SRAM is used. The images you mentioned show the swap mechanism in action.

[quote user="Amira R."] if two separate partitions are maintained in external flash (one for the application core's secondary image and one for the network core's secondary image), and an update for just the network core gets triggered, would the network core's old firmware be swapped into external flash? Or would it be discarded?[/quote]

I think this is how a netcore rollback might be possible, but it hasn’t been officially tested or supported by Nordic. So I can't say for sure if it will work, and I won’t be able to provide much support, as I haven’t tried it myself.

Kind regards,
Abhijith

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

Amira R. — Mon, 07 Jul 2025 17:53:30 GMT

Hi Abhijith,

I really appreciate you taking the time to answer my questions!

I think I see now what you mean by rollback not being supported by the network core.

[quote userid="115767" url="~/f/nordic-q-a/122459/non-simultaneous-multi-image-dfu-ota-over-wifi-rollback-capabilities/541496"]the network core doesn’t have a separate flash area to store a backup of its firmware[/quote]

Would maintaining a partition in external flash be sufficient for rollback use when performing non-simultaneous updates? Or would the backup image need to be stored in the network core's internal flash?

For example, if two separate partitions are maintained in external flash (one for the application core's secondary image and one for the network core's secondary image), and an update for just the network core gets triggered, would the network core's old firmware be swapped into external flash? Or would it be discarded?

I only ask because in rereading the DevAcademy lesson on DFU for the nRF5340, I was under the impression that the old image for the network core could remain available via the swap mechanism shown in this photo for non-simultaneous updates:

and this photo for simultaneous updates:

But with the information you've provided, I'm assuming these photos are simply to illustrate the swap mechanism for firmware upgrades, and the same mechanism doesn't apply for downgrades/rollbacks?

Also, would there be anything preventing a "manual" rollback wherein downgraded firmware is loaded into the network core's secondary image slot (not via swap) and is then treated as an "update"?

Thank you again!

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

Menon — Fri, 04 Jul 2025 15:25:49 GMT

Hello Amira,

[quote user="Amira R."]

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!

[/quote]

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.

[quote user="Amira R."]What exactly do you mean when you say MCUboot "may" attempt to restore the image? Is it indeterminate behavior? [/quote]

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

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

Amira R. — Thu, 03 Jul 2025 20:41:43 GMT

Hi Abhijith,

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

[quote userid="115767" url="~/f/nordic-q-a/122459/non-simultaneous-multi-image-dfu-ota-over-wifi-rollback-capabilities/541381"] I believe you can follow an update sequence like this[/quote]

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.

[quote userid="115767" url="~/f/nordic-q-a/122459/non-simultaneous-multi-image-dfu-ota-over-wifi-rollback-capabilities/541381"]However, during this rollback, MCUboot may also attempt to "restore" the network core image[/quote]

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!

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

Menon — Thu, 03 Jul 2025 20:04:11 GMT

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.

[quote user="Amira R."]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? [/quote]

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).

[quote user="Amira R."]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"?[/quote]

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

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

Amira R. — Fri, 27 Jun 2025 16:43:42 GMT

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:

[quote userid="138329" url="~/f/nordic-q-a/122459/non-simultaneous-multi-image-dfu-ota-over-wifi-rollback-capabilities"]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? [/quote]

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?

[quote userid="115767" url="~/f/nordic-q-a/122459/non-simultaneous-multi-image-dfu-ota-over-wifi-rollback-capabilities/540723"]Is this DFU meant for both the nRF5340 and the nRF7002 companion chip?[/quote]

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

[quote userid="115767" url="~/f/nordic-q-a/122459/non-simultaneous-multi-image-dfu-ota-over-wifi-rollback-capabilities/540723"]And which core on the nRF5340 is managing Wi-Fi?[/quote]

The application core is currently managing WiFi.

[quote userid="115767" url="~/f/nordic-q-a/122459/non-simultaneous-multi-image-dfu-ota-over-wifi-rollback-capabilities/540723"]In the "Simultaneous Multi-Image DFU" section, there's a note that, although placed there, seems relevant to this topic.[/quote]

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!

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

Menon — Fri, 27 Jun 2025 13:11:36 GMT

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

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

Amira R. — Thu, 26 Jun 2025 16:48:13 GMT

Hi Abhijith,

Sounds good! Thank you for updating me, I'll check back in tomorrow.

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

Menon — Thu, 26 Jun 2025 14:20:08 GMT

Hello,

Just letting you know that I am looking into this ticket. I couldn’t take a proper look at it today, but I will get back to you tomorrow. Sorry for the delay.

Kind regards,
Abhijith