Updating App + Net Core via Wi-Fi (HTTP) FOTA

[ozoz05]

Hello,
I’m working with a custom board using nRF7002 + nRF5340 + MX25R64 (SPI4), and I’m trying to perform firmware updates over Wi-Fi using a firmware file hosted on an HTTP server.

During the build process, I confirmed that:

• The output includes separate files for app core and net core.bin

• A file that seems to contain both app and net core images is also generated.zip

However, when I attempt to run the firmware update using the file, the update fails with the following log output:.zip

[00:00:24.743,804] <inf> downloader: Setting up TLS credentials, sec tag count 1
[00:00:24.743,988] <inf> downloader: Connecting to 3.5.188.194
[00:00:25.470,947] <inf> downloader: Downloaded 2048/897008 bytes (0%)
[00:00:25.471,099] <err> dfu_target: No supported image type found
[00:00:25.471,252] <err> fota_download: Unknown image type
[00:00:25.475,341] <err> wifi_socket: FOTA download error occurred
[00:00:25.475,494] <wrn> fota_download: fota_download_cancel invalid state

Is there any additional configuration I need to enable for using a .zip file with Wi-Fi FOTA?

[Vidar Berg]

Hello,

The zip file is created to make FW distribution easier on the client side. However, you must always extract the binaries (*.bin) from the zip file before transferring them to the target, as the chip does not support unzipping zip files.

Best regards,

Vidar

[ozoz05]

Then, do I have to code to extract the zip file downloaded to Fota as bin?
Or do I have to get the files I downloaded, app core, and net core, respectively, bin files?
The Nordic document says that for nrf5340 it is better to update the app core and net core at the same time,
Then, if I upload the file with app+net merged, does it work all at once??
If the last method is correct, please tell me how to merge.

[Vidar Berg]

Yes, you should download the app and netcore .bin files separately. However, you can stage both updates before activating them if your project is set up to support simultaneous multi-image DFU (https://academy.nordicsemi.com/courses/nrf-connect-sdk-intermediate/lessons/lesson-9-bootloaders-and-dfu-fota/topic/dfu-for-the-nrf5340/).

[ozoz05]

I'm currently reviewing the page you provided, but is there perhaps an example or more detailed information about additional configuration?
I think I've completed all the settings, but currently, only the app core is being downloaded, while the net core isn't downloading.

int ret = fota_download_start(host, file, SEC_TAG, 0, 0);

    if (ret != 0) {

        LOG_ERR("fota_download_start() failed: %d", ret);

        goto fota_error;

    }

    return 0; // 성공





///////////////

I ran fota_download_start explicitly only for the app core. Do I also need to explicitly run it again for the net core separately?

For example:

Option 1 (single execution):

fota_download_start(app_core_url, file, SEC_TAG, 0, 0); // After app core downloads, net core is automatically downloaded from the same path.

Option 2 (separate executions):

ret = fota_download_start(app_core_url, file, SEC_TAG, 0, 0);
if (ret) {
LOG_ERR("App core download failed");
return;
}

ret = fota_download_start(net_core_url, file, SEC_TAG, 0, 0);
if (ret) {
LOG_ERR("Net core download failed");
return;
}

If I use Option 2, does sys_reboot in FOTA_DOWNLOAD_EVT_FINISHED within fota_dl_handler occur only after both fota_download_start calls have completed?

 

[Vidar Berg]

Sorry, I realize now that the FOTA library does not support multiple mcuboot type FW images out of the box ( nRF5340 + nRF7002 multi-image HTTPS FOTA ) as it was initially designed with the nRF91 series in mind. Please have a look at the linked thread and see if that helps answer your question.

[ozoz05]

Based on the attached log, the app core (image 0) downloads successfully.
When the net core (image 1) download starts, it immediately throws an error.
I suspect the net-core firmware (.bin) was not built with its image number set to 1.

How can I generate the net-core firmware file correctly?

When I open the net-core firmware in a hex editor, should the byte at the position shown in the screenshot be 01?

[Kenneth]

Hello,

Vidar and a few other key persons are out of office this week, we will look into your question next week when they are back.

Kenneth

[Vidar Berg]

Sorry for the delayed response. Have you been able to make any progress on this in the meantime? The image number is not specified in the image itself, but is part of the SMP command. The error indicates that dfu_target_img_type() returns DFU_TARGET_IMAGE_TYPE_NONE instead of DFU_TARGET_IMAGE_TYPE_MCUBOOT when called from downloader_callback(). The question is why. The binary dump shows that the first four bytes contain the correct MCUBOOT_HEADER_MAGIC value, which is used to identify whether it is a mcuboot image.