• State Verified Answer
  • Replies 1 reply
  • Subscribers 73 subscribers
  • Views 3086 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 296532
Options

How to debug BLE timeout (reason = 0x08)

CktDesigner

Short description:   After establishing a BLE connection between two nRF52840 based boards (both running Zephyr) and starting data transmission (one transfer about every 500 ms), the connection disconnects with reason 0x08 (timeout)

More detail:

System:   A "sensor" board communicates with a "repeater" board which forwards packets to an Android device.   Communications between the sensor and repeater are "coded PHY" BLE.    Communications between the repeater and Android device are currently also coded PHY (but may not be in the future).

Sensor: Sensor custom board based on Laird BL654PA (nRF52840 with power amplifier) using Zephyr (Zephyr OS build v3.0.99-ncs1-1 as distributed in nRF Connect SDK 2.0.2).   There is an external 32 kHz crystal supporting the BL654PA.     The following image shows the SoftDevice log entry from Zephyr when it starts:

Repeater: Repeater custom board will also be based on Laird BL654PA, but for now is emulated using nRF52840-DK.   It also uses Zephyr (same version) with same SoftDevice.   The nRF52840-DK also has a 32 kHZ crystal.

Android device: Currently Samsung Galaxy S10 phone.

The prj.conf files for both the sensor and repeater have the lines:

CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=n

CONFIG_CLOCK_CONTROL_NRF_K32SRC_XTAL=y

I can monitor communications from the phone to the repeater to the sensor...    and monitor communications from the sensor to the repeater to the phone.     Control packets are sent to start the sensor and data is transmitted at about one packet every 500 ms.    After some (random) period of time, the connection between the sensor and repeater drops with the "reason" reported in the repeater as 0x08.    My interpretation is that this is a timeout at the lower levels of the BLE protocol where the control layers of the two devices (sensor/repeater) have stopped communicating.

Higher level code seems to be working as expected (the sensor is still acquiring reading and attempting to send packets).    I believe the timeout is happening inside the BLE driver, but am not sure how to debug why the timeout is occuring.

Searching DevZone has some older entries that suggest some other prf.conf file CONFIG_ statements that no longer exist.

Suggestions??

Thanks!

Parents
  • +1

    Hello,

    It sounds like you have understood the error correctly. Error 8, or BT_HCI_ERR_CONN_TIMEOUT, is raised by the lower layer of the Bluetooth stack if it stops receiving packets from a connected device for longer than the supervision timeout. And this is the disconnect reason you can expect to see if one of the devices is moved out of range, for instance.

    From other posts you may have seen that excessive drift on the 32 KHz can lead to intermittent connection problems like this. An easy way you can rule out this as a possible root cause is to repeat the test with the LFSYNT  clock instead (selected through CONFIG_CLOCK_CONTROL_NRF_K32SRC_SYNTH - you will want to select this on both the repeater and sensor board for this test).

    The following image shows the SoftDevice log entry from Zephyr when it starts:

    Do you have logging from both boards? I'm basically wondering if you will detect if one of the boards is reset while connected due to an error, etc.. This will almost always lead to a BT_HCI_ERR_CONN_TIMEOUT on the other side of the connection.

    Best regards,

    Vidar

Reply
  • +1

    Hello,

    It sounds like you have understood the error correctly. Error 8, or BT_HCI_ERR_CONN_TIMEOUT, is raised by the lower layer of the Bluetooth stack if it stops receiving packets from a connected device for longer than the supervision timeout. And this is the disconnect reason you can expect to see if one of the devices is moved out of range, for instance.

    From other posts you may have seen that excessive drift on the 32 KHz can lead to intermittent connection problems like this. An easy way you can rule out this as a possible root cause is to repeat the test with the LFSYNT  clock instead (selected through CONFIG_CLOCK_CONTROL_NRF_K32SRC_SYNTH - you will want to select this on both the repeater and sensor board for this test).

    The following image shows the SoftDevice log entry from Zephyr when it starts:

    Do you have logging from both boards? I'm basically wondering if you will detect if one of the boards is reset while connected due to an error, etc.. This will almost always lead to a BT_HCI_ERR_CONN_TIMEOUT on the other side of the connection.

    Best regards,

    Vidar

Children
No Data
Related
Terms of service