BLE_EVT_USER_MEM_REQUEST patterns

[charles]

nRF52832_XXAA, nRF SDK 14.0.0, SoftDevice 132 v5.0.1

We run a single service with 2 characteristics: one for "target to host" and the other for "host to target", where the "target" is our embedded device running the nRF52 + SD and the "host" is either a computer with a BLE USB dongle or a mobile app on a BLE-enabled handset. The target has a 65-byte MTU for power optimization purposes.

Our connection interval is 1 second, but while connected we have enough time to receive ~3 65-byte MTU frames.

We've just encountered a use case, for the first time, where the host is sending > 65 bytes inside of one connection interval: we never added a BLE_EVT_USER_MEM_REQUEST handler so SoftDevice is disconnecting us.

It's easy enough for us to service this request with a reserved 256-byte static buffer, but before we do that I'd like a clear normative statement from Nordic support that answers the following questions, please.

Given our specific use case:

1. What other scenarios that we haven't yet encountered would trigger BLE_EVT_USER_MEM_REQUEST?
2. Will SD issue multiple BLE_EVT_USER_MEM_REQUEST events before any memory is released? (Do we need a more general allocator, or will a single static buffer work?)

Thanks,

Charles

[bjorn-spockeli]

HI Charles, 

What other scenarios that we haven't yet encountered would trigger BLE_EVT_USER_MEM_REQUEST?

 The BLE_EVT_USER_MEM_REQUEST event will only be generated when a GATTS Queued write is performed on a characteristic, see the relevant Message Sequence Charts below

GATTS Queued Writes: Peer cancels operation

GATTS Queued Writes: App handled, one or more attributes require authorization

GATTS Queued Writes: App handled, no attributes require authorization

GATTS Queued Writes: Stack handled, one or more attributes require authorization

GATTS Queued Writes: Stack handled, no attributes require authorization

GATTS Queued Writes: Prepare Queue Full

Also see the API documentation for sd_ble_user_mem_reply. It is possible to write the 3 65-byte frames to the characteristic using write commands instead of prepare write requests, that way you do not have to allocate any memory, but you will have to keep track of the number or write commands to know when all the 3 frames have been received. 

Will SD issue multiple BLE_EVT_USER_MEM_REQUEST events before any memory is released? (Do we need a more general allocator, or will a single static buffer work?)

The SD will issue the BLE_EVT_USER_MEM_REQUEST event when a Queued Write is initiated by a connected Central. So if there is only one host connected to the nRF device at the time then BLE_EVT_USER_MEM_REQUEST will be generated only once and then the memory will be released when the Queued write has finished. 

Best regards

Bjørn