NUS data notifications results in a fatal error

[Herb Gingold]

Hello, we are semi-experienced with Nordic,

We are doing a DC power driver, during operation we do a NUS data send if we are connected and the NUS has started. When we get to extreme radio range the NUS data send causes a fatal error, and the only way to restore the system is with a power reset, not an option for production.

We are porting over a project to Nordic and cannot find a way to duplicate a command from the old data set.  In that code space you had a function call that was used to detect if the BLE stack was really connected or if it was unstable.  It was a BLE stack status check and if it did not report a good connection, we would not try to send, and never had this issue.

Is there any function or call that can truly validate that the stack can take a NUS data send, so it does not fatally crash.  I have considered RSSI but that is unreliable as there can be other reasons for the RSSI to change.  I saw a connection count call mentioned in a post, but need to better understand that count and what the data means, to determine if it will solve this issue.

We are using an 805 module

We are on SDK nRF5_SDK_17.0.2_d674dde 

Soft device s112

This is preventing us from production release so please take this seriously,

Herb

[Vidar Berg]

Hello Herb,

ble_nus_data_send() will return with an error code if the notification did not get added to the output queue, and it's only if you pass this returned error code to APP_ERROR_CHECK() that you should get the "fatal error" message (any non-zero value will invoke the fault handler as described here: Error module).

uint32_t err_code = ble_nus_data_send(&m_nus, data_array, &length, m_conn_handle);
if (err_code != NRF_SUCCESS)
{
    NRF_LOG_INFO("ble_nus_data_send() returned error: 0x%x", err_code);
    APP_ERROR_CHECK(err_code); // <-- comment this line to ignore errors
}

Do you know what the error code is? sd_ble_gatts_hvx() will return NRF_ERROR_INVALID_STATE (0x8) if the connection has been terminated. But it's also not uncommon to see the NRF_ERROR_RESOURCES error, which is returned when the notification buffer is full. This can happen more frequently if you have a poor connection with a lot of re-transmissions.

Is there any function or call that can truly validate that the stack can take a NUS data send, so it does not fatally crash. 

The easiest way is to check if you are in a connection is to check the global 'm_conn_handle' flag. It's set to BLE_CONN_HANDLE_INVALID' on disconnect in the original example code. You could also use the APIs from the Connection state module. e.g. ble_conn_state_status(m_conn_handle);

Best regards,

Vidar