Error8 (0x8) : GATT CONN TIMEOUT

[GK]

Dear Sir,

I have implemented a program and tested it using BMD-300 Rigado DK.

The program will advertise continuously and I used nRFConnect to connect to the peripheral. And once the App is connected to the peripheral it will stay connected until we disconnect /restart the peripheral. This is the behaviour I expected and it is working perfectly fine with DK.

Now I have done a customboard with BMD-300 module and I was using the internal oscillator . For this I made the following changes.

                        In DK                                                                 On Custom board

---------------------------------------------------------------------------------------------------------

1)  #define CLOCK_CONFIG_LF_SRC 1    -------------  #define CLOCK_CONFIG_LF_SRC 0

2) #define NRF_SDH_CLOCK_LF_SRC 1 ----------------  #define NRF_SDH_CLOCK_LF_SRC 0

3) #define NRF_SDH_CLOCK_LF_RC_CTIV 0 --------#define NRF_SDH_CLOCK_LF_RC_CTIV 16

4) #define NRF_SDH_CLOCK_LF_RC_TEMP_CTIV 0----#define NRF_SDH_CLOCK_LF_RC_TEMP_CTIV 4

Now custom board is advertising. And  I could connect to the custom board from the App. But the connection is disconnected after some time( which was expected to stay connected till we initaite disconnect from the App/ restrt the peripheral) with the following message ( showing  of the nRFConnect App in phone)

Error 8 (0x8):GATT CONN TIMEOUT.

Is there anything I did wrong or Am I missing something when we shift to custom board from DK?

Please hel me in resolving the same as I was struggling  for the same in the past 3-4 days.

Thanking you in advance.

with regards,

Geetha

[Edvin]

Hello,

What is your NRF_SDH_CLOCK_LF_ACCURACY? Can you try to set it to 1, and see if that helps?

Also, try to lower NRF_SDH_CLOCK_LF_RC_TEMP_CTIV to 2 (you can keep NRF_SDH_CLOCK_LF_RC_CTIV = 16).

Please let me know if these settings shows the same behavior.

Best regards,

Edvin

[GK]

Hi Edvin,

I made the following change NRF_SDH_CLOCK_LF_ACCURACY to 1.

Now I think it is working fine.

There is a small tolerance in the timing specified.

I have gone through the following link, but I could not get a complete idea on the variable (#define statements).

They have mentioned it as follows

"External clock accuracy used in the LL to compute timing. ". But we are not using any external clock, right?

Will you please give a detailed description on each one what it signifies and how will it affect the working etc?

Thanking you in advance.

with regards,

Geetha

[Edvin]

Hello Geetha,

The softdevice uses the LFCLK to calculate for how long it can sleep. A less accurate clock means that the device has to wake up sooner and turn on the radio, to compensate for the clock inaccuracy.

When you have (NRF_SDH_CLOCK_LF_SRC == NRF_CLOCK_LF_SRC_RC) and (NRF_SDH_CLOCK_LF_ACCURACY != NRF_CLOCK_LF_ACCURACY_500_PPM) you should get a compiling warning. See nrf_sdh.c line 76-79. (At least those lines in SDK15.2.0)

So what happens is that the softdevice thinks it has a more accurate clock than it actually has, and it will sleep for a while. Usually, it goes fine, but then after a while, the devices gets out of sync. When they miss the first message, they can't synchronize either, so they will probably loose the connection, unless they all the sudden starts to drift back into sync within before the connection timeout event triggers.

 

GK said:

But we are not using any external clock, right?

 That is correct, but you still need to tell the softdevice the accuracy of the LFCLK.

BR,

Edvin

[GK]

Hello Edvin,

Thank you very much for your time and response.

So here we are using LFCLK, right? And the accuracy corrsponding to this is "NRF_CLOCK_LF_ACCURACY_500_PPM".

Am I correct?

BR,

Geetha

[Edvin]

Hello Geetha,

 

GK said:

So here we are using LFCLK, right?

 Depends on where you are talking about. The softdevice uses LFCLK indeed. The SPI is not.

 

GK said:

And the accuracy corrsponding to this is "NRF_CLOCK_LF_ACCURACY_500_PPM"

 If you are using the RC oscillator, then you should set the accuracy to NRF_CLOCK_LF_ACCURACY_500_PPM, yes.

Although this may confuse you even more, there are advantages and disadvantages using an external LFXTAL.

 - An external LFXTAL is an extra component for your product.

 + The LFXTAL is more accurate.

 - The LFXTAL draws a bit more power

 + The LFXTAL doesn't need calibration like the RC-oscillator does. It costs power to calibrate, so it may actually draw more power than the LFXTAL.

 + Using an LFXTAL (more accurate) will give you a more accurate radio window in BLE, meaning you can sleep longer -> spend less time on the radio. The radio draws power when activated, so all in all, you will save power using an LFXTAL.

But the short answer for your question is: Yes. When you use the RC Oscillator, you must set the accuracy to NRF_CLOCK_LF_ACCURACY_500_PPM in sdk_config.h.

[EricDelangis]

Hello Edvin,

We have an nRF52 DK system running ble_app_uart_c example code and communicating with a peripheral device.  We setup a second development system using another nRF52 DK system running the exact same code as the first system but after about 6 seconds after a connection we get a timeout error 0x08 and it disconnects.  

I've tried changing the clock accuracy settings as you describe above but no effect. 

<info> app: Connected to device with Nordic UART Service.
<info> app: Disconnected.
<info> app: Disconnected. conn_handle: 0x0, reason: 0x8
<info> app: Connecting to target 520822071920
<info> app: ATT MTU exchange completed.
<info> app: Ble NUS max data length set to 0x14(20)
<info> app: Discovery complete.
<info> app: Connected to device with Nordic UART Service.
<info> app: Disconnected.
<info> app: Disconnected. conn_handle: 0x0, reason: 0x8
<info> app: Connecting to target 520822071920
<info> app: ATT MTU exchange completed.
<info> app: Ble NUS max data length set to 0x14(20)
<info> app: Discovery complete.
<info> app: Connected to device with Nordic UART Service.
<info> app: Disconnected.
<info> app: Disconnected. conn_handle: 0x0, reason: 0x8

You can see from the debug window that we are stuck in this loop.

We are also running the exact same development configuration on both systems:

SDK 15.3

Segger SES V 4.10

nRF DK PCA 10040

Please advise.

[Edvin]

Hello,

Please create a new ticket, where you describe the issue and attach the sniffer trace (it may be useful for the engineer which the case will be assigned to). It is probably a request that isn't answered to from one of the devices. 

Best regards,

Edvin