Writing a BLE, FreeRTOS program for nRF52833, getting unexplained BLE_HCI_CONNECTION_TIMEOUT

[doryhealth]

Hello everyone

I hope you all had a good start to the week.

I am stuck with an issue I don't quite get. 

I wrote code with BLE, FreeRTOS, and GPIOTE as a "proof of concept" for more complex code. 

It's a simple idea: a press on the button triggers a notification. I use nRFConnect, the Bluetooth Low Energy app.

- I ran it on the nRF52840-DK / S140 and it works

- I ran it on the EV-BM833 (Fanstel) which uses a nRF52833, and I lose connection with BLE_HCI_CONNECTION_TIMEOUT

(I changed RAM settings, mostly inspired by the example "ble_app_hrs_nfc_pairing_pca10100_s140", and it compiles and runs.)

I've faced similar issues (BLE_HCI_CONNECTION_TIMEOUT) when testing other code with the nRF52833, in general.

Looking at the following link, I'm wondering whether it's a matter of clock. Any other idea?

https://devzone.nordicsemi.com/f/nordic-q-a/29786/ble_hci_connection_timeout-and-nrf_clock_lf_xtal_accuracy_xx_ppm

Thank you in advance!

[run_ar]

Hi,
In general if you have issue with connection supervision timeout. The first thing you should check is the 32kHz clock source. Check the spec of the source. If it is a crystal, make sure it is correctly loaded. And make sure you set the accuracy correctly in the application as that will be used to adjust the Radio's listening window to the correct size to take both the Peripheral and Central clock into account.

[doryhealth]

Hi run_ar

Thank you for your fast reply, much appreciated.

I went back to the HW and the datasheet states the crystal is 32.768kHz +/- 20ppm. 
I tried lowering the accuracy to 30, 50, 100ppm -> the same BLE_HCI_CONNECTION_TIMEOUT happens after ~10s

What do you mean with "correctly loaded"?
Is there anything else I can try?

Have a great day

Jerome

[run_ar]

If the module comes with the crystal it likely has the correct load capacitors (32.768 kHz crystal oscillator (LFXO)). You could try to change to the internal rc and 500ppm settings to see if this works.

In addition to changing flash and ram setting, did you also update the preprocessor setting to reflect the device you are using now?

There might also be differences between the DK and the module when it comes to pin out, so there is another thing to check.

[doryhealth]

Hi run_ar

Thank you, that was helpful.

Setting the LF clock to RC solves the problem. That, per se, is enough seen as we're at the prototype stage. I'm assume this also discard the preprocessor idea as well as that of the Flash/RAM.

I'm testing with 500ppm and it seems better but I've already seen a connection timeout on each of the custom chip (Fanstel BM833) and the Fanstel DK (EV-BM833).
I did update the preprocessor and double-checked.

Any further idea, for when we'll look at power optimization?
I specifically chose the same crystal for our custom board as the one Fanstel chose for their DK. The datasheet is attached.
ABS06W.pdf
As always, thank you for your help

Cheers

Jerome

[run_ar]

Did you mean that when using the RC it works on both DK and Fanstel modules? or is it still failing with the module? Please check, what is the size of the load capacitors connected to XL1 and XL2 on the custom design? Please check they are the correct size, ref: 32.768 kHz crystal oscillator (LFXO)

Did you check to see if the signal strength is similar on the DK and the fanstel module? i.e, you could try to measure rssi as going out of range will also cause a connection timeout.