Device reboots into DFU Mode after App Update

[Kyle Krueger]

Hello,

I am having an issue with the DFU in SDK V12. Using the secure_dfu package, and the buttonless dfu app as a template, I was able to get OTA DFU application updates working with the development kit. However, the same cannot be said about running the same application with custom hardware.

After running the DFU update on the Development Kit, everything runs as expected. The device resets, and launches the application; the DFU control point is visible to reset the device and boot back into DFU mode.

On the other hand, with our custom hardware. The device reports |DFU| Upload Completed in (#####) ms, but then after the reset boots right back into DFU mode.

After checking the hardware compatibility matrix, I know our chip is the same revision as the one on the pca10040 DK we were using for testing.

My suspicion is that the BANK_0 value for a valid app is not being set upon DFU completion, but I can't make any sense out of why that would fail to occur.

Has anyone else seen a failure to launch an app after DFU update with SDK12.0 and/or SDK12.1?

Here is the output from the flash after performing DFU: hex_dump.txt

[Kyle Krueger]

Here is a larger portion of the output after issuing a reset with nrfjprog:

```
:INFO:------- nrf_dfu_flash_init-------
:INFO:Waiting for events
:INFO:Inside main
:INFO:In nrf_bootloader_init
:INFO:In real nrf_dfu_init
:INFO:running nrf_dfu_settings_init
:INFO:Enter nrf_dfu_continue
:INFO:Valid App
:INFO:Application sent bootloader request
:INFO:In nrf_dfu_transports_init
:INFO:num transports: 1
:INFO:vector table: 0x00075000
SDH:INFO:sd_ble_enable: RAM START at 0x20002c00
SDH:WARNING:sd_ble_enable: app_ram_base should be adjusted to 0x20002798
SDH:WARNING:ram size should be adjusted to 0xd868 
:INFO:After nrf_dfu_transports_init
:INFO:------- nrf_dfu_flash_init-------
:INFO:Waiting for events
```

[bjorn-spockeli]

Did the bootloader reach nrf_bootloader_app_start? The suggested RAM start address for the application is lower than 0x20002C00, i.e. it should not be an issue since you have allocated more than enough RAM to the SoftDevice.

[Kyle Krueger]

No, it doesn't look like it ever returns from nrf_bootloader_init(). However, it did acknowledge the valid app as seen above.

[bjorn-spockeli]

Hi Kyle, I directed you to the wrong nrf_bootloader_app_start call, nrf_bootloader_init() should not return as nrf_bootloader_app_start is called in nrf_dfu_init() in nrf_dfu.c. Can you try to set a breakpoint at the nrf_bootloader_app_start call shown below(should be at line 143 in nrf_dfu.c)

if (nrf_dfu_app_is_valid())
    {
        NRF_LOG_INFO("Jumping to: 0x%08x\r\n", MAIN_APPLICATION_START_ADDR);
        nrf_bootloader_app_start(MAIN_APPLICATION_START_ADDR);
    }

[Kyle Krueger]

Hi Bjørn,

The code is instead entering the if statement just before at line 119:

```
if(enter_bootloader_mode != 0 || !nrf_dfu_app_is_valid())
{
    timers_init();
    scheduler_init();

    // Initializing transports
    ret_val = nrf_dfu_transports_init();
    if (ret_val != NRF_SUCCESS)
    {
        NRF_LOG_INFO("Could not initalize DFU transport: 0x%08x\r\n");
        return ret_val;
    }

    (void)nrf_dfu_req_handler_init();

    // This function will never return
    NRF_LOG_INFO("Waiting for events\r\n");
    wait_for_event();
    NRF_LOG_INFO("After waiting for events\r\n");
}
```

This is because the nrf_dfu_enter_check() is passing, and the enter_bootloader_mode flag is being set to 1. To confirm, this is right after a DFU update, and that flag should not be set.