Regarding Simultaneous DFU for app core, net core and wifi patch

[Aarnav]

Hello,

I am working on a custom board with my own custom project. I want to perform DFU for all the images I mentioned. 
The mechanism for the OTA update will be as follows:
1. The OTA binary will be downloaded over the WIFI and stored to the SDCard
2. The OTA binary(from the SDCard) will be written to the respective memory in the flash and verified through my application core(if possible) or any other mechanism which is possible in the device runtime
3. The image will be verified and confirmed to be booted on the next reboot

I need help for the 2nd and 3rd step in the context of APIs and configuration options(already referred to Dev academy and nordic documentation but still in case I miss any).

Important details:
1. The nrf7002ek(for the wifi patch) is on the SPI interface.
2. The toolchain used is ncs v3.0.2(sysbuild and partition manager enabled)

Thanks in advance!  

[AHaug]

Hello,

First of I need to know one thing. Do you intend to place the mcuboot secondary application slot on the SPI, or do you simply intend to temporarily store the candidate image on the SD card before you move it to MCUboot secondary application slot on either the internal or external flash? 

Kind regards,
Andreas

[Aarnav]

So I will download the files through WIFI from a custom API of my own due to which I will store any DFU related file on the SDCard first.
Yes I want my mcuboot secondary slot on external flash.

Regards
Aarnav

[AHaug]

Ah, like that. Hmm, no not from the SD card itself, but you can have your ota bin/zip containing all 3 images to the SD card and then move the contents of the secondary for each respective partition you should be good to go to do a simultaneous update upon next reboot. 

Lets say you're using a nRF5340 as the host MCU together with your 7002EK. Then you will have 3 partitions for appcore, netcore and wifi fw patch, and 3 partitions for their secondary slots to store the candidate OTA image where the wifi fw patch may reside in external flash before being loaded into flash. For the update of these 3 images, you can do it simultaneously, and we recommend simultaneous DFU for the nrf5340 anyways. There may be some additional tips w.r.t downloading the image over wifi here https://academy.nordicsemi.com/courses/nrf-connect-sdk-intermediate/lessons/lesson-9-bootloaders-and-dfu-fota/topic/exercise-7-fota-over-wi-fi/ (if you're using AWS then this may be an even better fit than the cellular lwm2m dfu of another mcu sample).

When you have the images within the respective secondaries, you need to mark the candidate images with the proper status so that they will get swapped (if they get validated by the MCUboot). To do this you can use https://docs.nordicsemi.com/bundle/zephyr-apis-latest/page/group_mcuboot_api.html (boot_write_img_confirmed() and/or boot_write_img_confirmed_multi(image_index))

After the images are marked as confirmed you should be ready to trigger a multi image swap by reseting the SoC.

Kind regards,
Andreas

[Aarnav]

AHaug said:

When you have the images within the respective secondaries,

I want the guidance for this part specifically. As I said, I want to write the contents of the binary file into the flash for all the 3 partitions.

Are you saying https://docs.nordicsemi.com/bundle/zephyr-apis-latest/page/group_mcuboot_api.html will be able to do that also along with swapping mechanism?

Assume that I have the file already downloaded in the sdcard.

Regards
Aarnav 

[AHaug]

Aarnav said:

I want the guidance for this part specifically

Choose whichever transport you have connected the SD card to and the external flash to and do a read from the SD card and write it to the external flash. To do this you can use the file system that for instance the SD card samples in zephyr uses. As for setting up an SD card, have a look at the zephyr file system samples and for setting up an external flash see https://academy.nordicsemi.com/courses/nrf-connect-sdk-intermediate/lessons/lesson-9-bootloaders-and-dfu-fota/topic/exercise-3-dfu-with-external-flash/ 

struct fs_file_t src, dst;
fs_file_t_init(&src);
fs_file_t_init(&dst);

fs_open(&src, "/SD:/source_file.txt", FS_O_READ);
fs_open(&dst, "/lfs/dest_file.txt", FS_O_CREATE | FS_O_WRITE);

char buf[512];
ssize_t read_bytes;
while ((read_bytes = fs_read(&src, buf, sizeof(buf))) > 0) {
    fs_write(&dst, buf, read_bytes);
}

fs_close(&src);
fs_close(&dst);

Kind regards,
Andreas

[Aarnav]

All of this is done.
The only missing point is how to write it from the sdcard to the external flash.
I have my FAT FS initialised.
I am able to read contents of my file but the only thing I don't know is how to write it into the external flash.
Since external flash is a partition instead of a file, my only question is: 
What is the interface/API(s) to write the contents of the firmware binary file into the external flash in those regions defined in the pm_static for all the three partitions.

[AHaug]

Doesn't this work?

Kind regards,
Andreas

[Aarnav]

I think I am not able to make explain you what I want. Can you please float this ticket to someone else? 

[AHaug]

No can do, sir. You're stuck with me. Please review the resources, as you should have everything you need from there. 

AHaug said:

Doesn't this work?

This is the API you need to write contents to a specific memory address. You need to separate the contents of the .bin you download and initially write to the SD card. TBH I can't see the reason for why you have the SD card as a temporary storage when you already have an external flash and you can download the candidate images directly to the external flash in the first place.

Kind regards,
Andreas

[Aarnav]

Because the application will download the firmware from a specific secure API and then when the file is succesfully downloaded, we will go for writing the contents into the external flash.
Writing the downloaded chunk directly into the external flash does not seem to be a good idea for now but I will still consider it and try.

Still the part "how to write the content into the external flash" is not clarified. What you have given me in the last response is a write function of FAT FS library: fs_write which takes an initialised file descriptor(through fs_open) as an input and the FAT FS takes care of handling the address stuff.

What you are essentially saying is I should mount the external flash with the FAT FS library, then open a file in external flash for which I don't know how I am assigning a path, then write the content into it knowing that I am not giving any input for a specific address in this whole process.

Is this even possible and the correct way to do this?

Please correct me bluntly if I am wrong.

[AHaug]

Ok lets take it back a step 

Based on the motivation I still don't see the need to OTA the files into an SD card placed on the device you will update, before you move it to mcuboot secondary on an external flash and then do the image swapping. I can see the need to have an SD card as a replacement for UART/USB/Serial recovery as a physical option for DFU in a industrial device, where external operators will have to update the firmware of the device, but if the device that will be updated has WiFi I would skip the part where you OTA to an intermittent device (the SD card) and just go directly to the external flash.

Nonetheless, if you have a device without OTA options, you will have to have a physical DFU option, where you have 3 options; UART, USB or FS on a SD card. In your case I understand your design as having chosen SD card as the physical alternative. 

Does this resonate with what you're aiming to do, am I misunderstanding anything, or are insisting on having the SD card as an intermittent storage for WiFi OTA as well?

Here's what I would recommend

If WiFi-OTA:

1. Download the candidate images directly to the respective mcuboot secondary partitions for the candidate images and do DFU with MCUMgr as described in the academy course on DFU 

If DFU over SD card

1. Load the update binaries to the SD card by plugging it into Machine A (computer, SD card writer, wherever you will obtain the candidate images from), then plug it into Machine B which you will update.
2. Write the files to the addresses corresponding to the various secondary partitions you've defined that are located on the external flash. You can either use the FS write functions with the destination addresses being the partitions or the MCUmgr filesystem https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/app_dev/bootloaders_dfu/dfu_tools_mcumgr_cli.html#filesystem_management
3. Validate, confirm, reset and swap old and new images

 Kind regard,s
Andreas

[Aarnav]

You were right, storing the file in the sdcard is just an overhead. Also, I could do the simultaneous DFU through the "dfu milti image" and "dfu target" library. Thanks a lot for your help.
I am closing this issue for now

Although I wanted to raise another ticket for this question but in a case you can tell me, we set the pm_static.yml for the application core which includes the primary and secondary partitions for app core, secondary partitions for net core and wifi patch.

The question is-> Do we also have to declare a pm_static.yml for the network core application. 
Just for information sysbuild is being used to handle multiple images.