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]

Hi Mason,

I apologize for the late reply. 

I realize that I forgot to ask which SDK version you were using?Judging by the values in the linker script it could look like its SDK v14.x.0? If the device is resetting then it is likely that its one of the APP_ERROR_CHECK(err_code) calls that are asserting. Could you turn of any code optimization in Eclipse, compile the application , start a debug session and set a breakpoint in app_error_handler_bare() in app_error.c and see if you enter the error handler? If you do please examine the call stack to see where the assert originated from. 

Bjørn

 

[bjorn-spockeli]

If its the sd_softdevice_enable() call returns an error code other than NRF_SUCCESS, then please provide the error code here. 

[Mason]

I realized I made a bit of an error - I did have a NRF_CLOCK_LFCLKSRC defined in my custom_board.h file, which used to be defined to be the following:

#define NRF_CLOCK_LFCLKSRC      {.source       = NRF_CLOCK_LF_SRC_XTAL,      \
                                 .rc_ctiv      = 0,                          \
                                 .rc_temp_ctiv = 0,                          \
                                 .accuracy     = NRF_CLOCK_LF_ACCURACY_20_PPM}

When I replaced this block with the one you provided (effectively altering the values of rc_ctiv from 0 to 16, and rc_temp_ctiv from 0 to 2), I find that I still see the exact same behavior.

What's curious, is that when I look at the values of clock_lf_cfg in nrf_sdh.c via the debugger when stepping through the code, rc_ctiv and rc_temp_ctiv are both set to 0. So I suspect that my definition is being overwritten, though I'm unsure of where this is occurring.

Do I need to modify sdk_config.h as well?

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

(altering relevant values to 2 and 16 still sees a failure at initialization of the softdevice, though I don't believe I'm bootlooping anymore)

Thanks for all the help so far. If it would make things easier, I could open a private ticket with my full project enclosed.

[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.

[Mason]

Non-DFU builds have the following properties:

NRF_SDH_BLE_GAP_EVENT_LENGTH: 7

NRF_SDH_BLE_GATT_MAX_MTU_SIZE: 247

NRF_SDH_BLE_SERVICE_CHANGED: 0

[bjorn-spockeli]

Ok, if your are seeing the board advertising with NRF_SDH_BLE_GATT_MAX_MTU_SIZE 247 and NRF_SDH_BLE_GAP_EVENT_LENGTH 7 then there should not be any issues with 23 and 3. Service changed should also not lead to the sd_softdevice_enable() call to hang. 

I think the best option now is to make this case private and then share the entire project so that I can try to debug it on a NRF52 DK.

 

 

[Mason]

I made a new private topic over at: https://devzone.nordicsemi.com/support/207479

I'm not sure how to make this existing case private.. or how to close it without flagging a particular reply as an answer.