DFU Secure Boot Example wont work

Hello Andrew,

Pleas try to run the "debug" variant of the project (pca10056_s140_ble_debug) as it already has logging over RTT enabled.  With logging enabled you should be able to view the debug messages from the terminal window whenever you start a new debug session in Segger Embedded studio:

Also, if your custom board does not come with the optional 32KHz crystal mounted, please make sure you have selected the internal RC oscillator as the LF clock source with the config settings below. Otherwise the Softdevice may end up in an infinite loop waiting for the crystal oscillator to start.

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

// <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 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 2
#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

Best regards,

Vidar

Vidar, 

Thanks for your reply. I have now run the debug mode, and have tried to figure out the error, but am unable to fix it. This is the debug log. I have used the debug mode to isolate the issue to the bl 0x000F4958 <nrf_bootloader_init> line in main.c. (line 141). 

I have tried to switch the clock as you suggested, but that has not fixed it for me. The custom board does have a crystal onboard, so that should be ok. 

Here is the debug log:

<info> app: Inside main
<debug> app: In nrf_bootloader_init
<debug> nrf_dfu_settings: Calling nrf_dfu_settings_init()...
<debug> nrf_dfu_flash: Initializing nrf_fstorage_nvmc backend.
<debug> nrf_dfu_settings: Using settings page.
<debug> nrf_dfu_settings: Copying forbidden parts from backup page.
<debug> nrf_dfu_settings: Destination settings are identical to source, write not needed. Skipping.
<info> nrf_dfu_settings: Backing up settings page to address 0xFE000.
<debug> nrf_dfu_settings: Destination settings are identical to source, write not needed. Skipping.
<debug> app: Enter nrf_bootloader_fw_activate
<info> app: No firmware to activate.
<info> app: Boot validation failed. No valid app to boot.
<debug> app: DFU mode because app is not valid.
<info> nrf_bootloader_wdt: WDT is not enabled
<debug> app: in weak nrf_dfu_init_user
<debug> app: timer_stop (0x200057D4)
<debug> app: timer_activate (0x200057D4)
<info> app: Entering DFU mode.
<debug> app: Initializing transports (found: 1)
<debug> nrf_dfu_ble: Initializing BLE DFU transport
<debug> app: Failed to initialize transport 0, error 9
<error> app: Could not initalize DFU transport: 0x00000009
<error> app: Received an error: 0x00000003!

I have been trying to find what this error might mean, but I am unable to resolve it. 

Thanks,

Andrew

Ok so I have uploaded the hex file, and now it works correctly, I see DfuTarg show up, and can upload firmware. My nordic sdk is a fresh install, what should I check to see where it might be messed up? I followed the following guide to set up my SDK: 

devzone.nordicsemi.com/.../getting-started-with-nordics-secure-dfu-bootloader

That is good know, thanks. As you are using a fresh SDK install, the only other explanation I can really think of is that it must be related your build setup somehow.

Were you using any of the toolchain/IDE versions listed in the SDK release notes when you built the bootloader?

SDK Release Notes:

nRF5 SDK v17.1.0
------------------------
Release Date: August, 2021

Highlights:

- Added support for the new versions of the nRF52 devices:
- nRF52820 revision 3
- nRF52832 revision 3
- nRF52833 revision 2
- nRF52840 revision 3
(Note: Programming these requires nrfjprog v10.13 or newer.)
- Updated nrf_oberon to v3.0.8.
- Updated Mbed TLS to v2.16.10.

The following toolchains/devices have been used for testing and verification:

- ARM: MDK-ARM version 5.25
- GCC: GCC ARM Embedded 9.2020-q2.major
- IAR: IAR Workbench 7.80.4
- SES: SES 5.42a

Edit: I found this post which describes the exact same problem with the bootloader when building with GCC 11.x: https://devzone.nordicsemi.com/f/nordic-q-a/85677/sdk-17-1-0-secure-bootloader-runtime-failure-when-compiled-with-current-gcc-11-2-0.  Are you using the same version by any chance?

GCC ARM Embedded 9.2020-q2.major can be downloaded here: https://developer.arm.com/downloads/-/gnu-rm

Hi, sorry for the late reply. That does look like exactly the issue I am having, but I am already using that gcc version. I am not using 11.x, but rather the 10.3 version. This is quite confusing.

Another update, I have tested this with the nrf52840 development kit, and still get the same behavior. I am on gcc version 10.3, and have tested this with both sdk versions 17.1 and 15.3

A third note, the hex file worked only when I uploaded it through the nrfConnect desktop app. When I uploaded it through the nrfjprog command it did not work. (DFUTarg did not show up)

A third note, the hex file worked only when I uploaded it through the nrfConnect desktop app. When I uploaded it through the nrfjprog command it did not work. (DFUTarg did not show up)

Hi,

Strange. I really thought it had to be the GCC version. I have not managed to reproduce the problem here either, unfortunately. Here is what I did in my attempt to reproduce it on my end:

1. Connected a nRF52840 DK to the PC

2. Changed toolchain path from GCC ARM Embedded 9.2020-q2.major to gcc-arm-none-eabi-10.3-2021.10 in /nRF5_SDK_17.1.0_ddde560/components/toolchain/gcc/Makefile.posix

3. Opened the terminal in /nRF5_SDK_17.1.0_ddde560/examples/dfu/secure_bootloader/pca10056_s140_ble_debug/armgcc

4. Ran 'make flash_softdevice && make flash' to program the board. Note: these makefile targets do use nrfjprog

5. Observed that the board was advertising as "DFUTarg"

Log output after running 'make flash_softdevice && make flash' 

Do you notice any differences in my approach above compared to yours?

anisaw said:

When I uploaded it through the nrfjprog command it did not work.

There should be any difference between programming the hex file with nrfjprog vs the programmer app. Did you remember to include the reset command to start program execution?

$ nrfjprog --program secure_bootloader_ble_s140_pca10056_debug.hex --chiperase --reset