Getting error NRF_ERROR_RESOURCES when using more then one notification and the Connection crashes

[danny habot]

Hi, 

I am using the MCU on a board with sensors that are sampled in a very high rate (~100Hz). 

I am having issues when trying to send the data with notification on more then one characteristic. 

The information is sent correctly for a short time (~30 seconds) and then the connection get stuck and unresponsive. 

When the connection "crashes" i start getting NRF_ERROR_RESOURCES  from sd_ble_gatts_hvx(*pointer_conn_handle, &hvx_params);

Initially i thought it is because the queue was very small (the default value of 1) however even after changing it to 10 it still does it.

I use the following code to change it: 

ble_cfg_t ble_cfg;
memset(&ble_cfg, 0, sizeof ble_cfg);
ble_cfg.conn_cfg.conn_cfg_tag = APP_BLE_CONN_CFG_TAG;
ble_cfg.conn_cfg.params.gatts_conn_cfg.hvn_tx_queue_size = 10;
err_code = sd_ble_cfg_set(BLE_CONN_CFG_GATTS, &ble_cfg, ram_start);

I have 2 questions:

1. how can i config the system to allow much more bandwidth as i will need several notification simultaneously?

2. how can i avoid crashes in case of overload? i saw this post but couldn't understand how to use it on my project as the data structs are different.

I am using NRF52832 (custom board) with freeRTOS (based on the HRS freeRTOS example) SDK15, and SD 6.0

BR, 

Danny

[danny habot]

Hi, 

1. no, it is not always 30 seconds... it changes from run to run. i couldn't find a pattern...

2. my connection parameters are connection interval of 7.5ms, slave latency of 2 and Connection supervisory timeout of 4 seconds.

3. That is the weird thing. the connection is just unresponsive. it does not get disconnected, and the device has not crashed as it still response to inputs correctly. i do not get any error from the central side. the only errors i get is if i try to do any new action and it get timeout. when it happen i get the NRF_ERROR_RESOURCES on the relevant characteristics.

4. i should have deleted it. when rslt !=0 i print the return value.

[Sigurd]

danny habot said:

the only errors i get is if i try to do any new action and it get timeout

What do mean by action? Is it the connection that timeout, or do mean that you get the return code NRF_ERROR_TIMEOUT from a function?

Are you getting the event BLE_GATTS_EVT_HVN_TX_COMPLETE ?

If you could capture a sniffer trace, it would help us to see what is happening on-air.

You could also test the S132 v6.1.0, and see if you see any improvements with that version.

[Sigurd]

Hi again,

I talked with my colleague Bjørn, and we are waiting for the sniffer trace. We believe the root cause of this issue is caused by FreeRTOS. We will try to reproduce and verify this.

[danny habot]

Hi Sigurd, 

I sent to Bjørn the sniffer trace, please let me know if you need anything else from me. 

[bjorn-spockeli]

HI Danny, I am still looking into this and have yet to find the root cause yet. 

From the sniffer trace I see that the device is still sending empty packets, i.e. maintaining the link, hence we can rule out a SoftDevice issue as this confirms that the SoftDevice is still running properly. WHat I suspect is that there is something in our FreeRTOS port that results in the application locking up, resulting in sd_ble_gatts_hvx not being called. 

I have been using the ble_app_hrs_freertos example for testing, using a connection interval between 7.5ms and 12.5ms, and sending notifications with a 5ms interval. I have been using a hvn_tx_queue_size of 6 and a connection event length of 7.5ms(6*1.25 ms). 

I have seen significant improvement if the logger task is not running, i.e.  disable logging by setting NRF_LOG_ENABLED to 0 in the sdk_config.h file.  I still see the issue occurring after 10+ minutes, but it is far better than after <60s with logging enabled. 

Do you have logging enabled when you see this issue? If so could you try to disable the logging module,  perform another sniffer trace capture and see if this results in the issue occurring later than with logging enabled?

Also, I see that you have set hvn_tx_queue_size to 10, do you still call  sd_ble_gatts_hvx in a loop or do you keep track of how many notifications that have been queued and then only call sd_ble_gatts_hvx if you have gotten a BLE_GATTS_EVT_HVN_TX_COMPLETE  event indicating that you can queue a new notification?