This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Problem with bootloader-mode after DFU procedure


I have been investing a couple days now in order to get the DFU procedure working properly, but it seems I am stuck...

This the setup that I am currently using:

nRF52832 DK
Nordic SdK v12.2.0
Eclipse Neon 2
GCC-Toolchain (GNU-Arm-Tools v5.4_2016q3)
nRF Toolbox App v2.4.0
nRF Connect App v4.11.0

Here is what I did so far:

***(1.)*** DFU-test with zip-files from examples/dfu/ble_dfu_send_hex/test_images_update_nrf52 works as expected!

--> normal upload-procedure to DfuTarg, no error messages, startup of HRM-example after button-reset

Files: dfu_test_softdevice_bootloader_s132.hex /

***(2.)*** Prepared the buttonless_dfu-example found in examples/ble_peripheral by using this tutorial

(2.1)compiling and flashing worked right away without further modifications, but it got stuck right after startup while constantly repeating this messages

:INFO:running nrf_dfu_settings_init
:INFO:!!!!!!!!!!!!!!! Resetting bootloader settings !!!!!!!!!!!
:INFO:Erasing old settings at: 0x20002320
:INFO:Erasing: 0x20002320, num: 1
:INFO:Erase failed: 6
:ERROR:Erasing from flash memory failed.

(2.2) I am assuming this issue is caused by not having a correct bootloader setup, so I moved on to the next step...

Files: s132_nrf52_3.0.0_softdevice.hex / buttonless_dfu.hex (fixed)

***(3.)*** Followed the procedure of this tutorial for using the bootloader_secure-example found in examples/dfu

(3.1) application-upload (from (2)) is done successfully, but nRF52832 DK stays in bootloader-mode even after multiple resets (also happens for different apps that are flashed directly over cmd-line)

(3.2) uploading the zip-package for bootloader and softdevice always results in the error-message REMOTE DFU DATA SIZE EXCEEDS LIMIT even though my self-created package is only 146 KB compared to the example-package from (1) with 153 KB

(3.3) I already wanted to debug the bootloader but I cant seem to get those hints working for my gcc-toolchain and SDK v12.2.0


hex-Files: secure_dfu_settings.hex / secure_dfu.hex](/attachment/0aa826c0d535148f03394aea60f7a738) / secure_dfu_merged.hex

pkg-Files: /

In order to prepare the dfu-procedure and to create the necessary files I using the following commands:

a) Generated private key -> dfu_private.pem
b) Created public-key in code-format -> dfu_public_key.c
c) Compiled buttonless_dfu-example -> buttonless_dfu.hex
d) Compiled bootloader_secure-example -> secure_dfu.hex
e) Created bootloader-settings -> secure_dfu_settings.hex with 
'nrfutil settings generate --family NRF52 --application buttonless_dfu.hex --application-version 3 --bootloader-version 2 --bl-settings-version 1 secure_dfu_settings.hex'
f) Merged hex-files for bootloader- and bootloader-settings with
'mergehex -m secure_dfu.hex secure_dfu_settings.hex -o secure_dfu_merged.hex'
g) Created zip-package for the bootloader and the softdevice with
'nrfutil pkg generate --bootloader secure_dfu_merged.hex --bootloader-version 2 --softdevice s132_nrf52_3.0.0_softdevice.hex --key-file dfu_private.pem --hw-version 52 --sd-req 0x8C'
h) Created zip-package for the application with
'nrfutil pkg generate --application buttonless_dfu.hex --application-version 3 --key-file dfu_private.pem --hw-version 52 --sd-req 0x8C'

Does anyone have an idea what I might be missing in order to solve the problems in (2) and (3)?

  • Just checked this topic here, but even after adjusting the application- and bootloader-version to 1 the nRF52832 DK is still stuck in bootloader-mode after a successfull dfu and multiple resets...

  • As for the problem in (2) I came across this topic here, which mentioned a potientially missing part in the MEMORY-block and also in the SECTIONS-block of the corresponding loader-file.

    Now I am getting the following output for the buttonless_dfu-example:

    :INFO:running nrf_dfu_settings_init
    :INFO:!!!!!!!!!!!!!!! Resetting bootloader settings !!!!!!!!!!!
    :INFO:Erasing old settings at: 0x0007f000
    :INFO:Erasing: 0x0007f000, num: 1
    :INFO:Writing 0x00000057 words
    :INFO:Writing settings...
    :INFO:running nrf_dfu_settings_init

    When activating/deactivating notifications for the Nordic_Template-Device I am also seeing those messages:

    APP:INFO:Indication for BLE_DFU is enabled
    APP:INFO:Indication for BLE_DFU is disabled

    Is that the expected behaviour!?

  • After integrating the bug-fix for writing into the characteristic of the buttonless-dfu-service (see here), it is also possible to request a restart in bootloader-mode which results in the following messages:

    APP:INFO:Device is entering bootloader mode!
    :INFO:Erasing old settings at: 0x0007f000
    :INFO:Erasing: 0x0007f000, num: 1
    :INFO:Writing 0x00000057 words
    :INFO:Writing settings...
    :INFO:Obtained settings, enter dfu is 1

    So I am assuming the buttonless-dfu-example works pretty much as expected, even though it needed some adjustments which should have long been integrated officially into the recent SDK-releases.

  • Now only the problems 3.1 (bootloader being stuck - not starting the application), 3.2 (REMOTE DFU DATA SIZE EXCEEDS LIMIT-error) and 3.3 (debugging bootloader_secure-example) remain, where I would realy appreciate some help...

    [Edit:] Attached all of my used files in the initial post for further investigations!

  • Here is also the output of my flashing procedure:

    Part 1 (eraseall)

    make VERBOSE=1 erase 
    nrfjprog --eraseall -f nrf52
    Erasing code and UICR flash areas.
    Applying system reset.

    Part2 (flashing softdevice)

    make VERBOSE=1 flash_softdevice 
    Flashing: s132_nrf52_3.0.0_softdevice.hex
    nrfjprog --program ../../../../../../components/softdevice/s132/hex/s132_nrf52_3.0.0_softdevice.hex -f nrf52 --sectorerase 
    Parsing hex file.
    Erasing page at address 0x0.
    Erasing page at address 0x1000.
    Erasing page at address 0x2000.
    Erasing page at address 0x3000.
    Erasing page at address 0x4000.
    Erasing page at address 0x1B000.
    Erasing page at address 0x1C000.
    Erasing page at address 0x1D000.
    Erasing page at address 0x1E000.
    Applying system reset.
    Checking that the area to write is not protected.
    Programing device.
    nrfjprog --reset -f nrf52
    Applying system reset.

    Part 3 (flashing bootloader_secure-example)

    make VERBOSE=1 flash 
    Flashing: _build/secure_dfu.hex
    nrfjprog --program _build/secure_dfu.hex -f nrf52 --sectorerase
    Parsing hex file.
    Erasing page at address 0x78000.
    Erasing page at address 0x79000.
    Erasing page at address 0x7A000.
    Erasing page at address 0x7B000.
    Erasing page at address 0x7C000.
    Erasing page at address 0x7D000.
    Applying system reset.
    WARNING: A UICR write operation has been requested but UICR has not been
    WARNING: erased. Please verify that the result is correct.
    Checking that the area to write is not protected.
    Programing device.
    nrfjprog --reset -f nrf52
    Applying system reset.

    Part 4 (DFU through nRF Toolbox-app)

    Now I can discover a bt-device DfuTarg within the nRF Connect-app and LED1+LED3 on the nRF52832 DK are lighted up. After selecting the generated pkg-file for the buttonless_dfu-example (see initial post) and the device DfuTarg within the nRF Toolbox-app, I can start the dfu-procedure. When I press 'Upload' the nRF52832 DK is showing a connection state, with LED1 going off while LED2 goes on. The upload-progress gets shown in the app and finally I get the message 'Application has been transferred successfully.', which is resulting in a reset and them immediatly I am back in the bootloader-mode.

    Maybe someone could verify this behaviour with the given files in my initial post!?

    [Edit:] Apparently the problem wasnt the dfu-procedure itself, but some issue within both the bootloader_secure-example and the ble_dfu_send_hex-example regarding the need of doing a hard off-/on-switching for the nRF52832 DK in order to get to the application after completing the dfu-procedure! Isnt it possible to integrate the same kind of 'system-restart' automatically within the code?

    [Edit2:] Now I also added a watchdog-timeout to the bootloader_secure-example (used this tutorial) which gets triggered after 30s of idle-time, but unfortunately this timeout only triggers a soft-reset which isnt enough to get to the application again...