Understanding NRF_ERROR_BUSY - S132 V5 Update

[Tron]

Hi,

I just read Understanding NRF_ERROR_BUSY and wanted to know if this is true for the S132 V5 softdevice.

So each connection can queue one system Tx packet and one application Tx packet? What is the difference between a system Tx packet and an application Tx packet?

Short example: When I connect to two or more clients in very short time and I run one ble_db_discovery_start on each connection like this:

memset(&m_db_discovery_array[p_evt->conn_handle], 0x00, sizeof(m_db_discovery));
err_code = ble_db_discovery_start(&m_db_discovery_array[p_evt->conn_handle], p_evt->conn_handle);
APP_ERROR_CHECK(err_code);

Than the chance is there that two database discoveries are executed simultaneously. But because each connection has its own queue the two discoveries do not influence each other, right?

[Petter Myhre]

Right. That shouldn't be a problem.

[Petter Myhre]

In the link a system Tx packet was any transaction across GAP, GATTC, and GATTS. So if you were doing a GAP transaction you could get NRF_ERROR_BUSY when trying to do a GATTC procedure. An application Tx packet was notifications and write commands.

What you read is not true for S132 v5. It has more buffers for GAP, GATTS and GATTC, so a GAP transaction can now be run independent of what transactions are running in GATTS and GATTC, and so on. There is still a limitation (by spec) that you can only run one GATTC transaction at the time, you can't do a read request and a write request, but you can do a read request and a write command.

But if you are talking about transactions on different links, this isn't relevant, each link would have its own buffers.