Problems with DFU on nRF52832

[scottl]

Hello,

I am trying to add DFU to an existing product that uses an nRF52832. I have gone through the tutorial here. I am using SDK v15.3.0. I am using the GNU Tools ARM Embedded 6 2017-q1-update toolchain. My process is to first erase the chip then program it with softdevice v6.1.1 then flash the bootloader. The device will advertise "dfuTarg" for a second then triggers a fault and resets. Here is a snippet of the RTT output:

00> <debug> nrf_dfu_ble: Advertising...
00>
00> <debug> nrf_dfu_ble: BLE DFU transport initialized.
00>
00> <debug> nrf_dfu_flash: Initializing nrf_fstorage_sd backend.
00>
00> <debug> app: Enter main loop
00>
00> <error> app: Received a fault! id: 0x00000001, pc: 0x0001479E, info: 0x00000000

I have also run the debugger and noticed it gets to the "loop_forever()" function then at some point it fails in the softdevice. I can flash one of the precompiled bootloaders such as: "bootloader_secure_ble_debug_without_bonds_s132.hex" and it will advertise ok and not enter a fault. I have also tried flashing the bootloader I compiled onto a nRF52840-DK and it advertises normally without throwing a fault. I have tried compiling both the pca10040_ble_debug and the pca10040_ble version, but the result is the same. I tried disabling the button to enter DFU mode in the config file since I don't have a button, but this didn't seem to change anything. Any idea what could cause this fault or why it would work on the development kit and not my hardware?

Thanks,

Scott

[Vidar Berg]

Hello Scott,

Did you hit a breakpoint prior to receiving the fault by any chance? The fault shown in your log is an assertion raised by Softdevice that indicates that it has been unable to process a BLE event in time, and the most common reason for this type of assert is when you let the debugger halt the CPU and then let it resume execution afterwards.

scottl said:

I have also run the debugger and noticed it gets to the "loop_forever()" function then at some point it fails in the softdevice.

Does it loop around address 0x155ce in the Softdevice? This is the location of the "wait for event" loop inside the Softdevice where typically ~99% of the time. In other words, there's a good chance you will end up there if you randomly pause the debugger.

The wait for event loop is entered by calling sd_app_evt_wait().

scottl said:

I can flash one of the precompiled bootloaders such as: "bootloader_secure_ble_debug_without_bonds_s132.hex" and it will advertise ok and not enter a fault. I have also tried flashing the bootloader I compiled onto a nRF52840-DK and it advertises normally without throwing a fault. I have tried compiling both the pca10040_ble_debug and the pca10040_ble version, but the result is the same.

This is harder to explain.. I can't think of an explanation for how your FW would run fine on a DK but not on your custom board. Could you try to change the clock source (NRF_SDH_CLOCK_LF_SRC setting in sdk_config.h) to NRF_CLOCK_LF_SRC_SYNTH to see if it could have anything to do with the 32 Khz crystal mounted on your board?

Best regards,

Vidar

[scottl]

Hi Vidar,

Changing the clock source fixed the problem  Thanks for the help

[Vidar Berg]

Thanks for the update! But I'm suprised the pre-built hex worked on your custom board as it should be built with the same default clock configuration. In any case, for boards that don't have a LF crystal mounted it's generally recommeded to select the internal RC oscillator (NRF_CLOCK_LF_SRC_RC). The Synthezided clock is pretty power hungry since it's derived from the 64 MHz crystal oscillator ( idle current won't get below ~500 uA).

You can use the following configuration to select the RC oscillator:

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