NCS 2.2 custom net child image

[Hiihtaja]

Hello !

I have used multicore sample as base and add to it own network image and b0n bootloader ( as child to network image).

And net_core_app_update.bin is not build.

Looks like it is known issue and might be fixed in ncs 2.2 release or some patch is available some where.

Similar problems : 

 NCS 2.0 custom child image + mcuboot build

 NCS 2.1.0 custom child image + mcuboot build 

 NRF5340 multicore image dfu package not have net core binary 

Could it be possible to have some workaround about it ?

In our case we have custom radio image and muiltiimage type of build is expected as natural environment where app and network corea image + 2 bootloaders are build in one shot.

Regards,

Eugene

[Hieu]

Hi Eugene,

The multicore sample has a build order problem.

Normally, the regular netcore is built first, and then during bootloader build, the update bin files are generated.

However, in the multicore sample, after bootloader is added, bootloader is built first, and thus results in problem where the update bin files for the network core are not generated.

Could you please try to apply this commit to your SDK and see if it fixes the issue?

dump · hakonfam/fw-nrfconnect-zephyr@970c432 (github.com)

Regards,

Hieu

[Hiihtaja]

Hi Hieu !

1.

Thank you !

I think this patch is work for me as well and whole set of images are generated.

In latest SDK, line numbers have different numbers.

Can chaining of child images done in other way for avoid this patch ? OR patch will be published soon ?

2,

But after that I have moved to other step to validate if binaries is correct and can be used for actual update.

I have modified conf & sources a bit for have USB serial connectivity with bootloader and different main.c files for build actual firmware updates. Direct Serial flash recover DFU method is configured for both APP and NET images.

With serial recovery app and core images should be updated directly without any intermediate slots in internal or external memory. May be some shared SRAM is used for transfer image from MCUBoot to b0n boot-loader.

Configuration lines are collected from different SDK and Devzone samples and maybe redundant/wrong sometimes.

I'm able to update app core by using line: 

$ mcumgr -c acm2 image upload -e build/zephyr/net_core_app_update.bin

and image is updated directly and can boot again

But composite update:

$ mcumgr -c acm2 image upload -e build/zephyr/dfu_application.zip

destroy everything and no valid image any more

I: Starting bootloader

I: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3

I: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3

I: Boot source: none

W: Failed reading image headers; Image=0

E: Image in the primary slot is not valid!

E: Unable to find bootable image

Unfortunately , no traces from b0n bootloader, I'm not sure if I enable those in correct way.

Netcore update

$ mcumgr -c acm2 image upload -e build/zephyr/net_core_app_update.bin

Looks like overwrite application core flash space.

So I need some correct test application for verify network/composite image update ( I will move to signed images as well). In our case app and core images expected to be huge and keep second copy in internal flash memory is not possible. Better to avoid usage external flash memory as well. Load and update will take long time.

Board will be connected to some host and we have enough space for keep app/network update binaries.

This is why direct serial recovery method is preferable method for DFU.

Regards,

Eugene

multicore_dfu.zip 

 

[Hieu]

Hi Eugene,

What does this command give you?

mcumgr -c your_conn image list

Based on the info returned by that command, can you retry uploading only the netcore with this command:

mcumgr -c acm2 image upload -e build/zephyr/net_core_app_update.bin -n <IMAGE_SLOT>

where IMAGE_SLOT is the slot of the net core image, identifiable from the image list command.

Regards,

Hieu

[Hiihtaja]

Hi Hieu !

$ mcumgr -c acm2 image list
Images:
image=0 slot=0
version: 1.0.0.0
bootable: false
flags:
hash: Unavailable
image=0 slot=1
version: 1.0.0.0
bootable: false
flags:
hash: Unavailable
Split status: N/A (0)

Looks like this is 2 copies of app core image ?

Flashing net_core image to first slot  e.g. -n 1 and press reset , cause infinitive reboot after 

-I jumping to first image slot

flashing with -n 0 app core will boot as usually.

Partition info

But netcore flash is not accessible directly, what image list is really expected  ?

May be my configuration wrong ?

BUT

if I upload image to slot 3

$ mcumgr -c acm2 image upload -e build/zephyr/net_core_app_update.bin -n 3
20.16 KiB / 20.16 KiB [==============================================================================================================] 100.00% 2.98 KiB/s 6s
Done

: Writing at 0x4f84 until 0x50a0
I: Erasing range 0x%jx:0x%jx
I: Turned on network core
I: RX: 0x0
I: TX
 

Update looks like happens

*** Booting Zephyr OS build v3.2.99-ncs1 ***
Hello world from net nrf5340dk_nrf5340_cpunet, data Jan 25 2023, time 19:44:38
*** Booting Zephyr OS build v3.2.99-ncs1 ***
*** Booting Zephyr OS build v3.2.99-ncs1 ***
Hello world from net nrf5340dk_nrf5340_cpunet, data Jan 25 2023, time 19:47:11

Can it be some trick with network core update if slot 3 is specified ?

Also it is not so clear if it write happens directly by some small chunks or network image is written to slot 1 of app flash and updated during reboot ?

Existing traces from bootloader is not so informative, no idea how to enable more.

and in case of composite image update dosn't work 

$ mcumgr -c acm2 image upload -e build/zephyr/dfu_application.zip

After reboot

** Booting Zephyr OS build v3.2.99-ncs1 ***
I: Starting bootloader
I: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Boot source: none
W: Failed reading image headers; Image=0
E: bad image magic 0x4034b50; Image=0
E: Unable to find bootable image

manifest.json looks not so correct for net image for case of serial recovery

{
"format-version": 0,
"time": 1674719169,
"files": [
{
"type": "application",
"board": "nrf5340dk_nrf5340_cpuapp",
"soc": "nRF5340_CPUAPP_QKAA",
"load_address": 98816,
"image_index": "0",
"slot_index_primary": "1",
"slot_index_secondary": "2",
"version_MCUBOOT": "1.0.0+0",
"size": 41724,
"file": "app_update.bin",
"modtime": 1674719168
},
{
"type": "application",
"board": "nrf5340dk_nrf5340_cpunet",
"soc": "nRF5340_CPUNET_QKAA",
"image_index": "1",
"slot_index_primary": "3",
"slot_index_secondary": "4",
"load_address": 16812032,
"version": "1",
"size": 20640,
"file": "net_core_app_update.bin",
"modtime": 1674719168
}
],
"name": "multicore_dfu_ext",
"firmware": {
"zephyr": {
"revision": "c0689b16ff127d1b71a4cc20310d476e1807e26e-dirty"
},
"nrf": {
"revision": "188a16036ab968bc0f9226ba178ca461548a8c66"
}
}
}2744.dfu_application.zip

Can it be some build error what generate dfu_application.zip in wrong way for serial recovery ?

Regards,

Eugene

[Hieu]

Hi Eugene,

First, regarding your observation running mcumgr commands, I am able to reproduce almost all of it, except that my setup only results in Slot 0 listed, no Slot 1. There are some things that don't make sense here. I will have to ask our internal team for some more information.

Secondly, regarding using dfu_application.zip, it is likely not supported for serial DFU and serial recovery. I will also ask the internal team while I am at it.

I am out of office tomorrow, so I will come back with an update by the end of Tue Jan 31.

Regards,

Hieu