nrf5340 and mcuboot simultaneous update over serial port

[Marko_P]

I am working on nrf5340dk board with 2.6.1 SDK and toolchains.

So, I took "mesh_shell" project as a starting point, then added external flash and mcuboot with simultaneous update support and then made my partitions static. List of partitions is below, AFAIK it is ok.

Then I configured mcuboot for serial recovery and added shell and mcumgr server (over shell) to the app. Everything seemed ok, mcumgr (go client) talked to mcuboot and the app over the serial port (e.g. "image list").

1. Last thing I want to do is update the board over BLE mesh, but before that (at least as I understand it) I need to be able to do a simultaneous update of app and net images from the secondary partitions through mcuboot. Correct?

2. nrf5340 default behaviour is different here from e.g. nrf52 series because potential revert bricks net core - so I tried to force the same behaviour by setting  CONFIG_USE_NRF53_MULTI_IMAGE_WITHOUT_UPGRADE_ONLY=y in prj.conf. This did not work as the option has no prompt. I added one just to be able to set this, but what is the correct way to go here?

3. The first issue: With connecting mcumgr to the app after flashing, I see only "image=0 slot=0" in the image list and after uploading "app_update.bin", I see "image=0 slot=0" and "image=0 slot=1" with uploaded app. If I upload "net_core_app_update.bin", it is ALSO uploaded to "image=0 slot=1". So:

a) Why don't I see the slot for net core in the image list?
b) If I try to upload "dfu_application.zip", the transfer stops at 0 bytes and never moves. Why?

4. The second issue: I can stop in mcuboot (confirmed by led) and image list here shows 3 slots (so, also "image=1 slot=0"). I can upload "dfu_application.zip" here. So:

a) After 60 KB are uploaded, the already slow transfer (3 KB/s) drops to 1 KB/s. Why?
b) After upload of zip and doing image list, the "image=0 slot=0" disappears from the list and "image=1 slot=0" is still empty. If I reboot, the app is bricked, mcuboot still works.

As a reference, I took this link: https://github.com/hellesvik-nordic/samples_for_nrf_connect_sdk/tree/main/bootloader_samples
It contains samples for DFU update over BLE for nrf5340 and separate samples for serial recovery of app in net cores, but there is no sample for simultaneous serial recovery of both cores. 

The docs say it should be possible - or am I missunderstanding the docs?

I am attaching the ZIP file that contains .conf files for the app and mcuboot and also a manifest file from the "dfu_application.zip".conf_and_manifest.zip

Regards,
Marko

---------------------------

external_flash (0x800000 - 8192kB):
+----------------------------------------------------+
| 0x0: mcuboot_secondary (0xcc000 - 816kB) |
| 0xcc000: mcuboot_secondary_1 (0x40000 - 256kB) |
| 0x10c000: littlefs_ext_storage (0x6c0000 - 6912kB) |
| 0x7cc000: external_flash (0x34000 - 208kB) |
+----------------------------------------------------+

flash_primary (0x100000 - 1024kB):
+--------------------------------------------------+
| 0x0: mcuboot (0x14000 - 80kB) |
+---0x14000: mcuboot_primary (0xcc000 - 816kB)-----+
| 0x14000: mcuboot_pad (0x200 - 512B) |
+---0x14200: mcuboot_primary_app (0xcbe00 - 815kB)-+
| 0x14200: app (0xcbe00 - 815kB) |
+--------------------------------------------------+
| 0xe0000: littlefs_storage (0x20000 - 128kB) |
+--------------------------------------------------+

otp (0x2fc - 764B):
+------------------------------+
| 0xff8100: otp (0x2fc - 764B) |
+------------------------------+

ram_flash (0x40000 - 256kB):
+------------------------------------------+
| 0x0: mcuboot_primary_1 (0x40000 - 256kB) |
| 0x40000: ram_flash (0x0 - 0B) |
+------------------------------------------+

sram_primary (0x80000 - 512kB):
+-----------------------------------------------+
| 0x20000000: pcd_sram (0x2000 - 8kB) |
| 0x20002000: sram_primary (0x6e000 - 440kB) |
| 0x20070000: rpmsg_nrf53_sram (0x10000 - 64kB) |
+-----------------------------------------------+

CPUNET flash_primary (0x40000 - 256kB):
+--------------------------------------------+
+---0x1000000: b0n_container (0xa000 - 40kB)-+
| 0x1000000: b0n (0x9a00 - 38kB) |
| 0x1009a00: provision (0x600 - 1kB) |
+---0x100a000: app (0x36000 - 216kB)---------+
| 0x100a000: hci_ipc (0x36000 - 216kB) |
+--------------------------------------------+

CPUNET sram_primary (0x10000 - 64kB):
+-------------------------------------------+
| 0x21000000: sram_primary (0x10000 - 64kB) |
+-------------------------------------------+

[tesc]

Hi,

This did not work as the option has no prompt. I added one just to be able to set this, but what is the correct way to go here?

I am not sure if I understand what you mean here, can you elaborate?

1. Last thing I want to do is update the board over BLE mesh, but before that (at least as I understand it) I need to be able to do a simultaneous update of app and net images from the secondary partitions through mcuboot. Correct?

While you may not always have to do a simultaneous update, you will have to do that if the interface between the appliation and network firmwares change. Simultaneous update is therefore the preferred option, yes.

2. nrf5340 default behaviour is different here from e.g. nrf52 series because potential revert bricks net core - so I tried to force the same behaviour by setting  CONFIG_USE_NRF53_MULTI_IMAGE_WITHOUT_UPGRADE_ONLY=y in prj.conf.

According to Simultaneous multi-image DFU with nRF5340 DK, simultaneous update of multiple images does not support network core image reversion, and so CONFIG_BOOT_UPGRADE_ONLY is required for preventing application core image reversion. (If the application core reverts, you are left with possibly incompatible application and network images.)

For the remaining questions - basically getting the details correct for peforming a full DFU on the nRF5340 - I highly recommend having a look at the nRF Connect SDK Intermediate course on DevAcademy, and specifically Lesson 8 - Bootloaders and DFU/FOTA. It covers, among other topics, DFU for the nRF5340, and exercises which are walk-throughs of DFU: first over UART, then over USB and with external flash, and at last over Bluetooth LE. With the documentation linked in the previous paragraph (Simultaneous multi-image DFU with nRF5340 DK) as reference, those exercises should give you a solid understanding of DFU for nRF5340 using nRF Connect SDK.

Regards,
Terje

[Marko_P]

Hi,

No prompt issue: Add CONFIG_USE_NRF53_MULTI_IMAGE_WITHOUT_UPGRADE_ONLY=y to prj.conf and compile. With SDK 2.6.1 I get an error saying that I cannot set this option because it has no prompt. But I did not find any other ways to (implicitly) set it. 

I understand that what I am trying to do makes little sense because network core would be bricked after revert. OTOH it would confirm that my setup is prepared for FOTA over BLE mesh. I spent a few days on this, but was not able to produce a working simultaneous update over serial port through mcuboot or mcumgr server - and I have read everything on devzone and beyond . I followed the instructions in the first link you suggested, but to be honest, there are things written there that I do not understand. For example:

"The application core can be reverted, but doing so breaks the network core upon reversal, as the reversion process fills the network core with the content currently in the RAM that PCD uses. To enable this, define the CONFIG_USE_NRF53_MULTI_IMAGE_WITHOUT_UPGRADE_ONLY Kconfig option in the project-level Kconfig file. When this option is defined, you can enable it by setting CONFIG_USE_NRF53_MULTI_IMAGE_WITHOUT_UPGRADE_ONLY."

What does the last (italic) sentence here mean? That I should set the option to "=y"?

Also: "The CONFIG_NRF53_MULTI_IMAGE_UPDATE option selects this feature by default if these options and all its other dependencies are asserted." - this option can only be set in child image config file (see bold text above) and I do not see how this option would set the above option (it only depends on it).

Regards,

Marko

 

[tesc]

Hi,

I assume you have found the answers to this already, but here it goes:

Marko_P said:

What does the last (italic) sentence here mean? That I should set the option to "=y"?

Yes, setting the config means adding it with the "=y". When the type of the config is "bool", you can set it with either "=y" or "=n", e.g. "CONFIG_SOME_WANTED_SETTING=y" or "CONFIG_SOME_UNWANTED_SETTING=n".

Marko_P said:

I do not see how this option would set the above option (it only depends on it).

I expect there to be some automatic dependency resolution at play here. If you still get warnings in the build log about configs and dependencies not being set or not correctly set, then you may have to add some config values for everything to work as intended.

Regards,
Terje