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]

Hello Kenneth,

It´s me again. After a lot of further investigation we finally managed to solve the problem. However, we still do not completely understand it.

Apparently there is some timing problem with the log messages that causes the chip to freeze. We were able to solve this by either changing the sdk_config.h macro PM_LOG_ENABLED to 0 or by building with RELEASE settings (we have always been building in DEBUG).

If you have any idea about why the error occurs and espeacially why it only occurs when connecting to mobile phones we appreciate some insight. If not, we are just happy to finally have it solved.