This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Why am I seeing an LL_REJECT_IND from the slave intermittently?

I have an nRF51822-based peripheral using the SoftDevice 110 v7.0.0 and SDK v6.0.0. The peripheral uses two custom characteristics under a single custom service. I'm using the Device Manager. The central is an Android app using the new Android L preview BLE stack.

About half the time the central attempts to connect to the GATT server, discover services, and bond, the connection is immediately dropped. Here's a Wireshark screenshot and log of when that happens.

screenshot_wireshark_reject.png

ll_reject_ind_2014-08-29.pcapng

And here are my security parameters:

// Timeout for Pairing Request or Security Request (in seconds).
#define SEC_PARAM_TIMEOUT                 30

// Perform bonding.
#define SEC_PARAM_BOND                    1

// Man In The Middle protection NOT required.
#define SEC_PARAM_MITM                    0

// No I/O capabilities.
#define SEC_PARAM_IO_CAPABILITIES         BLE_GAP_IO_CAPS_NONE

// Out Of Band data not available.
#define SEC_PARAM_OOB                     0

// Minimum encryption key size.
#define SEC_PARAM_MIN_KEY_SIZE            7

// Maximum encryption key size.
#define SEC_PARAM_MAX_KEY_SIZE            16

I'd say this happens about a third to half the time. The rest of the time the connection is fine. Why is this happening? How do I debug this?

[Edit]

Here's the log from nRFLogger/MCP app on Android L:

mcp_log_disconnect_2014-09-02.txt

Parents
  • Case closed. Before calling dm_init(), I wasn't initialising init_data.clear_persistent_data in my code, so the behaviour of the Device Manager was non deterministic and depended on what had been in memory beforehand. Thanks to Anders for spotting it.

Reply
  • Case closed. Before calling dm_init(), I wasn't initialising init_data.clear_persistent_data in my code, so the behaviour of the Device Manager was non deterministic and depended on what had been in memory beforehand. Thanks to Anders for spotting it.

Children
Related