DFU Bootloader crashes within softdevice code

[keenanda]

I am working on a BLE bootloader using SDK 14.2.0 on an NRF52832 device, using softdevice version 5.0.0. I am able to get the bootloader up and running, and I am able to see it using the nRF Toolbox app on my phone. I select a the device using the nRF Toolbox app and select a file to perform DFU. As soon as I click "Upload" to perform the DFU, the bootloader app crashes within the softdevice code where I cannot glean any information from the stack trace. I have put breakpoints throughout the code including in all of the BLE event callback routines and I never even get a callback with the BLE connection event.

The crash always occurs immediately at function address 0x00021c96. Here is a the output from the backtrace within gdb.

#0  0x00021c96 in ?? ()

No symbol table info available.

#1  <signal handler called>

No symbol table info available.

#2  0x00000000 in ?? ()

No symbol table info available.

#3  <signal handler called>

No symbol table info available.

#4  0x00002e6a in ?? ()

No symbol table info available.

#5  0x00013d6c in ?? ()

No symbol table info available.

Backtrace stopped: previous frame identical to this frame (corrupt stack?)

(gdb)

[MartinBL]

Hi,

Are you using a custom device without an external LF crystal? It may seem like your bootloader is waiting for the crystal to start. But if it waits for a non-existing crystal then obviously that would be a problem. 

[keenanda]

Yes we have an external LF crystal. We have an application that runs on the device and uses the same clock configuration that runs perfectly fine. Here is our clock configuration:

#define NRF_CLOCK_LFCLKSRC      {.source        = NRF_CLOCK_LF_SRC_XTAL, \

                                 .rc_ctiv       = 0,                     \

                                 .rc_temp_ctiv  = 0,                     \

                                 .xtal_accuracy = NRF_CLOCK_LF_XTAL_ACCURACY_20_PPM}

[keenanda]

I am currently looking into whether it may be a clock issue. Just wondering if you had encountered something similar that was caused by a clock issue?

[MartinBL]

I can't say for sure that it is a clock issue. I believe that __WFE() resides at address 0x00013d6c though, which indicates that the system has been in sleep mode. 

If you are able to successfully run a "normal example" using an external crystal, but without the bootloader, then we can conclude that the crystal works.