Does sd_ble_gatts_hvx use a dedicated memory pool?

RE: Does sd_ble_gatts_hvx use a dedicated memory pool?

Einar Thorsrud — Mon, 06 Sep 2021 13:19:09 GMT

I checked this with the SoftDevice team, and my earlier statement was not entirely correct. There is a dedicated HVN queue, and that is 1 by default. There are also more shared LL buffers, so you can typically schedule more packets, depending on configuration. These can be used for any type of packet. To reserve buffers for more than 1 notification you need to configure it with BLE_CONN_CFG_GATTS (ble_gatts_conn_cfg_t::hvn_tx_queue_size).

RE: Does sd_ble_gatts_hvx use a dedicated memory pool?

Elias — Fri, 03 Sep 2021 16:04:22 GMT

Yes, I am familiar with everything in the first half of your answer, as I have been working with the Nordic SoftDevice for years. Our application is built to wait for BLE_GATTS_EVT_HVN_TX_COMPLETE before ERROR_RESOURCES should occur, and when ERROR_RESOURCES does happen, it is handled gracefully. This issue is only interesting because ERROR_RESOURCES really is rare in our system after years of development and months of integration testing; and it's also correlated with a different error.

> It is the same Tx queue for data like this.
"Data like this" meaning enqueued notifications?

> control packets, reads of characteristics etc are not part of the same queue
This is close to the information I was looking for. Is this a definite statement that there is nothing else that take up memory that would otherwise be allocated for the Tx queue by the SoftDevice?

RE: Does sd_ble_gatts_hvx use a dedicated memory pool?

Einar Thorsrud — Fri, 03 Sep 2021 13:28:02 GMT

Hi,

[quote user=""]ble_gatts.h says that NRF_ERROR_RESOURCES means "Too many notifications queued." However, we believe we have allocated enough memory for the SoftDevice so that we should never enqueue too many notifications.[/quote]

It is not possible to queue an infinite number of notifications, they need to be buffered in the SoftDevice memory. The amount of memory set aside by the SoftDevice for this depends on the configuration, for instance event length. (Therefor you can see that you must adjust the application RAM start address if you change these configurations).

If you queue notifications more quickly than they are sent, then you will get NRF_ERROR_RESOURCES. This will typically happen from time to time in most real applications, for instance if there are a lot of consecutive retransmissions etc. So this is a situation you need to handle in any application. In this case you typically wait for a BLE_GATTS_EVT_HVN_TX_COMPLETE event before you try to queue the notification again.

[quote user=""]Does the SoftDevice have a portion of its memory pool dedicated to buffering notifications, or does it share the this memory with other events? If the memory pool is shared and fills with "too many" events, what are the symptoms?[/quote]

It is the same Tx queue for data like this (control packets, reads of characteristics etc are not part of the same queue). The symptom is that you get NRF_ERROR_RESOURCES when you attempt to queue a new notification or indication.