DFU over USB get stuck in MCUBOOT after power cycle

Hi, 

NCS3.0.2 on nRF52840 platform.

Using mcuboot + app build using sysbuild

in the app: shell + console are configured over cdc_acm_uart1 (connecting to e.g. COM11), mcumgr configured over cdc_acm_uart0 (connecting to e.g. COM10)

mcuboot boot is configured over cdc_acm_uart0 (COM10)

The app includes the following code fragment in its main thread (right after system initialization:

    LOG_INF("application starting...");
    app_start();
    LOG_INF("application started");

    if(!boot_is_img_confirmed()) {
        LOG_INF("confirming image...");
        int rc = boot_write_img_confirmed();
        if (rc != 0) {
            LOG_WRN("Error confirming image failed. Error: %d\n", rc);
            // sys_reboot(SYS_REBOOT_COLD);
        }
    }

    LOG_INF("application main thread exiting !");
    return 0;

I try to DFU over USB. 

I closely followed Lesson 9 of the NCS intermediate course. Specifically exercise 4

I build the application + mcuboot and then flash them through the IDE (vscode).

After flashing, the app runs as expected. I even managed to update the app with mcumgr (using AuTerm).

It all works fine even after running "kernel reboot" shell command.

BUT, when I power cycle, something weird happens and I only see "MCUBOOT" in the serial monitor list of devices.

The update does not survive a power cycle.

Strangely, when I use AuTerm to probe the image list, I get no image identified... (no hash, nor flags).

I do see the image in place using the nrf programmer

Some more info - I use a custom nrf52840 based board + custom private key (as explained in exercise 2)

What can be the reason ?

Attached are sysbuild.conf & sysbuild\mcuboot.conf

/cfs-file/__key/communityserver-discussions-components-files/4/6114.sysbuild.conf

/cfs-file/__key/communityserver-discussions-components-files/4/7522.mcuboot.conf

We are starting production of poc units and I don't have DFU  in place  Cold sweatCold sweatCold sweat

Parents
  • Hello,

    It seems like the problem is that the device enters Serial recovery mode in the Bootloader also when you don't want it to. For example, after uploading the update via the application instead of the bootloader?

    Serial recovery (DFU within bootloader) vs DFU in app:

    Is the 'mcuboot-button0' assigned to an actual button on your board? Ref.: 

    Best regards,

    Vidar

    Edit: it may be good to check the actual configs applied to the mcuboot build by checking the .config file in build/mcuboot/zephyr

Reply
  • Hello,

    It seems like the problem is that the device enters Serial recovery mode in the Bootloader also when you don't want it to. For example, after uploading the update via the application instead of the bootloader?

    Serial recovery (DFU within bootloader) vs DFU in app:

    Is the 'mcuboot-button0' assigned to an actual button on your board? Ref.: 

    Best regards,

    Vidar

    Edit: it may be good to check the actual configs applied to the mcuboot build by checking the .config file in build/mcuboot/zephyr

Children
Related