Handle a 'BUSY' error message

[brianreinhold]

I have looked at some other NRF_ERROR_BUSY questions and the answers seem to be very dependent upon the situation and not necessarily 'busy' in the usual context of busy. In any case I am writing a pulse oximeter peripheral and I get an NFR_ERROR_BUSY sometimes when I try and indicate the resonse to an RACP transaction. The RACP transaction is transferring stored measurements (in this case just one) and the measurement actually gets transferred. But then I need to indicate the conclusion of the transaction to the central client. But I can sometimes get this NFR_ERROR_BUSY response. I am not sure why ( continuous measurements and some spot measurements are also being indicted and notified). Should I just try again? What are the chances this error will repeat ... and maybe forever?

Interesting: The client gets the response anyways in spite of the NRF_BUSY_ERROR. Which means the client gets more than one if I wait and retry. What am I to make of that? 

[Hung Bui]

Hi Brian, 

Please describe your application, the activity happens. Please tell us where did you get the NRF_ERROR_BUSY, in which function, which side  .

[brianreinhold]

On the client side I use an Android application. It works fine with the Nonin pulse ox that follows the Pulse ox 0x1822 service with RACP. So the issue is not on the Android side.

I have simplified the app a little in that the ONLY thing it does is the RACP transaction (no live data to be indicated/notified). When the Android does an RACP transfer for all records, the pulse ox handles it fine and the stored spot measurements are sent to the Android.

Now this is a threaded application running on the PC using the ble_pc_driver.

Just to make sure that no one was doing anything, I placed mutexes on the indications. So I lock the mutex before indicating and unlock when I get the BLE_GATTS_EVT_HVC event making sure that there is no simultaneous transactions taking place. When all the measurements are indicated, I send the RACP indication telling the client that the transfer is done and it is successful. The Android receives it. But I get the NRF_ERROR_BUSY error every time. At this point I just ignore it (so I do not retry) as the client always receives it.

The code that sends the data is below. Note the pthread_mutex_lock() calls. This call blocks until an unlock is called. That gets called when the indication event is received.

        if (racp[1] == RACP_OPERATOR_ALL_RECORDS) // all records
        {
            printf("Sending stored Pulse Ox data via RACP at time %llu\n", (GetTickCount64() - elapsedTimeStart));
            for (i = 0; i < poParams->numberOfMsmts; i++)
            {
                if (poParams->poMsmtChars[i]->storedSpotChar != NULL)
                {
                    pthread_mutex_lock(&spotMutex);
                    printf("---Mutex stored start\n");
                    mderFloatToStringSimp(&poParams->poMsmtChars[i]->storedSpotChar->spo2, buf, 16);
                    printf("Send Stored SpO2 %s and ", buf);
                    mderFloatToStringSimp(&poParams->poMsmtChars[i]->storedSpotChar->pulseRate, buf, 16);
                    printf(" Pulse Rate %s\n", buf);
                    po_spot_measurement_indicate(poParams->poMsmtChars[i]->storedSpotChar);
                    j++;
                }
                if (po_abort)
                {
                    return;
                }
            }
            pthread_mutex_lock(&spotMutex);
            printf("---Mutex racp start\n");
            racp[0] = RACP_OPCODE_RESPONSE;     // response
            racp[1] = RACP_NULL;
            racp[2] = RACP_OPCODE_REPORT_STORED_RECORDS;
            racp[3] = (j > 0) ? RACP_OPERAND_SUCCESS : RACP_OPERAND_NO_RECORDS_FOUND;
            po_racp_indicate(racp, 4);
            return;

The RACP code is as follows:

static uint32_t po_racp_indicate(unsigned char* racp, unsigned short length)
{
    uint32_t               error_code = NRF_SUCCESS;
    uint16_t               hvx_length;
    ble_gatts_hvx_params_t hvx_params;

    hvx_length = length;

    hvx_params.handle = m_po_racp_handle.value_handle;
    hvx_params.type = BLE_GATT_HVX_INDICATION;
    hvx_params.offset = 0;
    hvx_params.p_len = &hvx_length;
    hvx_params.p_data = racp;
    int count = 0;
    while (count < 3)
    {
        error_code = sd_ble_gatts_hvx(m_adapter, m_connection_handle, &hvx_params);

        if (error_code != NRF_SUCCESS)
        {
            if (error_code == NRF_ERROR_BUSY)
            {
                printf("Failed to send racp response. Busy. Don't believe it. Time %llu\n", (GetTickCount64() - elapsedTimeStart));
                error_code = NRF_SUCCESS;
                break;
              //  mySleep(500);
              //  count++;
              //  continue;
            }
            printf("Failed to send racp response. Error code: 0x%02X. Time %llu\n", error_code, (GetTickCount64() - elapsedTimeStart));
            fflush(stdout);
            break;
        }
    }
    return error_code;
}

Note that I commented out the retry on the NRF_ERROR_BUSY error.

[Hung Bui]

Please correct me if I'm wrong. You receive NRF_ERROR_BUSY when calling sd_ble_gatts_hvx() is it correct ? 

If you are doing indication, the function will throw NRF_ERROR_BUSY if the last indication has not received a response. 

Do you have any other service that might also send indication ? 

What is the connection interval do you have ? It may take 1-2 connection interval until you receive the response.

Could you take a sniffer trace ? 

[brianreinhold]

I do wait to get a response. That's what the mutex operation is for. I cannot indicate the RACP response until I have received the response to the last indication from the measurements.

Recall how it works.

1. The client writes to the RACP to transfer all measurements

2. The peripheral then indicates all the stored measurements, one at a time. Measurement X does not get indicated until a response from the previous indication has been received

3. When all measurements have been indicated and the last indication response has been received, the peripheral indicates the RACP response. The RACP response is correctly received by the Android client and an indication response is correctly evented by the dongle. However, I still get the error message.

It is annoying but at this stage I simply ignore it.

[Hung Bui]

Hi Brian, 
A sniffer trace would be useful in this case. There could be other activity happened at the same time causing the buffer to be filled. There is only one buffer for Indication and for Write Request.

If you can trigger a reset (or shutdown) right at the time you receive a NRF_ERROR_BUSY . We can find the root cause by looking at the sniffer trace at that moment when the peripheral stop responding.