sd_ble_gatts_hvx NRF_ERROR_RESOURCES in do while loop

[nrbrook]

After a few notifications in short succession this code will reliably get stuck in an infinite loop (15.2.0). Can sd_ble_gatts_hvx not be used in this way? Do you have to wait for BLE_GATTS_EVT_HVN_TX_COMPLETE? This makes things more difficult as you then have to queue the notifications in the application.

do {
    err_code = sd_ble_gatts_hvx(conn_handle, &params);
} while (err_code == NRF_ERROR_RESOURCES);

[bjorn-spockeli]

Hi Nick, 

sd_ble_gatts_hvx() is a synchronous API call so it should return NRF_ERROR_RESOURCES as long as the notification queue is full and should not halt if called in a loop. 

Yes, the recommended and most power-efficient approach is to call sd_ble_gatts_hvx untill you get the NRF_ERROR_RESOURCES return code and then wait until you get the BLE_GATTS_EVT_HVN_TX_COMPLETE before you call sd_ble_gatts_hvx again. 

Note: The number of Handle Value Notifications that can be queued is configured by ble_gatts_conn_cfg_t::hvn_tx_queue_size.

Best regards

Bjørn 

[nrbrook]

Thanks for your response but the code does not halt on sd_ble_gatts_hvx, just the loop continues indefinitely i.e. sd_ble_gatts_hvx continues to return NRF_ERROR_RESOURCES forever. So perhaps the function does not work correctly, as I assume it shouldn't return NRF_ERROR_RESOURCES forever as the queue will become free at some point.

[nrbrook]

I get zero HVN_TX_COMPLETE unless I omit the loop and just ignore the return error. Perhaps the interrupt handling queue is full and interrupts from the radio can't be handled or something? I'm not sure of the detail of how things work in that respect, just guessing.

[bjorn-spockeli]

Are you running the loop at an interrupt context?  It could sound like thee loop is blocking the SD events from being handled in the application. I think this could happen if the loop is running in an interrupt context with priority 6.

Best regards

Bjørn

[nrbrook]

Yes, in a GPIO Interrupt with priority 6. What is the proper way to escape the interrupt context and handle the interrupt without blocking other events?

[bjorn-spockeli]

Could you try to set the GPIO interrupt priority to 7 and see if that helps. I think the SD events are handled in the application at interrupt priority 6, so setting the GPIO interrupt to 7 should resolve the blocking issue. (if that is the cause of the issue that is).

Bjørn

[nrbrook]

Yes that seems to prevent the blocking, thanks.