This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

DFU Bootloader crashes within softdevice code

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)

Parents
  • 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. 

  • 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}

Reply
  • 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}

Children
No Data
Related