ERROR 18 [NRF_ERROR_CONN_COUNT] crash after forcing disconnect

Question

Hi,

I try to implement a disconnection after wrote a characteristic parameter. This byte change the working mode of my systeme.

So user connect, write the field to change mode. Then in on_write function , i close some timer and close twi module and force disconnection with ble_conn_state_for_each_connected(disconnect, NULL); .

Before force disconnect, i started a timer that will allow to wake up systeme each 20sec , advertise, and allow phone to get data before to enter sleep again, and this infinitely .

But after the first wake up and first advertising this error happens:

<info> app: ADVERTISING...
<error> app: ERROR 18 [NRF_ERROR_CONN_COUNT] at C:\nordic\nRF5SDK160098a08e2\examples\ble_peripheral\Firmware\main.c:918
PC at: 0x00031B91
<error> app: End of error report

Its is triggered by uint32_t err_code = ble_advertising_start(&m_advertising, BLE_ADV_MODE_FAST);
APP_ERROR_CHECK(err_code);

It seems to be related to the number of connexion. But i'm already disconnected with the own client connected , my phone. Moreover, i remember to have set three max connexion client at a time ( even if i was only able to have only one at a time but i will investigate this further)

DO you have an idea how to manage properly disconnexion? i thought to do it well by using ble_conn_state_for_each_connected(disconnect ...

Thank you !!!

Edvin · Accepted Answer

Olfox said: As i'm only peripheral, what is difference between both please ? i guess total link is for uC doing the job of central + peripheral et the same time ? 
 That is correct. You can set NRF_SDH_BLE_TOTAL_LINK_COUNT = NRF_SDH_BLE_PERIPHERAL_LINK_COUNT + NRF_SDH_BLE_CENTRAL_LINK_COUNT if you like, but I guess the reason it is not is that you can support e.g. 8 connections that can be either peripheral or central, but not 8 of each at the same time.

Olfox said: So i imagine that i have to check everywhere if number of connexion live is superior to one before to switch off sensors ? 
 I guess you can look at the SDK\examples\ble_peripheral\experimental\ble_app_multiperipheral example for inspiration. Look at how the 
 ble_evt_handler() -> case BLE_GAP_EVT_CONNECTED -> on_connected() 
 checks the periph_link_cnt and uses this parameter to decide whether to restart advertising. Similarly, you can use it to check whether you should start or stop the sensors. 
 If your on_connected() is called with periph_link_cnt = 1, it means that it was 0 before that, and you should start the sensors. If on_disconnected() is called with periph_link_cnt = 0 it means that the last connection disconnected, and you can stop the sensors. 
 
 CONN_SUP_TIMEOUT is the time that it takes for the connection to disconnect if the other device stops responding (runs out of battery, is turned off, moves out of range) without sending a disconnect packet. 
 If you try to connect to the peripheral with a central (either another nRF or a phone), and they agree on 4 seconds CONN_SUP_TIMEOUT, and then you just power off the nRF, you will see that it takes 4 seconds for the phone to say that it is disconnected. During these 4 seconds, the central will continue to look for BLE packets from the peripheral, and resume normal operation if a packet is received. The reason for this is that the link should be robust against packet loss due to noise (various sources such as obstacles, walls, long distance, other radio transmitting sources such as WiFi, etc.). 
 
 Hopefully, this clears up your questions. Let me know if anything was unclear. 
 
 BR, 
 Edvin

ERROR 18 [NRF_ERROR_CONN_COUNT] crash after forcing disconnect

Top Replies