Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Does sd_ble_gatts_hvx use a dedicated memory pool?

Hello,

Our Peripheral server application regularly uses a stream of notifications to transmit data to a Central client. We have a rare error in which sd_ble_gatts_hvx returns NRF_ERROR_RESOURCES. The interesting part is that this appears be correlated to some corruption within a series of writes to the Peripheral, detected at the application level via a CRC across several writes.

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.

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?

I am using s132 v5.1.0 and SDK v14.2.

Parents
  • Hi,

    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.

    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.

    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?

    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.

  • 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?

Reply
  • 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?

Children
  • 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).

Related