nRF52833 stream notifying BLE packets get stuck frequently

[Juergen Laude]

Hello,

we do have a custom board with a nRF52833 to stream sensor data to a mobile app. The board contains a 32 MHz crystal, but not a 32.768 kHz. We are using nRF Connect SDK version 2.2.0 and the Softdevice controller for BLE. Our application is supposed to send 200 20-byte packets per second running on 2 Mbps.

Problem: Keeping the board resting allowed multiple times to stream 2 h without a problem. Moving the board (the main use case) got the stream stuck, sometimes within seconds sometimes only with stronger movement. Occasionally resting also leads to stuck streaming. Once the mobile app disconnects everything recovers. We do have purchased custom boards that work fine with the mobile app, so the problem must be within our own boards HW or FW. Moving the board (within a case) means holding it in one hand, so the impact might be temperature.

To analyse this further we made a reduced application showing the same problem when only streaming zero filled packets and sensors disabled. The stream gets stuck in "bt_gatt_notify()". The behavior is on 7 of 7 boards, so it shouldn't be faulty single board.

The major parts of prj.config:

CONFIG_BT=y

CONFIG_BT_PERIPHERAL=y

CONFIG_BT_DEVICE_NAME_DYNAMIC=y

CONFIG_BT_BAS=y

CONFIG_BT_BUF_ACL_TX_COUNT=32

CONFIG_BT_ATT_ENFORCE_FLOW=n

CONFIG_BT_DEBUG_LOG=y

CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=4096

and for the board:

CONFIG_SOC_SERIES_NRF52X=y

CONFIG_SOC_NRF52833_QIAA=y

CONFIG_ARM_MPU=y

CONFIG_HW_STACK_PROTECTION=y

CONFIG_BOARD_ENABLE_DCDC=n

CONFIG_GPIO_AS_PINRESET=n

CONFIG_CLOCK_CONTROL_NRF=y

CONFIG_CLOCK_CONTROL_NRF_K32SRC_SYNTH=y

# CLOCK_CONTROL_NRF_K32SRC_RC=y

# CONFIG_CLOCK_CONTROL_NRF_K32SRC_500PPM=y

# CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC_CALIBRATION=y

Initially we used RF for the LFCLK but after a while it connected only shortly on the board side and not in the mobile app anymore. This went away when using SYNTH instead (maybe this helps for diagnosing the problem).

Live debugging and logging is not really possible when moving the board. We were able to connect a LogVewer over RTT after it got stuck, but got no extra logs from the driver.

We tried sending 2 packets every 10 msec and 4 packets every 20 msec, both had the problem.

We are out of ideas how to narrow the problem down:

Could it be the connection parameters (we are using defaults)?

Could it be the board or app config parameters?

Could it be the HW e.g. the crystal oscillator (although our electronics developer said he measured it and it would be OK)?

What further changes would help in diagnosis?

Thanks in advance,

Jürgen

[Susheel Nuguru]

We need to get more context on what the state of "Stuck" means in this issue. 

This went away when using SYNTH instead (maybe this helps for diagnosing the problem).

Using internal RC for LFCLK might not be good enough for the accuracy of the BLE connection timekeeping. If you are using RC for LFCLK they frequently needs to be calibrated based on the HFCLK Crystal or you need to use SYNTH LFCLK derived from hfclk itself.

[Juergen Laude]

"Stuck" means the call to "bt_gatt_notify()" does not return although the mobile app tries to receive the notifications.

For internal RC for LFCLK we had:

CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y

CONFIG_CLOCK_CONTROL_NRF_K32SRC_500PPM=y

CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC_CALIBRATION=y

do we need more?

[Juergen Laude]

Problem almost solved: While movement lots of packets get lost and BLE TX buffer fills-up. "bt_gatt_notify" unfortunately waits until the buffer gets space again, a return code would be nicer. Could't find a function to request the current fill level, so I have to count from outside.

Forcing the connection interval to 15 msec (default 30 msec) seems to give more chances to re-transmit lost packets.

I will test more on using RC for LFCLK especially because of the limitation "DRGN-6362: Synthesized low frequency clock source not tested".

[Susheel Nuguru]

Juergen Laude said:

"bt_gatt_notify" unfortunately waits until the buffer gets space again, a return code would be nice

I agree, this has been asked by few before, so I will check with the R&D team if we can make this purely asynchronous with an error when no buffer is available.

Juergen Laude said:

I will test more on using RC for LFCLK especially because of the limitation "DRGN-6362: Synthesized low frequency clock source not tested".

sounds like a plan. Thanks for letting me know.