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

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

user26071 — Fri, 03 Jun 2022 09:20:25 GMT

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.

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

user26071 — Fri, 03 Jun 2022 09:19:32 GMT

[quote user="SebastianA"]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.[/quote]

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

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

user89430 — Fri, 03 Jun 2022 06:39:45 GMT

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!

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

user26071 — Thu, 02 Jun 2022 13:04:50 GMT

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