SDK v15 DFU Bootloader hangs on execute instruction

[dingari]

Hi, I'm migraing our project to the latest NRF5 SDK v15.0.0 (S132  v6.0.0). We were previously on v12.2.0  (S132 v3.0.0) using the BLE DFU Bootloader. I've  modified our bootloader code to match the example from the latest SDK. It compiles and runs on our board. We're using our own utility which implements the DFU procedure to upload the firmware to our device.

The utility is able to connect, switch the device to the bootloader and transfer the init packet. The problem arises when the first object has been transferred and  we issue an execute command. The device locks up and doesn't respond to any command (including the execute). If I break with gdb the cpu is always somewhere around address `0x0007c1ea`. It is a branch instruction to the same address... an infinite loop.

I tried the nRF Toolbox for Android, but it wasn't even able to switch to the bootloader. I assume it hasn't been updated to use the new 16-bit Buttonless Servicee UUID.

Is there any obvious reason  this could be happening?

[Bjørn Kvaale]

Could you take a look at the .map file & see where in the code 0x0007c1ea corresponds to? Where is the infinite loop occurring? You can find the .map file in your build folder.

[dingari]

I think these are the relevant lines in the .map file for the bootloader:

    0x000000000007c1a0                nrf_bootloader_dfu_inactivity_timer_restart.constprop.38
    0x000000000007c20c                image_copy.part.0.constprop.35

I'm not sure where the infinite loop is occurring, but it's triggered somewhere after I issue an Execute command after sending the first object of the firmware.

[Bjørn Kvaale]

Looking at the secure dfu bootloader example in sdk 15, the function nrf_bootloader_dfu_inactivity_timer_restart() gets called twice: once in the dfu_observer() function inside nrf_bootloader.c to handle the NRF_DFU_EVT_OBJECT_RECEIVED event & once in nrf_bootloader_init() also in nrf_bootloader.c. 

Having you tried adding some NRF_LOG_ERROR() calls to debug the bootloader with an RTT client? I would try that to figure out where the error is occuring.

[Takeshi Goda]

https://devzone.nordicsemi.com/f/nordic-q-a/33310/invert-pwm-behaviour

Can you tell me how to solve this problem?

[Bjørn Kvaale]

This case was not assigned to my group. Another application engineer will look at your question as soon as they have time.

[dingari]

Hmm, looking at nrf_bootloader_dfu_timers.c I'm suspecting the infinite loop is occurring due to a failed `ASSERT` on a return code from the timer module in this function:

static void timer_start(app_timer_t * p_timer, uint32_t timeout_ms, nrf_bootloader_dfu_timeout_callback_t callback)
{
    ret_code_t err_code;

    timer_init();

    err_code = app_timer_stop(p_timer);
    ASSERT(err_code == NRF_SUCCESS);

    if (timeout_ms != 0)
    {
        //lint -save -e611 "Suspicious cast"
        err_code = app_timer_start(p_timer, APP_TIMER_TICKS(timeout_ms), (void *)callback);
        //lint -restore
        ASSERT(err_code == NRF_SUCCESS);
    }
}

I had to disable link time optimization to have the necessary debug symbols available in gdb for debugging. However, without the -flto flag the bootloader doesn't crash... So I'm at a loss on how I can debug this.

[Bjørn Kvaale]

Are you saying that everything works fine if you remove the -flto flag? This devzone case gives you a bit more information. If everything does work without this flag, could you not just remove the flag. It seems there is not too much performance difference from what I understand.

[dingari]

Yes, removing the -flto allows the bootloader to behave normally. I'm curious as to why this is happening. Of course I could remove the flag, but then I have to increase the size of the bootloader code (around 8kB seems to do the trick). It's not the end of the world, but a smaller bootloader is preferrable.