CC2640R2F: Heap size required for LE Secure Connections pairing

John Whitehouse

Part Number: CC2640R2F
Other Parts Discussed in Thread: BLE-STACK

Hello,

Related to earlier posts on a similar theme, I'm running a BLE application using LE Secure Connections and I'm seeing the SMP_PAIRING_FAILED_UNSPECIFIED error being reported. I am using SimpleLink SDK version 3.20.00.21.

The error isn't consistent across all BLE central devices I'm testing with. Most central devices work, but one fails consistently with the same error.

I've read comments in other posts regarding increasing the heap memory available for BLE-Stack to use. I've tried this and it fixes the problem, but only if I increase the heap size by over 1.5KB by stripping out most of my application's functionality.

It would be really useful to understand what would trigger the extra heap allocation between different central devices. Can you offer any guidance?

For reference, some of my heap-related settings are:

MAX_NUM_BLE_CONNS: 1

MAX_NUM_PDU: 5

MAX_PDU_SIZE: 119

Thanks for your assistance.

John

over 6 years ago

0 IUsedToBeARealPerson (M-W) over 6 years ago

TI__Guru 58425 points

Hi,

I have assigned an expert to comment on this.

0 Marie H over 6 years ago

TI__Guru* 83691 points

Hi John,

I don't think we have any numbers for how much heap is needed for different pairing methods. If 1.5 kB is your number then I guess that's your number. You can do the same check for simple peripheral (check the heap just after a connection is formed, and again after the devices are bonded).

If you are running out of SRAM it could be useful to go through the RAM Optimizations section of the BLE-Stack User's Guide:

You can also consider using GPRAM or AUXRAM:

If you post a sniffer log of this happening I can try to understand why you're getting this error message.

0 John Whitehouse over 6 years ago in reply to Marie H

Intellectual 620 points

Hi Marie,

Thanks very much for your assistance.

We limit the pairing method supported to 'Just Works' with LE Secure Connections, so this behaviour should be consistent for all centrals.

In looking at the heap metrics, I'm not seeing any allocation failures being reported. Is there any other reason why there could be a failure?

Thanks,

John

0 Marie H over 6 years ago in reply to John Whitehouse

TI__Guru* 83691 points

Hi John,

If you can post a BLE sniffer log I can check and see if I see anything wrong.

0 John Whitehouse over 6 years ago in reply to Marie H

Intellectual 620 points

Hi Marie,

I can provide a log: would it be possible to follow-up by email rather than via the forum?

Thanks,

John

0 John Whitehouse over 6 years ago in reply to Marie H

Intellectual 620 points

Hi Marie,

I think I've managed to work around out the problem by disabling Data Packet Length Extensions at runtime.

Using DLE seems to be OK if there's a long enough time gap (> 1000ms) between the start of the connection and pairing request being issued and/or an ATT MTU exchange does not take place.

Thanks,

John

Bluetooth®︎

Bluetooth forum

CC2640R2F: Heap size required for LE Secure Connections pairing