CC2640R2F: Bond manager error: SMP_PAIRING_FAILED_UNSPECIFIED

Hi,

There could be many reasons to get this error code SMP_PAIRING_FAILED_UNSPECIFIED from memory allocation errors to key generation failure to multiple bonding failure. Are you doing any other processing after the connected state?

Best wishes

Zahid,

The connection parameters, MTU, and DLE all get negotiated right after the connection is established. I'm wondering if this is what's tripping up the bond manager. I should be able to capture things on a sniffer tomorrow, so hopefully that will shed some more light on the issue. I'll report back once I have that data.

The peripheral is responsible for initiating bonding, is there any way to manually kick of the bonding, or delay it a bit so the other processing that happens when a connection is initiated can complete first? I tried setting the GAPBOND_INITIATE_WAIT parameter to 750 msec, but it didn't seem to have any effect.

-Josh

The sniffer capture didn't really tell me much, although it does provide some timing information. Here's a screenshot:

It looks like the peripheral is immediately sending the security request once the connection has started. The first couple SMP messages are exchanged without issue, but shortly after sending the "Pairing Response" the slave sends a Pairing Failed error. I'm not really sure how to debug this further as "Unspecified Reason" doesn't give me much to go on...

If I set uint8_t pairMode = GAPBOND_PAIRING_MODE_WAIT_FOR_REQ; one of two things happens, depending on the central configuration:

1. If the central is configured to initiate pairing, we can get the devices to pair and encrypt, but so far only when the central disables LE Secure Connections
2. If the central isn't configured to initiate pairing, obviously no pairing occurs

I've had some success in digging further into this issue, but we still aren't having success getting the device to bond with the actual central using LE Secure Connections.

I think the SMP_PAIRING_FAILED_UNSPECIFIED error I am getting may be linked to the stack running out of heap RAM. I slashed and burned all ancillary features on a debug branch of our peripheral build to free up as much RAM as possible (increase the heap size). Eventually I freed up enough RAM to get the peripheral to pair and bond using LE Secure connections. So far this  only works when the central device is a CC2642 (basically another instance of our peripheral hardware, but with special firmware to simulate our central).

I need to do more testing to figure out why the paring / bonding doesn't work with our actual peripheral. 

One question this has generated, is exactly how much heap RAM does LE Secure Connection Key generation require? I noticed this excerpt in the BLE stack users guide:

" If using Secure Connections, the PDU size must be >= 69. This can be set by defining the following preprocessor symbol in the application project: MAX_PDU_SIZE=69. Also, the minimum heap size that can be used with Secure Connections is 3690."

Is 3690 whats required just for pairing / bonding (in addition to whatever else is using heap memory)? Because in our non-instrumented master branch the heap is 4608 bytes, which exceeds the vague number from the documentation. This build results in the error documented in my original post. If I run the debug build, which has 5916 bytes of heap available the paring/bonding succeeds. I instrumented the bond manager callback to print the free heap available each time its called, but that always shows >> 1 kB free. If the key generation is eating up a bunch of heap, its doing it quickly and freeing it before the callbacks are made.