nRF5340 Upgrade of App and Net core firmware

[Riccardo Gaiati]

Hi, 

I am using SDK 1.9.1 and nRF5340.

Scenario

I am investigating the following scenario:

• files containing the firmware upgrade for the app and/or net cores will be initially stored in the filesystem partition (extenal flash) as they are produced during the compilation phase (app_update.bin and net_core_app_update.bin);
• on request, the upgrade of the app or net core will start;
• the request will be handled by the firmware running in the app core: the request will specify the file to use for the upgrade;
• the file containing the upgrade will be first validated; if validation is passed, the file will be copy into the mcuboot_secondary partition (external flash, but at the moment internal) and MCUBoot will take over the control of this phase and perform the upgrade of the core;
• due a bug, i cannot used the external flash to store the new image of the app and net core, so at the moment internal flash will be used; but the final goal is to use the external spi flash.

Looking in the documentation and in some tickets, I understood that one possible way to do it would be to use the DFU taget library. Here below  the pseudo-code:

uint8_t buffer[1024] = {0};

(void)fileOpen("app_update.bin", READ_MODE, handle);

(void)fileRead(handle, &buffer[0], 4);    /* read the first 4 bytes at the beginning of the upgrade bin file */

int imageType = dfu_target_img_type(const void *const &buffer[0], sizeof(buffer));

/* imageType should be 0x01,  DFU_TARGET_IMAGE_TYPE_MCUBOOT */

uint32_t fileSize = fileSize("app_update.bin"); 

int ret = dfu_target_init(imageType, fileSize, NULL);

if (ret < 0) return;
uint32_t offset = 0;
do
{
    uint32_t bytesRead = fileRead(handle, offset, &buffer[0], sizeof(buffer)); 
    ret = dfu_target_write(&buffer[0], bytesRead);
    fileSize -= bytesRead;
	offset += bytesRead;
}while ((filesize > 0) && (ret > 0)); 

if ((filesize == 0) && (ret == 0))
{
	dfu_target_done(true);
}
else
{
	dfu_target_done(false);
	dfu_target_reset();
	/*Reset the nRF5340 */
}

When the upgraded app firmware restarts, the function  boot_write_img_confirmed()  will be invoked.

Using the app nRF Connect Device Manager i am able to update both app and net core.

In my actual project i have defined only mcuboot_secondary partition.

I can see that with the app is possible to swap the firmware, instead with the netcore is not.

Questions:

1. is the reported approach correct ? If not, could you kindly indicate an example that suites my scenario ?
2. Can it work also for the network core ? How do i specify the core to be updated ? Basically, doing the same thing that nRF Connect Device Manager does.
3. Is there a function that perform the validation of the bin files before being copy in the DFU target ?
4. I saw that there is DFU multi-image library. is there any example using that ? is the zip file produced during the compilation that need to be sent to the DFU target? 

Thanks in advance for your kind help.

[Simon]

is the reported approach correct ? If not, could you kindly indicate an example that suites my scenario ?

It seems good. As long as you put the app_update.bin or the net_core_app_update.bin into the secondary flash partition, mcuboot will handle the rest. Based on the reset addr it will decide whether it is a netcore update or an appcore update and take the appropriate action.

Can it work also for the network core ? How do i specify the core to be updated ? Basically, doing the same thing that nRF Connect Device Manager does.

Actually, all you need to do is to put net_core_app_update.bin into secondary flash, and mcuboot will handle the rest.

Is there a function that perform the validation of the bin files before being copy in the DFU target ?

I did provide a similar answer in another private ticket. In that case mcumgr was used, and I explained how to do some verification of the .bin file from the computer as well as from the chip. I'll copy it in here. Let me know if this is not what you asked about:

"The mcumgr tool does not have this functionality. If you would like to do some verification from the computer, you could use Image tool (located in <ncs>/bootloader/mcuboot/scripts) to verify the binary file. Use imgtool verify:"

@$ imgtool verify -h
Usage: imgtool verify [OPTIONS] IMGFILE

  Check that signed image can be verified by given key

Options:
  -k, --key filename
  -h, --help          Show this message and exit.

"As said the mcumgr is quite dumb and pretty much only writes the image to the secondary slot (with one exception), with no checks on it. The verification is done by mcuboot, when mcuboot tries to swap images. The exception is when checking for image address is enabled, so that an image with an incorrect boot adress would not get uploaded, because the image may be still be verified by mcuboot and brick the device - but this needs to be enabled and special TLV needs to be added with the start image address using the imgtool.

Also topic of image verification is quite broad and may mean anything from signature, version, CPU, board revision, device purpose, nearly anything - and mcuboot currently only supports signatures, versions and some other basic checks that are rather related to correctness of an image than it's purpose.

If you have some additional conditions the img needs to fulfill, you can try providing an own callback img_mgmt_upload_cb that allows to do some additional checks on received image chunk, after mcumgr has already accepted it as valid but not yet written."

I saw that there is DFU multi-image library. is there any example using that ? is the zip file produced during the compilation that need to be sent to the DFU target?

I'm not too familiar with simultaneous multi image DFU, however it makes sense to update both the netcore and appcore simultaneously if Bluetooth is affected, for changes that is related to the Bluetooth communication between the chips. You could take a look at the Machine Learning application and the Thingy:53 configuration, it demonstrates how to do multi image DFU. Use the file dfu_application.zip to do multi image DFU.

Let me know if anything is unclear, and I will try to clarify or investigate further.

Best regards,

Simon