BLE connection not working with smartphone but with Dongle

[Xandberg]

Hi Nordic Team,

We are working with two nrf52840 chips that communicate with each other via gazell. To change system settings we write characteristics via BLE. Recently we noticed a weird behavior and we have not been able to fix it.

If we activate BLE on one chip (the GZLL-device in our gazell connection) and try to connect it to a smartphone the chip freezes and has to be restarted.

The interesting thing is that it only happens when connecting to smartphones (both IOS and android) but not with the BLE-dongle and PC. Furthermore it´s working on the GZLL-host despite both running the same BLE code. When flashing the GZLL-host software on the GZLL-device chip everything is fine so the problem must lie somewhere in the non-BLE code.

We tried stepping through it with our debugger but since the BLE process is so time-critical we weren't able to spot what exactly is causing the problem. However, we always ended up in: app_error_weak.c - NRF_BREAKPOINT_COND.

We suppose that there are some interrupts or timers in the background that interfere with the BLE connection.

Do you have any ideas about what might cause the problem and how we could fix it?

[Kenneth]

Please build with DEBUG (not RELEASE), then typically the code should go to app_error_fault_handler() where you can find the file name, line number, and error code that caused the "freeze". For difference between DEBUG and RELEASE see this reply:
https://devzone.nordicsemi.com/f/nordic-q-a/73037/glitch-in-analog-audio-output-when-using-i2s-module/306523#306523 

If it's not caused by an assert, then I assume you will need to look at the switching between BLE and GAZELL. Do GAZELL run in time-slot or how is the switching between BLE /GAZELL done? 

[Xandberg]

Hi Kenneth, thank you for your fast reply and your inputs.

We are already building with DEBUG. We actually do end up in app_error_fault_handler() when debugging. However, there is no error information available. The variable values in app_error_save_and_stop() are:

The error id is NRF_FAULT_ID_SD_ASSERT which seems to be caused (or at least influenced) by the debugging and not by the original problem itself according to this answer:
https://devzone.nordicsemi.com/f/nordic-q-a/36021/nrf_fault_id_sd_assert.
If we just let the chip run and stop the debugger once It freezes we are stuck in a HardFault_Handler in gcc_startup_nrf52840.S, line 300.

We use the same antenna for GAZELL and BLE but we do not use them simultaneously. We experience the same problem even if start BLE right after rebooting and never activate GAZELL.

[Kenneth]

What softdevice and version is this?

Kenneth

[Xandberg]

We use softdevice s113, version s113_nrf52_7.0.1 from SDK 16.0.0

[Kenneth]

The error is consistent with an application interrupt is preventing the softdevice LL to run. Do you by any chance disable interrupts for a period of time and/or have any interrupt with priority 0?

If that is not the case, what lfclk parameters have you init the softdevice with?

Kenneth

[Xandberg]

Disabled interrupts is a great approach that we had not tried yet. Unfortunately we never disable the interrupts and the highest priority interrupt we use is 3.

We initialize the LFCLK at startup with these settings:

NRF_CLOCK->LFCLKSRC  = (CLOCK_LFCLKSRC_SRC_RC << CLOCK_LFCLKSRC_SRC_Pos);

Later we configure the BLE stack using the default settings:

err_code = nrf_sdh_ble_default_cfg_set(APP_BLE_CONN_CFG_TAG, &ram_start);

I hope these are the parameters you were asking for.

[Kenneth]

I want to know the values you have set for these 4 defines that is used in nrf_sdh_enable_request():

nrf_clock_lf_cfg_t const clock_lf_cfg =
{
.source = NRF_SDH_CLOCK_LF_SRC,
.rc_ctiv = NRF_SDH_CLOCK_LF_RC_CTIV,
.rc_temp_ctiv = NRF_SDH_CLOCK_LF_RC_TEMP_CTIV,
.accuracy = NRF_SDH_CLOCK_LF_ACCURACY
};

Kenneth