Problem with bootloader-mode after DFU procedure [closed]

Ray Breslin gravatar image

asked 2017-04-12 13:39:50 +0100

updated 2017-04-13 15:00:29 +0100


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 / dfu_test_app_hrm_s132.zip

***(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

pem-Files: dfu_private.zip

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

pkg-Files: dfu_softdevice_bootloader_s132_1.zip / dfu_app_buttonless_s132_2.zip

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 dfu_softdevice_bootloader_s132_1.zip'
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 dfu_app_buttonless_s132_2.zip'

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

edit retag flag offensive reopen delete report spam

Closed as "duplicate question" by Bjørn Spockeli at 2017-04-19 11:36:48 +0100


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...

Ray Breslin ( 2017-04-12 15:01:13 +0100 )editconvert to answer

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!?

Ray Breslin ( 2017-04-12 16:31:23 +0100 )editconvert to answer

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.

Ray Breslin ( 2017-04-13 14:05:55 +0100 )editconvert to answer

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!

Ray Breslin ( 2017-04-13 14:11:25 +0100 )editconvert to answer

2 answers

Sort by » oldest newest most voted
bjorn-spockeli gravatar image

answered 2017-04-19 11:36:26 +0100

Duplicate: https://devzone.nordicsemi.com/questi...

edit flag offensive delete publish link more
Ray Breslin gravatar image

answered 2017-04-13 15:12:19 +0100

updated 2017-04-18 10:16:15 +0100

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...

edit flag offensive delete publish link more

Question Tools

1 follower


Asked: 2017-04-12 13:39:50 +0100

Seen: 554 times

Last updated: april 19