Mesh OTA couldn't resume after target node reset

[John]

Hi，

I use NCS 3.2.4 and 54L15 DK. In the DFU target, I added configuration

CONFIG_DFU_TARGET=Y
CONFIG_DFU_TARGET_MCUBOOT=y
CONFIG_DFU_TARGET_STREAM_SAVE_PROGRESS=y

and also added the following content in dfu_recover function.

static int dfu_recover(struct bt_mesh_dfu_srv *srv,
                       const struct bt_mesh_dfu_img *img,
                       const struct bt_mesh_blob_io **io)
{
    size_t offset = 0;

    int err = dfu_target_mcuboot_offset_get(&offset);
    if (err) {
        printk("Failed to get MCUboot offset (err %d)\n", err);
        offset = 0; 
    }

    printk("Recovering BLOB transfer, already written: %zu bytes\n", offset);

    err = bt_mesh_blob_io_flash_init(&blob_flash_stream,
                                     FIXED_PARTITION_ID(slot1_partition),
                                     offset);
    if (err) {
        return err;
    }    

    *io = &blob_flash_stream.io;
    return 0;
}

After the distributor finished transmitting 3 chunks more, I manually reset the target device. In the RTT window, I entered the shell command: mesh models dfu cli resume, but the command returned error -22.

How can I implement the resume/breakpoint resumption feature for Mesh OTA?

[Edvin]

Hello,

Is there a way for me to test and reproduce what you are seeing? 

Where exactly did you add CONFIG_DFU_TARGET_STREAM_SAVE_PROGRESS=y?

Can you try to also add these, unless you already have them?

CONFIG_DFU_TARGET_STREAM_SAVE_PROGRESS=y
CONFIG_SETTINGS=y
CONFIG_FLASH_MAP=y
CONFIG_NVS=y

And, for debugging purposes, can you try to also add this one? Does that change the behavior?

CONFIG_DFU_TARGET_STREAM_SYNCHRONOUS=y

Best regards,

Edvin

[John]

Hi Edvin,

I add CONFIG_DFU_TARGET_STREAM_SAVE_PROGRESS in the prj.conf based on example target and light ctrl. I also have added these 

CONFIG_DFU_TARGET_STREAM_SAVE_PROGRESS=y
CONFIG_SETTINGS=y
CONFIG_FLASH_MAP=y
CONFIG_NVS=y

to test before I asked question.

Best regards,

John

[John]

Hi Edvin,

There is no difference after adding CONFIG_DFU_TARGET_STREAM_SYNCHRONOUS=y;

Besides,I found a link https://github.com/zephyrproject-rtos/zephyr/pull/104959 from Nordic AI, Is it still a bug for NCS now?

Best regards,

John

[Edvin]

This pull request was merged before NCS v3.3.0, but was not part of NCS v3.2.4 (that you are using). Try building and test your application using v3.3.0, and see if that helps.

If that doesn't work, perhaps you can guide me through how you are testing. Perhaps you have an application that you can .zip and upload, so that I can try to reproduce what you are seeing locally?

Best regards,

Edvin

[John]

In NCS v3.3.0, the distributor and target were used without any modifications. After compilation, the code was flashed onto the DK for testing.

Then, following the previously described procedure to modify the target, a manual reset was performed on the target after the upgrade reached 3%. However, after the reset, the read progress was 0.

The distributor returned error -22 for the two test.

Could u have a try?

Best regards,

John

[Edvin]

Can you please zip and upload the applications that you are using, together with the build command you are using (even if it is just "west build -b nrf54l15dk/nrf54l15").

If you are building using VS Code, right click the build configuration, and select "Copy build command" to copy the build command.

Best regards,

Edvin

[John]

This is a modified target example used for testing; The distributor has not been modified. After configuring CONFIG_DFU_TARGET=y, a compilation error occurs due to multiple definitions of dfu_target_init. Since I don't want to modify the original SDK files, I copied dfu_target.c into the project and renamed it to dfu_target_init_.

Build command: west build --build-dir e:/Nordic/Code/target_330/build e:/Nordic/Code/target_330 --pristine --board nrf54l15dk/nrf54l15/cpuapp -- -DDEBUG_THREAD_INFO=On -DCONFIG_DEBUG_THREAD_INFO=y -Dtarget_330_DEBUG_THREAD_INFO=Off -Dmcuboot_DEBUG_THREAD_INFO=Off

target_330.rar

Best regards,

John