Trying to Integrate DFU and now encountering bootloops due to sd_softdevice_enable()

[Mason]

I've been going off of the Buttonless DFU example to integrate DFU functionality into an existing project on a custom board. While I seem to have added the necessary includes and code to compile without errors, my board bootloops when it executes the code. After stepping through the code in debug mode in Eclipse, it appears that the hard fault occurs at the sd_softdevice_enable_request(), in particular when it makes the SVCALL to sd_softdevice_enable(). I'm unable to see what the actual signal returns to induce the failure.

I modified my linker script to match the memory layout of the buttonless DFU example. I also added relevant DFU configuration code to sdk_config.h, and then integrated the appropriate methods for initializing DFU from the example (app_shutdown_handler, ble_dfu_evt_handler, pm_evt_handler, peer_manager_init, delete_bonds, advertising_start) as well as necessary additions to services_init() and ble_init().

The curious thing is that all of these additions occur after the call to sd_softdevice_enable_request(). This makes me suspect that the problem has to do with changes to sdk_config.h, or changes to my Makefile. The biggest changes to sdk_config.h appear to be changing PEER_MANAGER_ENABLED from 0 to 1, PM_CENTRAL_ENABLED from 1 to 0, NRF_SDH_BLE_GAP_EVENT_LENGTH 7 to 3, NRF_SDH_BLE_GATT_MAX_MTU_SIZE 247 to 23, NRF_SDH_BLE_SERVICE_CHANGED 0 to 1.

For the Makefile, the memory layout was altered from

MEMORY
{
  FLASH (rx) : ORIGIN = 0x23000, LENGTH = 0x5D000
  RAM (rwx) :  ORIGIN = 0x20002A68, LENGTH = 0xD598
  
}

to

MEMORY
{
  FLASH (rx) : ORIGIN = 0x23000, LENGTH = 0x55000
  RAM (rwx) :  ORIGIN = 0x20002180, LENGTH = 0xde80
  
}

with an additional section:

  .svc_data :
  {
    PROVIDE(__start_svc_data = .);
    KEEP(*(.svc_data))
    PROVIDE(__stop_svc_data = .);
  } > FLASH

I can include any additional files or sections of code. I realize this isn't very much to go off of, but I'm scratching my head over this, seeing as the bootloop is occurring at a point in the code in which things have not been altered prior to attempting to integrate the DFU code.

EDIT: there is one other detail I forgot to mention that may be a major factor here: In order to resolve an Implicit Declaration error within my build, I included "nrf_sdm.h" within the file initializing my BLE stack. This wasn't included in the example code, perhaps its resulting in improper initialization of the soft device.

[bjorn-spockeli]

Ok, that is progress. If your project runs on a nRF52 DK then we could go private and you could share the full project. However, before we do that could you put a breakpoint in app_error_handler_bare() again and then see which error code that is returned and which sd_ - function that returns it?

 

[Mason]

Unfortunately I'm seeing the same behavior as before. I don't manage to get the app_error_handler_bare(), just the <signal handler called>() at 0xfffffff9, triggered by sd_softdevice_enable() in nrf_sdm.h line 310

I'll spend some time seeing if I can build the project on the nrf52DK.. as far as my understanding goes all of our code should build, but we have some external components we interface with over gpio and spi. I can likely modify the project to get it to a working state.

If there's nothing else we can do here, should I close this thread?

[bjorn-spockeli]

Well, other than the incorrect clock configuration (or damaged LFXO) then the only thing I can think of that could case the application to hang on sd_softdevice_enable() is that you've flashed the incorrect softdevice or not flashed it at all. 

No, I prefer to have the context, rather than creating a new question. So we can just keep it open, but I'll put it in a waiting state and then I will get a notification once you post a reply.

[Mason]

If I flash builds that don't have the DFU sections added / enabled, our board is able to advertise and perform all other regular bluetooth functionality. Flashing the DFU build never manages to get that far. I'm using s132_nrf52_5.0.0_softdevice.hex from the SDK.

The Flash memory layout in the makefile is still starting at the same location, so I don't think its an issue of the wrong softdevice / the soft device is getting overwritten.

[bjorn-spockeli]

OK, good. Then we can rule that out. Does the non DFU builds also have the same define values you listed in the question, i.e. 
NRF_SDH_BLE_GAP_EVENT_LENGTH  3, NRF_SDH_BLE_GATT_MAX_MTU_SIZE  23, NRF_SDH_BLE_SERVICE_CHANGED  1.