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

Thanks, the log shows that nrf_bootloader_init()  fails because ble_dfu_transport_init() in nrf_dfu_ble.c is returning NRF_ERROR_INVALID_LENGTH (9) which means the issue is not related to the clock source configuration at least. But I don't understand why ble_dfu_transport_init() would return this error.  Is there any chance the original project or SDK source files may have been modified? In that case, it may be a good idea to try again with new clean SDK copy.

To debug your current project further we would first need to find out where the error occur in ble_dfu_transport_init(). You can do that by adding more logging in the function, or by using breakpoints.

Thanks for your reply. I have isolated the problem to the ble_stack_init function, likely in the nrf_dfu_mbr_init_sd() function. I am not sure where it is failing after that, the code is somewhat hard to parse. 

To narrow down the problem a bit more, could you please try to flash the pre-compiled hex file in "/nRF5_SDK_17.1.0_ddde560/examples/dfu/secure_bootloader/pca10056_s140_ble_debug/hex" to see if it gives the same error? I still can't think of any obvious reasons for how ble_stack_init() would return with NRF_ERROR_INVALID_LENGTH

Programming with nrfjprog:

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

Ok I have run the code you suggested in powershell, and got a Run. message. The DfuTarg does not show up still. Is there a debug log I can check?

Thanks

Yes, you can use jlinkRTTViewer to view the logs.

Yes, you can use jlinkRTTViewer to view the logs.