When the central device connects to the peripheral device, the connection is lost. The reason is BLE_HCI_CONN_FAILED_TO_BE_ESTABLISHED.

[Chaoyue Ying]

I attempted to connect the central device to the peripheral device.

Both sides are custom boards of nrf52832 and both are based on nrfSDK v17.

The log output on central is as follows：

00> <debug> ble_scan: Scanning
00> 
00> <debug> ble_scan: Connecting
00> 
00> <debug> ble_scan: Connection status: 0
00> 
00> <debug> ble_scan: Conn params:min:6,max:24,sl:0,cst:400
00> 
00> <info> app: Scan FILTER MATCH.
00> 
00> <info> app: name:
00> 
00>  41 6E 6E 79 5F 45 54 43|Anny_ETC
00> 
00>  5F 31 39 36 31         |_1961   
00> 
00> <debug> nrf_ble_gatt: Requesting to update ATT MTU to 247 bytes on connection 0x0.
00> 
00> <debug> nrf_ble_gatt: Updating data length to 251 on connection 0x0.
00> 
00> <info> app: Connected.
00> 
00> <info> app: 19:61:78:87:1E:DE
00> 
00> <info> app: Connection 0x0 has been disconnected. Reason: 0x3E

Peripheral uses UART to output logs.When the central unit outputs the above log, the peripheral does not make any output.

I looked for the information related to "BLE_HCI_CONN_FAILED_TO_BE_ESTABLISHED" in the devzone.

It seems to be because  the peripheral does not respond to the first 6 connection events.

What can I do to make it easier and even faster for them to connect?

[Kenneth]

Hi,

Both sides are custom boards of nrf52832

Have you done any verification of the hardware?

If not, you can setup the radio test example:
https://docs.nordicsemi.com/bundle/sdk_nrf5_v17.0.2/page/nrf_radio_test_example.html 

Then use the start_channel and start_tx_carrier commands.

You should then for instance see a unmdulated carrier exactly on the frequency of 2400MHz + channel, e.g. 2402MHz if channel = 2.

You then need access to a spectrum analyzer, set it up to sweep around 2.402MHz and check how much off the center frequency the carrier is. If it's within specification it should be maximum +-96kHz off center frequency.

Also, for the low frequency 32.768kHz clock, are you using internal or external, and what it the configured tolerance in ppm for the clock? Possible try with 500ppm if you haven't tried it already.

Kenneth

[Chaoyue Ying]

Hi,

Do you think there is a problem with the customized board's advertising?

I currently don't have a spectrum analyzer at hand. According to the documentation, do I need to use the second method and employ two boards for both transmission and reception?

32.768kHz clock uses an external clock. The ppm currently used is 20ppm. I will try 500ppm.

[Kenneth]

Chaoyue Ying said:

Do you think there is a problem with the customized board's advertising?

If increasing the tolerance of the 32.768kHz doesn't help, then it's likely related to the 32MHz clock, and it can only be measured indirectly by using a spectrum analyzer.

Kenneth

[Chaoyue Ying]

Hi Kenneth,

Since I don't have a spectrum analyzer at the moment, I used a clumsy method today.

I gradually replaced the custom board with the DK board for testing (although the board-level hardware settings were different, I only needed to focus on the Bluetooth part itself)

I found that this problem always occurs when the central uses the custom board.

However, after comparing the circuit diagrams, I did not find any obvious errors.So I attempted to modify the clock settings.Configuration as follows:

// <o> NRF_SDH_CLOCK_LF_SRC  - SoftDevice clock source.
 
// <0=> NRF_CLOCK_LF_SRC_RC 
// <1=> NRF_CLOCK_LF_SRC_XTAL 
// <2=> NRF_CLOCK_LF_SRC_SYNTH 

#ifndef NRF_SDH_CLOCK_LF_SRC
#define NRF_SDH_CLOCK_LF_SRC 1
#endif

// <o> NRF_SDH_CLOCK_LF_RC_CTIV - SoftDevice calibration timer interval. 
#ifndef NRF_SDH_CLOCK_LF_RC_CTIV
#define NRF_SDH_CLOCK_LF_RC_CTIV 16
#endif

// <o> NRF_SDH_CLOCK_LF_RC_TEMP_CTIV - SoftDevice calibration timer interval under constant temperature. 
// <i> How often (in number of calibration intervals) the RC oscillator shall be calibrated
// <i>  if the temperature has not changed.

#ifndef NRF_SDH_CLOCK_LF_RC_TEMP_CTIV
#define NRF_SDH_CLOCK_LF_RC_TEMP_CTIV 2
#endif

// <o> NRF_SDH_CLOCK_LF_ACCURACY  - External clock accuracy used in the LL to compute timing.
 
// <0=> NRF_CLOCK_LF_ACCURACY_250_PPM 
// <1=> NRF_CLOCK_LF_ACCURACY_500_PPM 
// <2=> NRF_CLOCK_LF_ACCURACY_150_PPM 
// <3=> NRF_CLOCK_LF_ACCURACY_100_PPM 
// <4=> NRF_CLOCK_LF_ACCURACY_75_PPM 
// <5=> NRF_CLOCK_LF_ACCURACY_50_PPM 
// <6=> NRF_CLOCK_LF_ACCURACY_30_PPM 
// <7=> NRF_CLOCK_LF_ACCURACY_20_PPM 
// <8=> NRF_CLOCK_LF_ACCURACY_10_PPM 
// <9=> NRF_CLOCK_LF_ACCURACY_5_PPM 
// <10=> NRF_CLOCK_LF_ACCURACY_2_PPM 
// <11=> NRF_CLOCK_LF_ACCURACY_1_PPM 

#ifndef NRF_SDH_CLOCK_LF_ACCURACY
#define NRF_SDH_CLOCK_LF_ACCURACY 1
#endif

// </h> 
//==========================================================

Under this configuration, the connection can be established quickly and almost no BLE_HCI_CONN_FAILED_TO_BE_ESTABLISHED errors are observed.

However, each connection failed with the error code BLE_HCI_CONNECTION_TIMEOUT.

In conclusion, I might need to switch to a different external clock source? How can the issue of BLE_HCI_CONNECTION_TIMEOUT be resolved?

[Kenneth]

Do you have any specifications for the 32MHz crystal you have chosen, and which capacitor values have you placed on the 32MHz crystal?

Kenneth