Error 34 (0x22): GATT CONN LMP TIMEOUT in nrfConnect log Rigado BMD-340

[apdobaj]

When running our hardware using the J-Link debug in connector on the dev kit, BT is fully functional. But when we try to run using the very same power source (ie, the dev kit) without being hooked up to J-link (serial wire debug, SWDIO, SWCLK, etc) we get a "Error 34 (0x22): GATT CONN LMP TIMEOUT" message in nrf Connect log file and we can't even connect. I've futzed with the settings for MIN_CONN_INTERVAL  and MAX_CONN_INTERVAL (we get a run-time error if we set this parameter to greater than 50) to no avail. Here's the info from the log file:

D 16:50:21.822 [Broadcast] Action received: android.bluetooth.device.action.ACL_CONNECTED
W 16:50:21.832 Connection parameters update failed with status 34 (interval: 45.0ms, latency: 0, timeout: 5000ms)
E 16:50:21.832 Error 34 (0x22): GATT CONN LMP TIMEOUT
D 16:50:21.844 [Callback] Connection state changed with status: 34 and new state: DISCONNECTED (0)
E 16:50:21.845 Error 34 (0x22): GATT CONN LMP TIMEOUT
I 16:50:21.845 Disconnected
D 16:50:21.862 [Broadcast] Action received: android.bluetooth.device.action.ACL_DISCONNECTED

[apdobaj]

I've discovered that the difference in behavior is due to whether or not the firmware is being run from the debugger or not. If run from the debugger everything is good, when run without the debugger is when error 34 happens. Is this a timing issue of some sort? 

[Kenneth]

It can be pretty much anything, an on-air sniffer log could help:
https://www.nordicsemi.com/eng/Products/Bluetooth-low-energy/nRF-Sniffer/(language)/eng-GB (v2 beta preferred)

Is it possible that you have some debugging enabled (e.g. UART) that may have some floating pins, which by accident floats different when debugger is connected (e.g. GND connected). Are you able to detect if there are any asserts or disconnect reasons occurring on the peripheral?

What SD, SDK and example have you based your code on? 

[apdobaj]

Hi Kenneth, thanks for the response. It turns out this was due to a loose sensor wire being held down by the tag connect device clamp and when taking the cable off the sensor would activate randomly. This issue can be closed.