Problems with DFU on nRF52832

RE: Problems with DFU on nRF52832

Vidar Berg — Fri, 17 Sep 2021 14:20:17 GMT

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

RE: Problems with DFU on nRF52832

scottl — Fri, 17 Sep 2021 14:04:42 GMT

Hi Vidar,

Changing the clock source fixed the problem 🤦 Thanks for the help

RE: Problems with DFU on nRF52832

Vidar Berg — Fri, 17 Sep 2021 13:18:01 GMT

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.

[quote userid="108273" url="~/f/nordic-q-a/79735/problems-with-dfu-on-nrf52832"]I have also run the debugger and noticed it gets to the "loop_forever()" function then at some point it fails in the softdevice.[/quote]

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

[quote userid="108273" url="~/f/nordic-q-a/79735/problems-with-dfu-on-nrf52832"]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. [/quote]

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