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.

[brianreinhold]

I can take a sniffer trace (but I don't see what that will give since I know what I am receiving at least at the GATT level) but I do not know how to do a 'reset'. The last sd_* call I make when terminating a specialization is

sd_rpc_close(adapter)

Is that a reset?

I should state that I run several specializations (heart rate, thermometer, blood pressure, pulse ox, and glucose meter) in any order one after the other (but only one at a time). For each specialization the first sd_* calls I make are

• sd_rpc_physical_layer_create_uart
• sd_rpc_data_link_layer_create_bt_three_wire
• sd_rpc_transport_layer_create
• sd_rpc_adapter_create
• sd_rpc_log_handler_severity_filter_set
• sd_rpc_open
• ble_cfg_set
• ble_stack_init

I do not really understand what is happening in all these calls; I took them from the single example that exists and I start every specialization peripheral with that sequence. Seems to work so far.

On a shutdown/disconnect (by peer or by user - if by user I throw in a disconnect to the peer) I do

• sd_ble_gatts_sys_attr_get (to save data for reconnect)
• sd_rpc_close

and that's it. Everything else I do on shutdown is application clean up (freeing memory, thread cleanup, semaphore releases and stuff like that).

So when I get the busy error, what should I call? My user shutdown sequence?

I have just completed the glucose monitor which ONLY uses RACP and I get the same result.

[Hung Bui]

OK, I wasn't aware that you mentioned that you were using the ble_pc_driver. It's a bit harder to trigger a reset from PC. But you can also trigger a disconnection instead. At least we still can see the last activities. 

To rule out any issue related to the ble_pc_driver and the serialization firmware on the nRF52, if you can create an example running directly on the nRF52 (no serialization) and expose the same issue, then it would be easier to debug. 

[brianreinhold]

Sorry,

at this stage the latter would be both costly and time consuming as I have no compilers that are capable of compiling nRF52840 HEX files. It would also take a good deal of time just getting that environment up and running. 

Though it would be nice to find out what is causing the issue and clean it up, at the moment it is pretty low priority because over the airwaves the transactions are correct.

I will say that it appears to be unique to the RACP response. I had the same error on a pulse ox spot indication and THAT was due to competing threading issues which I fixed and it went away. For the RACP in the glucose meter (where there is only one transmission 'thread' or the RACP in the Pulse ox where I have only stored data) there is no threading issues but the error message still comes and nothing I do gets rid of it but over the airwaves it is always correct.

[Hung Bui]

I understood. If you can capture a sniffer trace (even without disconnect or reset) please send it to us. For now if the NRF_BUSY_ERROR doesn't happens too often. You can just ignore and retry.

[brianreinhold]

It happens EVERY time when I do an RACP indicate; in both the pulse ox and glucose meter. I ignore it. And I do NOT retry, as every retry gives the same result and every retry sends the same indication to the peer.As I have said, the indication is ALWAYS successful over the airwaves. Its the error message that is bad.