Buttonless ble dfu example not working in sdk v15.0.0

[julienm]

Hello,

I would like to use the bouttonless dfu feature in my application, but I have not been able to run the sdk example ble_app_buttonless_dfu.

The application does not work like the compiled example "ble_app_buttonless_dfu_without_bonds_s132_with_setting_page.hex" in the folder "examples \ dfu \ secure_dfu_test_images \ ble \ nrf52832", there is no advertising, the led does not flash. But if we press button 4 the bootloader starts.

Before trying the buttonless example, I tried with the bootloader compiled with my own dfu public key, then generated the setting page with my application and it works well.
So I think it's not a bootloader problem.

I use sdk v15.0.0 and compile with gcc (arm-none-eabi v7.2.1)

I use the NRF52-DK development platform.

As I have not managed to use the example ble_app_buttonless_dfu as it is, I find myself stuck in my project.

I also read the other topics related to the DFU BLE, but it is not the same version of sdk, or the same problem.

Can you help me find a solution?

Thank you very much,

[Einar Thorsrud]

Hi,

The ble_app_buttonless_dfu_without_bonds_s132_with_setting_page.hex has been made from the exact same source code as the ble_app_buttonless_dfu example and secure_bootloader, so it should behave in the same way. Did you remember to generate and flash a valid setting page together with the application that you have compiled? You need to flash the following parts (separately or merged):

• SoftDevice
• Bootloader
• Applicaton
• Bootloader setting page

[julienm]

Hello sir,

Indeed I flashed all these elements and generated the setting page in my previous tests, and I tried again today.

So I have:

Erase soc:

=> make erase

flashed the softdevice:

=> make flash_softdevice

flashed the bootloader:

1: installed micro-ecc

2: generated a private and public key

3: replaced sfu_public_key.c

4: make flash

Compiled the application ble_app_buttonless_dfu

=> make

Generate setting page:

=> nrfutil settings generate --family NRF52 --application ble_app_buttonless.hex --application-version 1 --bootloader-version 1 --bl-settings-version 1 bootloader_setting_page.hex

Merge ble_app_buttonless.hex and bootloader_setting_page.hex:

=> mergehex --merge ble_app_buttonless.hex bootloader_setting_page.hex --output ble_app_buttonless_with_setting_page.hex

And finaly flash and reset:

=> nrfjprog -f nrf52 --program ble_app_buttonless_with_setting_page.hex --sectorerase --reset

I still have the same problem.

I do not know what I could have forgotten.

[Einar Thorsrud]

I have not been able to reproduce the issue.

Pressing button 4 during reset as you do forces the bootloader to stay in DFU mode instead of starting the application, so it is expected that you see that the bootloader is running in this case (with LED 1 and LED 2 lit). It would also stay in DFU mode if there was no valid application, so it seems that everything (including the bootloader settings page) is OK seen from the bootloader, and that it jumps to the application, but that something happens there.

• Have you made any modifications in the example application?
• Do you get the same behaviour if you use the _debug variant of the bootloader with the public key that is shipped with the SDK (you will not be able to sign the DFU image in this case and actually perform the DFU but it will be interesting to see if the behaviour is different).
• Can you use a debugger to check the state of the device at the point where it should have started the application (after you have flashed the merged app settings / setting page hex and reset the device)? What is the value of the stack pointer?
• Are you using the nRF52 DK or custom HW?

[julienm]

Hello,

I start by checking with the nRF52-DK then I try on a module SKB369 (without LF XTAL). Ido not have a debugger, only the one built into the NRF52-DK.

I tried starting all over again from the beginning:

1. unzip nRF5_SDK_15.0.0_a53641a.zip

2. Edit components/toolchain/gcc/Makefile.posix with my configuration:

GNU_INSTALL_ROOT ?= /home/julien/opt/gcc-arm-none-eabi-7-2017-q4-major/bin/
GNU_VERSION ?= 7.2.1
GNU_PREFIX ?= arm-none-eabi

3. build ble_app_buttonless_dfu example

4. download and build micro-ecc

unzip micro-ecc (https://github.com/kmackay/micro-ecc) inside external/micro-ecc/ folder

chmod a+x build_all.sh

./build_all.sh

5. build secure_bootloader dfu example (debug version):

cd examples/dfu/secure_bootloader/pca10040_ble_debug/armgcc/

make

6. Create bootloader settings for ble_app_buttonless_dfu example:

nrfutil settings generate --family NRF52 --application ble_app_buttonless.hex --application-version 1 --bootloader-version 1 --bl-settings-version 1 bootloader_setting_page.hex

7. merge application with settings page:

mergehex --merge ble_app_buttonless.hex bootloader_setting_page.hex --output ble_app_buttonless_with_setting_page.hex

8. flash NRF52-DK.

 

I have Led1 blinking, so i think the application works with a debug bootloader.

then I tried with the normal version, after re-generating the private and public keys and it worked.

I compared the original "components" folder with that of my project and I saw that I made some modifications:

components / toolchain / gcc / Makefile.posix differ (gcc configuration)
components / boards / boards.h differ (add my custom board)
components / boards / SKB369.h new (custom board definition file)
components / libraries / bsp / bsp.cdiff (add BSP_BUTTON_ACTION_RELEASE event in switch-case structure)
components / libraries / bsp / bsp.h differ (add BSP_EVENT_KEY_x_PUSH and BSP_EVENT_KEY_x_RELEASE in bsp_event_t structure)

I added each change one by one in the original code and it still works with NRF52-DK board.

I would not know where the problem came from but I think it is corrected, Thank you!

New problem: I can not operate the buttonless application if I disable the LF quartz (cut SB1 and SB2 short).

Bootloader works well but not the application. I configured well in sdk_config.h for both:

For bootloader:

// ================================================ ==========

// <h> Clock - SoftDevice clock configuration

// ================================================ ==========
// <o> NRF_SDH_CLOCK_LF_SRC - SoftDevice clock source.
 
// <0 => NRF_CLOCK_LF_SRC_RC
// <1 => NRF_CLOCK_LF_SRC_XTAL
// <2 => NRF_CLOCK_LF_SRC_SYNTH

#ifndef NRF_SDH_CLOCK_LF_SRC
#define NRF_SDH_CLOCK_LF_SRC 0
#endif

// <o> NRF_SDH_CLOCK_LF_RC_CTIV - SoftDevice calibration timer interval.
#ifndef NRF_SDH_CLOCK_LF_RC_CTIV
#define NRF_SDH_CLOCK_LF_RC_CTIV 16
#endif

// <o> NRF_SDH_CLOCK_LF_RC_TEMP_CTIV - SoftDevice Calibration timer interval under constant temperature.
// <i> How often (in a number of calibration intervals) the RC oscillator shall be calibrated
// <i> if the temperature has not changed.

#ifndef NRF_SDH_CLOCK_LF_RC_TEMP_CTIV
#define NRF_SDH_CLOCK_LF_RC_TEMP_CTIV 4
#endif

// <o> NRF_SDH_CLOCK_LF_ACCURACY - External clock accuracy used in the LL to compute timing.
 
// <0 => NRF_CLOCK_LF_ACCURACY_250_PPM
// <1 => NRF_CLOCK_LF_ACCURACY_500_PPM
// <2 => NRF_CLOCK_LF_ACCURACY_150_PPM
// <3 => NRF_CLOCK_LF_ACCURACY_100_PPM
// <4 => NRF_CLOCK_LF_ACCURACY_75_PPM
// <5 => NRF_CLOCK_LF_ACCURACY_50_PPM
// <6 => NRF_CLOCK_LF_ACCURACY_30_PPM
// <7 => NRF_CLOCK_LF_ACCURACY_20_PPM
// <8 => NRF_CLOCK_LF_ACCURACY_10_PPM
// <9 => NRF_CLOCK_LF_ACCURACY_5_PPM
// <10 => NRF_CLOCK_LF_ACCURACY_2_PPM
// <11 => NRF_CLOCK_LF_ACCURACY_1_PPM

#ifndef NRF_SDH_CLOCK_LF_ACCURACY
#define NRF_SDH_CLOCK_LF_ACCURACY 1
#endif

For buttonless_dfu application the same modification as above and also:

#ifndef CLOCK_CONFIG_LF_SRC
#define CLOCK_CONFIG_LF_SRC 0
#endif

#ifndef NRFX_CLOCK_CONFIG_LF_SRC
#define NRFX_CLOCK_CONFIG_LF_SRC 0
#endif

But the buttonless_dfu application always runs only with the LF quartz (if I reconnect the shorts SB1 and SB2, it works).

Can you help me for this problem too?

[Einar Thorsrud]

Hi,

It should be enough to set CLOCK_CONFIG_LF_SRC to 0 (RC). Can you verify that you are modifying the correct sdk_config.h? Can you verify with a debugger or by printing/logging the value that NRFX_CLOCK_CONFIG_LF_SRC and CLOCK_CONFIG_LF_SRC really have the expected value (0)?