Zigbee FOTA limitation on NRF5340

RE: Zigbee FOTA limitation on NRF5340

Sigurd Hellesvik — Mon, 08 Jan 2024 08:28:16 GMT

[quote user="Sigurd Hellesvik"]I will ask our bootloader developers on what they recommend here. I am curious myself to our take on robusteness here. However, as it is the christmas vacation now, I will ask them in January.[/quote]

I think this was the only one I should pick up on right:

Our developers confirm what you say: FOTA for the nRF5340 is at the moment less robust that for our single-core chips. This is something we are working on improving.

For now, I suggest being extra vigilant on testing new applications to prevent errors to happen.

If you have serial access to the nRF5340, you could also enable Serial Recovery, which enables you to recovery the device over serial if FOTA breaks the application.

RE: Zigbee FOTA limitation on NRF5340

Sigurd Hellesvik — Fri, 22 Dec 2023 14:12:31 GMT

[quote user="bilal337"]Bridge - Firmware will be downloaded in Nrf9160 and through UART it will be sent to nrf5340. [/quote]

We got a sample for this at Evaluating LwM2M Advanced Firmware Update for external MCU. This would be similar for non-LwM2M applications as well. Download the firmware and then send it via DFU Target to the external chip over UART.

[quote user="bilal337"]Zigbee FOTA Limitation - developer.nordicsemi.com/.../zigbee_fota.html[/quote]

Right, I remember the limitation now. The nRF5340 has two slots in this mode, but it can not revert the image when doing SImultaneous multi-image updates:

" CONFIG_BOOT_UPGRADE_ONLY - The simultaneous update of multiple images does not support network core image reversion, so you need to disable application image reversion. "

We do not provide any fix for this yet. You can turn on revertion, but then need to handle the consequences yourself.

MCUboot will still verify the signature and hash of the image, so a corrupted image should not be booted.

[quote user=""] we'd appreciate insights into potential mitigation strategies for handling corrupted firmware images during the update process, particularly regarding bootloader and critical functionality impact.[/quote]

I will ask our bootloader developers on what they recommend here. I am curious myself to our take on robusteness here. However, as it is the christmas vacation now, I will ask them in January.

RE: Zigbee FOTA limitation on NRF5340

bilal337 — Fri, 22 Dec 2023 13:57:51 GMT

Bridge - Firmware will be downloaded in Nrf9160 and through UART it will be sent to nrf5340.

Zigbee FOTA Limitation - developer.nordicsemi.com/.../zigbee_fota.html

RE: Zigbee FOTA limitation on NRF5340

Sigurd Hellesvik — Fri, 22 Dec 2023 13:30:30 GMT

[quote user="bilal337"]Bridge - Firmware is stored on Aws s3 bucket. The device will call an API and firmware will be downloaded in MCU it will do security verification. If the firmware is for bridge it will update itself. [/quote]

The bridge is both the nRF9160 and nRF5340. How does this process affect each of these?

[quote user="bilal337"]But in the case of sensors, the bridge will call an API download the firmware, and will do security verification and after that, the bridge will send it to the sensor via Zigbee protocol. The issue here is that nrf5340 only support single bank and not a dual bank OTA, Meaning it will delete the previous firmware and then write the new firmware and in case new firmware is corrupted the device will not work anymore.[/quote]

I am not very familiar with ZigBee FOTA specifially, but in the nRF Connect SDK MCUboot FOTA is is in all cases I have seen dual bank. Can you link to where you learned that this is single bank, so I can have a look at it?

RE: Zigbee FOTA limitation on NRF5340

bilal337 — Fri, 22 Dec 2023 13:18:48 GMT

Bridge - Firmware is stored on Aws s3 bucket. The device will call an API and firmware will be downloaded in MCU it will do security verification. If the firmware is for bridge it will update itself.

But in the case of sensors, the bridge will call an API download the firmware, and will do security verification and after that, the bridge will send it to the sensor via Zigbee protocol. The issue here is that nrf5340 only support single bank and not a dual bank OTA, Meaning it will delete the previous firmware and then write the new firmware and in case new firmware is corrupted the device will not work anymore.

RE: Zigbee FOTA limitation on NRF5340

Sigurd Hellesvik — Fri, 22 Dec 2023 12:33:32 GMT

Hi,

You want to update two things, the sensor and the bridge, right?
For each of those, can you explain where the DFU is sent from?
For example, does the sensor receive DFU over UART from the bridge?

Regards,
Sigurd Hellesvik