Understanding NRF_ERROR_BUSY

[giglesias]

I am using the s120 soft device v2.2.1 as a center communicating with a peer using a s110 soft device. The peer is a black box an all I have is the documented protocol. The protocol is simple.

1. Write a command to enable indications on the peer and wait for a Write response from the peer as the indication the command was received. Send the next enable indications Command.
2. Write a command to a given characteristic on the peer and wait for a Write response followed by an HVX indication as the response to the command that I sent. Send the next Command.

I am basing my implementation on the S120 Heart Rate monitor project and all seem to be working well. From time to time I am receiving a NRF_ERROR_BUSY from sd_ble_gattc_write even though I am waiting for a write request and an HVX indication before sending the next command.

Even though I attempt to resend the command the NRF_ERROR_BUSY status is still reported and the peer disconnects because I am no longer communicating with it. Based on the documentation the soft device is busy processing a message. Is there some way to debug this NRF_ERROR_BUSY status or receive an indication that the soft device is no longer BUSY?

[FormerMember]

Hello,

The following, found in the S120 release notes, is the reason for the NRF_ERROR_BUSY error:

All BLE layers (GAP, GATTC and GATTS) are restricted to queuing no more than one system Tx packet and one applicatio n Tx packet per connection when operating in the central role. Because of this limitation, any API calls that require a system packet to be sent out may return NRF_ERROR_BUSY to the application. Since the SoftDevice does not inform the application when the system packet is again available, the application must simply retry (potentially with a timer) until the call succeeds.

The workaround would be to add a delay before calling sd_ble_gattc_write(..). The length of the delay should be at least one connection interval. One connection interval is the smallest amount of time it will take before the buffer is freed.

Regards, Kristin

[Unknown]

The workaround would be to call sd_ble_gattc_write(..) after delaying the call. At least one connection period should pass during the wait. The shortest period required before the buffer is released is one connection interval.

drift boss

[financecajole]

Hi Kristin, penalty kick online

I was able to troubleshoot the NRF_ERROR_BUSY state. Thank you very much for your comments.