This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

How to deal with [NRF_ERROR_RESOURCES]

Hello
If "NRF_ERROR_RESOURCES" occurs, does the set transmission data not be transmitted? Will it be sent partway? I do not know either.
If "NRF_ERROR_RESOURCES" is returned when executing [ble_nus_data_send ()], can I freeze the time and execute [ble_nus_data_send ()] again?
Thanking you in advance
 
  • I'm reading out the variable 

     p_ble_evt->evt.gatts_evt.params.hvn_tx_complete.count;
    in BLE_GATTS_EVT_HVN_TX_COMPLETE event, doesn't that variable shows you how many packets are sent in an overall connection event? If not then how do I keep count of the numbers of packets that are sent.

    I couldn't implement DLE because the central devices use BLE v4.1.  I'm able to increase the MAX_ATT_MTU to 247, but it's of no use because as soon I increase the data size to above 20 it gives me "NRF_ERROR_RESOURCES" error.

    I recently tested with one plus 6 mobile which supports BLE v5 and even that shows me one packet. 

    What do you think I'm doing wrong here

  • Hi,

    doesn't that variable shows you how many packets are sent in an overall connection event?

    No, you could get that event several times during the connection event. E.g. if you send 4 packets in a connection event, you could get the tx-complete event first with count=1 and then again with count=3.

    If not then how do I keep count of the numbers of packets that are sent.

    The easiest way is just to check nRFSniffer to see what is happening on-air.

  • Hi Sigurd,

    I'm programming an app based on the blinky example from SDK 15.1.0 on the nRF52 development kit. I've managed to modify the example to send and receive multiple bytes per packet, but when I try to send more packets, I get the NRF_ERROR_RESOURCES error. For me, the BLE_GATTS_EVT_HVN_TX_COMPLETE event never seems to occur, although packets are sent to the central. I have a case for it in ble_event_handler:

    case BLE_GATTS_EVT_HVN_TX_COMPLETE:
        NRF_LOG_DEBUG("BLE_GATTS_EVT_HVN_TX_COMPLETE");
        break;

    That line never gets printed. Am I doing something wrong here?

    Also, when I send the packets, I always wait for NRF_SUCCESS before sending the next one, but I still get the error after a few packets. I don't know, what am I missing?

    Thank you in advance!

  • That line never gets printed. Am I doing something wrong here?

    Could you try NRF_LOG_INFO instead of NRF_LOG_DEBUG ?

  • Thanks a lot for your answer, it does work with NRF_LOG_INFO. Sending over 30 notifications in a row also works, if I wait for the BLE_GATTS_EVT_HVN_TX_COMPLETE event. Shouldn't NRF_SUCCESS be enough to look for?

    uint32_t ble_dev_send_data(uint16_t conn_handle, ble_dev_t * p_dev, uint8_t *data, uint16_t len)
    {
    	ret_code_t err_code;
    
    	ble_gatts_hvx_params_t params;
    
    	memset(&params, 0, sizeof(params));
    	params.type   = BLE_GATT_HVX_NOTIFICATION;
    	params.handle = p_dev->read_char_handles.value_handle;
    	params.p_len = &len;
    	params.p_data = data;
    					
    	err_code = sd_ble_gatts_hvx(conn_handle, &params);	
    	
        return err_code;
    }

    If I keep trying to send in a while loop until the above method returns NRF_SUCCESS, it fails with NRF_ERROR_RESOURCES after the 5th or 6th packet anyways.

    case BLE_GATTS_EVT_HVN_TX_COMPLETE:
    	NRF_LOG_INFO("BLE_GATTS_EVT_HVN_TX_COMPLETE");
        ble_tx_complete = 1;
    	break;

    If I set a flag when BLE_GATTS_EVT_HVN_TX_COMPLETE occurs (like in the above snippet) and wait, it works:

    for (uint8_t i = 0; i < noOfPkts; i++)
    {	
        /* other code */
        
    	while(ble_tx_complete == 0);
    	ble_dev_send(m_conn_handle, &m_dev, (uint8_t*)&report, (uint16_t)sizeof(report));
    	ble_tx_complete = 0;												
    }

    Isn't there a better way of doing this? Do you always have to wait for this event before sending more packets?

    By the way, increasing NRF_SDH_BLE_GAP_EVENT_LENGTH in sdk_config.h had no effect.

Related