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? 

[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.