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

Custom GATT - central hangs when connecting: nRF52810 + S112 | armgcc @SDK14.2

Hello,

I am trying to get a BLE peripheral with a single service containing a single custom read-write characteristic.

Unfortunately, any time I initiate a connection to the device the device stops advertising and the connection hangs. The connection never times out or fails, the peripheral never disconnects.

My connection params say BLE should disconnect on fail:

ble_conn_params_init_t cp_init = {
	.p_conn_params                  = NULL,
	.first_conn_params_update_delay = FIRST_CONN_PARAMS_UPDATE_DELAY,
	.next_conn_params_update_delay  = NEXT_CONN_PARAMS_UPDATE_DELAY,
	.max_conn_params_update_count   = MAX_CONN_PARAMS_UPDATE_COUNT,
	.start_on_notify_cccd_handle    = BLE_GATT_HANDLE_INVALID,
	.disconnect_on_fail             = true,
	.evt_handler                    = NULL,
	.error_handler                  = ble_err_callback
};

Here are the parameters being used:

#define FIRST_CONN_PARAMS_UPDATE_DELAY  APP_TIMER_TICKS(20000) /**< Time from initiating event (connect or start of notification) to first time sd_ble_gap_conn_param_update is called (15 seconds).*/
#define NEXT_CONN_PARAMS_UPDATE_DELAY   APP_TIMER_TICKS(40000) /**< Time between each call to sd_ble_gap_conn_param_update after the first call (30 seconds per BLE spec). */
#define MAX_CONN_PARAMS_UPDATE_COUNT    3 /**< Number of attempts before giving up the connection parameter negotiation. */

I have enabled all possible debugging defines at level 4 in sdk_config.h, all I am getting is:

<info> clock: Function: nrf_drv_clock_init, error code: NRF_SUCCESS.
<warning> nrf_sdh_ble: RAM starts at 0x20001CD0, can be adjusted to 0x20001A40.
<warning> nrf_sdh_ble: RAM size can be adjusted to 0xE5C0.
<info> app: running

Note that:

  • The last NRF_LOG_INFO above is printed by the app (me) after successful return from sd_ble_gap_adv_start().
  • Right after this print my application loops on sd_app_evt_wait() and does nothing else.
  • I have an NRF_LOG_INFO on ble_evt_handler() but this is never called when the central hangs while attempting to connect.
  • I also have an NRF_LOG_ERROR in my ble_err_callback() but this is never called.
  • The application is not doing anything else, no other modules in use.

A specific note on the linker script (and memory errors I'm getting):

  • I'm using

nRF5_SDK_14.2.0_17b948a/examples/ble_peripheral/ble_app_blinky/pca10040e/s112/armgcc/ble_app_blinky_gcc_nrf52.ld

  • This is DIFFERENT from e.g.

nRF5_SDK_14.2.0_17b948a/examples/ble_peripheral/ble_app_template/pca10040e/s112/armgcc/ble_app_template_gcc_nrf52.ld

  • The values given in the warning above are DIFFERENT AGAIN from either of these linker scripts
  • Don't see documentation in the SDK which explains how to determine what I need here.

The current frustration in attempting to debug lies around the fact that:

  • No info forthcoming from the SoftDevice, though all possible print levels are set to 'debug' (4).
  • No source code given for the SoftDevice, can't understand by reading code, can't instrument with print statements.
  • Diligently testing all calls to the SoftDevice - they all return 0 and no hints of a problem.
  • The same code works on nRF51 and SDK12.
  • Feel I'm missing an "overview" or "conceptual" document which helps me grok what's really happening on the SoftDevice side. It doesn't help that I don't grasp all the nuances of the BLE spec (in my defense it's literally thousands of pages).
  • Nagging suspicion it's a minor/stupid mistake on my side - but ran out of ideas on how to find it.

I'm finding it hard to isolate and prove whether the problem lies with (given in order of likelihood):

  • incorrect options (or bad COMBINATION of options) given to SoftDevice
  • missing and/or wrong sequence of calls to SoftDevice from the app
  • sdk_config.h
  • linker script
  • build system (compile/link flags)
  • SoftDevice bug
  • hardware

What I'm hoping to get here is NOT "can you show us your code so we can debug it" ... I'd like to get some constructive advice on how to actually dig into SoftDevice issues and how to approach finding the inconsistencies between my (surely flawed) understanding of the Doxygen commentary scattered in the SDK and what's really happening in the black-box SoftDevice I can't go and read.

I say this because last time around I spent 3-4 hours copy-pasting code until it worked ... in SDK12, for nRF51.

But now it's broken in SDK14 and I'm back to square zero ... and even if I fix this now I will live forever dreading the day I have to add a feature or change something relating to the BLE side - since I'll still not understand what I'm doing!

Teach a man to fish please ;)

  • The answer seems to be that the -flto flag subtly breaks the build on PCA10040e +S112 using armgcc 7-2017-q4-major

    ... seriously debated removing the above rant since the answer is so anticlimactic, but I'll leave it here where it might help, and in monument to the self-inflicted trivialities that can ruin a programmer's day.

  • I see the same issue here with the latest arm-none-eabi, where it get's stuck trying to transfer data over UART (nrf_log). It looks like -flto is trigger happy and removes IRQHandler's (and links them all in the Default_Handler) with the latest arm-none-eabi:

    (gdb) print UARTE0_IRQHandler
    $5 = {<text variable, no debug info>} 0x1b092 <WDT_IRQHandler>
    (gdb) print Default_Handler
    $6 = {<text variable, no debug info>} 0x1b092 <WDT_IRQHandler>
    

    I feel your pain. compiler issues are the worst. It looks like you're not the only person seeing this: bugs.launchpad.net/.../1743765

    Humble regards, Håkon

Related