nRF5 SDK is not maintained anymore
More Info: Consider nRF Connect SDK for new designs

DFU update over USB fails because the old application starts during update

We are using nrfutil 6.1.3 on Ubuntu 20.04LTS and nRF5 SDK 17.0.2

We're using a copy of the dfu/secure_bootloader as the bootloader. We've changed NRF_BL_DFU_INACTIVITY_TIMEOUT_MS to 0 and added our own keys.

On the device we already have a softdevice with id 0x100 and an application (with a different version number).

We build a dfu package with:
nrfutil pkg generate \
    --softdevice sd.hex \
    --application app.hex \
    --key-file priv.pem \
    --hw-version 52 \
    --application-version 1654161769 \
    --sd-req 0 \
    --sd-id 0x100 \
    pkg.dfu

(the softdevice is the same as is already on the device).

We put the device in DFU mode with:
sd_power_gpregret_clr(0, 0xffffffff);
sd_power_gpregret_set(0, 0xb1);
NVIC_SystemReset();

Then we try to update the device with:
nrfutil dfu usb-serial -pkg pkg.dfu -p /dev/serial/by-id/usb-Nordic_Semiconductor_*

nrfutil waits a while, then it starts to update the device, up to about 58%. After that we see that our old application has started again.

From this I'm guessing that the old softdevice version is updated to the same one once more, then it resets and starts the old application.

If I don't put the softdevice in the dfu package (and change to --sd-reg 0x100), then it works as expected, the application is updated and then starts.

What should we do differently to make it work with a sd+app dfu package?

I want the softdevice in the dfu package so it will work for devices with older softdevices on them as well.

  • Hello,

    If you are updating to the exact same softdevice as you had, you don't need to include the softdevice in the DFU image. Also, the DFU images are typically .zip. Can you try to use

    nrfutil pkg generate \
        --softdevice sd.hex \
        --application app.hex \
        --key-file priv.pem \
        --hw-version 52 \
        --application-version 1654161769 \
        --sd-req 0 \
        --sd-id 0x100 \
        pkg.zip

    Just to see whether it matters.

    If that doesn't do the trick, I would suggest you try to compile the _debug bootloader instead of the normal, and monitor the log from the bootloader. On every bootup it should say something about whether or not it should enter DFU mode or jump to the application, and what that decides that option.

    What does the log say?

    If you are not able to figure it out, is there some way for me to reproduce this with a DK? If so, can you upload the bootloader and application that you are using to reproduce this?

    Best regards,

    Edvin

  • No, when I know the device contains the right softdevice I don't need to include the softdevice, but I want to create a dfu package that also works with devices with older versions of the softdevice so we don't have to create many different versions. If I understand the documentation correctly that should be a valid use case.

    Renaming the file did not help, but good call with the logging.

    With logging turned on, I get this log:
    [... logs for the first startup and update of the softdevice]
    [08:06:50:315] <info> nrf_dfu_settings: Backing up settings page to address 0xFE000.␍␍␊

    [08:06:50:413] <info> app: Entering DFU mode.␍␍␊

    [08:06:50:427] <info> nrf_dfu_serial_usb: USB power detected␍␍␊

    [08:06:50:427] <info> nrf_dfu_serial_usb: USB ready␍␍␊

    [08:07:00:373] <info> app: Inactivity timeout.␍␍␊

    [08:07:00:377] <info> nrf_dfu_settings: Backing up settings page to address 0xFE000.␍␍␊

    [08:07:00:394] <info> app: Inside main␍␍␊

    [08:07:00:394] <info> nrf_dfu_settings: Backing up settings page to address 0xFE000.␍␍␊

    [08:07:00:404] <info> app: No firmware to activate.␍␍␊

    [08:07:00:863] <warning> nrf_dfu_settings: No additional data erased␍␍␊

    [08:07:00:879] <info> nrf_dfu_settings: Backing up settings page to address 0xFE000.␍␍␊

    After that the application starts.

    It seems the default value of NRF_BL_DFU_CONTINUATION_TIMEOUT_MS (which is 10000 in the example) is too little for the current nrfutils on my computer. Changing that value to 40000, then the update process worked fine.

    It seems to take almost 30 seconds from the device turning on USB to the nrfutil starting to send the next  image.


    Thanks!

  • SebastianA said:
    No, when I know the device contains the right softdevice I don't need to include the softdevice, but I want to create a dfu package that also works with devices with older versions of the softdevice so we don't have to create many different versions.

    That is true, but please remember that if you change the major version of the softdevice then you need to update the bootloader as well, so you don't end up with a bootloader and a softdevice that doesn't work together, in which case you will get a bricked device. 

    Exactly how this is typically done in field, I am not sure. One approach would be to create an application-only image which requires a certain softdevice. If that softdevice isn't present, then you would send the image with the SD+app. If the But then you need to make sure that bootloader will still work with the new softdevice. If that is also rejected due to it being a major SD update, then you can create a 3rd image containing BL+SD+app. That should be accepted.

    BR,

    Edvin

  • Alternatively, you can skip the APP+SD update, and jump straight to BL+APP+SD update. It is up to you how many steps you want to include in the procedure.

Related