nRF5340 Production DFU

[AnujPathak]

Hi Nordic,

We are now in pre-production phase and till now we are MCUBoot serial recovery with slot 0/slot 1 in internal flash to have USB-CDC DFU capability.
Due to slotted internal flash (~432KB slot size) we are hitting flash size limitations and now exploring ways to utilize full flash.

We have explored and got "Simultaneous multi-image DFU" with MCUBoot Recovery (both app and net core) working. But the very first line in Simultaneous multi-image section read out as "The simultaneous update of multiple images is available for testing since nRF Connect SDK v1.7.0".

Since our device will be sealed pack and only option to update them is through USB interface. We would like to get some clarity on following questions. Please answer them keeping in mind that we are using v2.2.0

Q. Is "Simultaneous multi-image DFU" stable for prodcution build?

Even if answer to above question is no
Q. Is "MCUBoot Recovery" with netcore recovery are stable for production builds? anc can we use this fallback option as our primary way to update the devices

if not please suggest ways to extend application slot size.


Regards

[AHaug]

Hi,

Regarding both questions: To be certain I can answer with 100% confidence, could you elaborate some of your concerns regarding this? In general simultaneous is what we recommend that users do when migrating versions since that ensures that the firmware on the netcore is compatible with the firmware on the appcore. Doing them non-simultaneous can result in communication issues in between the cores since the Softdevice controller 

This case  nrf5340 multi-image DFU update over BLE 'Remote Error: In Value(3)' ? , more specifically this comment elaborates some of the incompatibilities you may face if you do nonsimultaneous updates when your migrating in between several major NCS versions

Let me know about the question I've asked and if the other case I've linked and supported clarifies things for you

Kind regards,
Andreas

[AnujPathak]

Thanks for reply.

We have got simultaneous working and are aware the non-simultaneous can leave app core / net core in inconsistent state.
1. We just want to confirm that the Simultaneous DFU feature is still experimental or production ready ? Because SDK document still says "The simultaneous update of multiple images is available for testing since nRF Connect SDK v1.7.0".
Since our devices are completely sealed pack we'll be relying on robustness of bootloader for device lifetime once that is programmed.
2. Since secondary slots will be hosted on external NAND (8Gb in our case) with our custom driver. Can we always fallback to "MCUBoot Recovery with netcore" mode to write to app/net core directly bypassing external NAND ?

Regards

[AHaug]

Hi,

AnujPathak said:

1. We just want to confirm that the Simultaneous DFU feature is still experimental or production ready ? Because SDK document still says "The simultaneous update of multiple images is available for testing since nRF Connect SDK v1.7.0".

Noted, thank you for clarifying. Then I can with certainty say that simultaneous DFU is production ready for the nRF5340.

AnujPathak said:

2. Since secondary slots will be hosted on external NAND (8Gb in our case) with our custom driver. 

In general only SPI NOR flashes are supported so mostly out of curiosity could you verify if you've successfully implemented a custom driver to perform DFU using the external NAND flash?

AnujPathak said:

Can we always fallback to "MCUBoot Recovery with netcore" mode to write to app/net core directly bypassing external NAND ?

If you're referring to this part of the documentation, then the answer is yes, and as the documentation states then mcuboot_primary_1 must be used as the RAM partition mediator. MCUboot recovery of the appcore will also work as described in mcuboot recovery of the application, but it will need a secondary slot either on internal or external flash to store the new firmware image

https://github.com/hellesvik-nordic/samples_for_nrf_connect_sdk/tree/main/bootloader_samples/serial_recovery contains 

Kind regards,
Andreas

[AnujPathak]

Hi,

AHaug said:

Noted, thank you for clarifying. Then I can with certainty say that simultaneous DFU is production ready for the nRF5340.

Thanks for confirming that simultaneous DFU is production ready. SDK Document line "The simultaneous update of multiple images is available for testing since nRF Connect SDK v1.7.0" not clear, and give a sense that it is still available for testing only. We suggest to update the document to reflect the production readiness of the feature.

AHaug said:

In general only SPI NOR flashes are supported so mostly out of curiosity could you verify if you've successfully implemented a custom driver to perform DFU using the external NAND flash?

Yes we are using a custom NAND driver with our bad block management to make sure images are not corrupted. It was working fine as per our internal testing.

AHaug said:

If you're referring to this part of the documentation, then the answer is yes, and as the documentation states then mcuboot_primary_1 must be used as the RAM partition mediator. MCUboot recovery of the appcore will also work as described in mcuboot recovery of the application, but it will need a secondary slot either on internal or external flash to store the new firmware image

Yes we referring to same section and this will add a fallback routine to recover/update devices even if NAND has any issue. But i think secondary slot is not needed to app core recovery process. but it should be defined in partition yaml and dts files. Right?

Regards