The node resets on connection negotiation timer timeout

[hardikp]

We are using the following.

Module: BM833 (nRF52833) from Fanstel

Softdevice: S140 7.0.0

SDK: nRF5SDK17009d13099

Sample code: nRF5_SDK_17009\examples\ble_peripheral\ble_app_uart

The parameters we use are as below.

#define APP_ADV_INTERVAL 64

#define APP_ADV_DURATION 18000 

#define MIN_CONN_INTERVAL MSEC_TO_UNITS(20, UNIT_1_25_MS) 
#define MAX_CONN_INTERVAL MSEC_TO_UNITS(60, UNIT_1_25_MS) 
#define SLAVE_LATENCY 0
#define CONN_SUP_TIMEOUT MSEC_TO_UNITS(4000, UNIT_10_MS) 
#define FIRST_CONN_PARAMS_UPDATE_DELAY APP_TIMER_TICKS(5000) 
#define NEXT_CONN_PARAMS_UPDATE_DELAY APP_TIMER_TICKS(30000) 
#define MAX_CONN_PARAMS_UPDATE_COUNT 3

In our application, the peripheral node connects to the central device, transmit the data, and issues the disconnect event. It finished all this within 5 to 6 seconds.

We observed that sometimes rtc_irq()->on_compare_evt()->timer_expire() is executed after the disconnection request is issued and the it throws the invalid state error (0x08) and causes the software reset.

How can we fix it?

Why the timer is not stopped from the library if connection parameters are successfully established? The timer is configured in one-shot mode and it is assumed that it will expire before the disconnection request is issued. Where can we stop that timer? 

Is it ok to increase the FIRST_CONN_PARAMS_UPDATE_DELAY  from 5 seconds to 8 seconds?

[Karl Ylvisaker]

Hello,

As @Awneil says, it would be helpful if you could narrow down the problem, perhaps with the logs of your application or central side.

it throws the invalid state error (0x08) and causes the software reset.

Which function is returning the error?
If you define DEBUG in your preprocessor defines, as shown in the included image, then you may see the exact error generated, if an error is passed to APP_ERROR_CHECK.

Is it ok to increase the FIRST_CONN_PARAMS_UPDATE_DELAY  from 5 seconds to 8 seconds?

Yes. The FIRST_CONN_PARAMS_UPDATE_DELAY  determines how long the peripheral will wait before initiating an update of the connection parameters, if the connection parameters of the central is outside of the specified peripheral's parameters. You are currently using MIN_ 20, MAX_ 60, do you know what interval your central supports?

Best regards,
Karl

[hardikp]

Karl Ylvisaker said:

Which function is returning the error?

The reset issue occurrence frequency very low. We hardly get it 2 3 times per day. We will put the system in debug mode and will share the result.

Karl Ylvisaker said:

do you know what interval your central supports?

We are using the nRF52840 module on the central side and similar ble_app_uart_c example code. So it should support the minimum and maximum connection intervals as mentioned above. 

[Karl Ylvisaker]

hardikp said:

The reset issue occurrence frequency very low. We hardly get it 2 3 times per day. We will put the system in debug mode and will share the result.

It will be much easier to investigate the cause when we see the logs for the occurrence with debug enabled. Great!
It seems strange that you only see this 2-3 times a day, if it indeed is a disconnect due to connection parameter negotiation mismatch.

hardikp said:

We are using the nRF52840 module on the central side and similar ble_app_uart_c example code. So it should support the minimum and maximum connection intervals as mentioned above. 

Could you verify for me whether you are using an unmodified ble_app_uart_c example on your central side?
Could you also share with me the exact MIN_ and MAX_ connection interval specified for your central?
The default supported connection interval for the ble_app_uart_c is 7.5 - 30 ms ( which has some overlap with your peripheral device ).
Is your central connected to multiple peripheral devices at the same time?

Best regards,
Karl