Disconnected (reason 0x08)

Hey, 

My code worked fine in 52832. but after moving to 52811, it keeps disconnect itself with the reason 0x08. How can I fix it? 

I am using NCS 2.4.2.

I changed conf for 52811 in order to get smaller size, as listed below:

CONFIG_UART_CONSOLE=n
CONFIG_USE_SEGGER_RTT=y
CONFIG_RTT_CONSOLE=y

CONFIG_BT=y
CONFIG_BT_DEBUG_LOG=n
CONFIG_BT_SMP=y
CONFIG_BT_PERIPHERAL=y
CONFIG_BT_DIS_PNP=n
CONFIG_BT_BAS=y

CONFIG_BT_ATT_ENFORCE_FLOW=n

CONFIG_ADC=y

# Drivers and peripherals
CONFIG_I2C=y
CONFIG_WATCHDOG=n
CONFIG_PINCTRL=y
CONFIG_SPI=n
CONFIG_GPIO=y
CONFIG_SERIAL=n

# Power management
CONFIG_PM=n

# Interrupts
CONFIG_DYNAMIC_INTERRUPTS=n
CONFIG_IRQ_OFFLOAD=n

# Memory protection
CONFIG_THREAD_STACK_INFO=n
CONFIG_THREAD_CUSTOM_DATA=n
CONFIG_FPU=n

# Boot
CONFIG_BOOT_BANNER=n
CONFIG_BOOT_DELAY=0

# Console
# CONFIG_CONSOLE=n
# CONFIG_UART_CONSOLE=n
# CONFIG_STDOUT_CONSOLE=n
# CONFIG_PRINTK=n
# CONFIG_EARLY_CONSOLE=n

# Build
CONFIG_SIZE_OPTIMIZATIONS=y

# ARM
# CONFIG_ARM_MPU=n

# In order to correctly tune the stack sizes for the threads the following
# Configurations can enabled to print the current use:
# CONFIG_THREAD_NAME=y
# CONFIG_THREAD_ANALYZER=y
# CONFIG_THREAD_ANALYZER_AUTO=y
# CONFIG_THREAD_ANALYZER_RUN_UNLOCKED=y
# CONFIG_THREAD_ANALYZER_USE_PRINTK=y
# CONFIG_THREAD_ANALYZER_AUTO_INTERVAL=20
# CONFIG_CONSOLE=y
# CONFIG_UART_CONSOLE=y
# CONFIG_SERIAL=y
# CONFIG_PRINTK=y

# Example output of thread analyzer
# BT RX : STACK: unused 576 usage 448 / 1024 (43 %); CPU: 0 %
# BT RX pri : STACK: unused 260 usage 188 / 448 (41 %); CPU: 0 %
# BT ECC : STACK: unused 256 usage 888 / 1144 (77 %); CPU: 1 %
# BT TX : STACK: unused 296 usage 344 / 640 (53 %); CPU: 0 %
# thread_analyzer : STACK: unused 128 usage 384 / 512 (75 %); CPU: 1 %
# sysworkq : STACK: unused 856 usage 168 / 1024 (16 %); CPU: 0 %
# logging : STACK: unused 232 usage 536 / 768 (69 %); CPU: 0 %
# idle 00 : STACK: unused 208 usage 48 / 256 (18 %); CPU: 97 %
# main : STACK: unused 576 usage 448 / 1024 (43 %); CPU: 0 %
CONFIG_BT_RX_STACK_SIZE=1024
CONFIG_BT_CTLR_RX_PRIO_STACK_SIZE=448
CONFIG_BT_HCI_TX_STACK_SIZE_WITH_PROMPT=y
CONFIG_BT_HCI_TX_STACK_SIZE=640
CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=512
CONFIG_IDLE_STACK_SIZE=128
CONFIG_MAIN_STACK_SIZE=640
CONFIG_ISR_STACK_SIZE=1024

# Disable features not needed
CONFIG_TIMESLICING=n
CONFIG_MINIMAL_LIBC_MALLOC=n
# CONFIG_LOG=n
CONFIG_ASSERT=n

# Disable Bluetooth features not needed
# CONFIG_BT_DEBUG_NONE=y
CONFIG_BT_ASSERT=n
CONFIG_BT_DATA_LEN_UPDATE=n
CONFIG_BT_PHY_UPDATE=n
CONFIG_BT_GATT_CACHING=n
CONFIG_BT_GATT_SERVICE_CHANGED=n
CONFIG_BT_GAP_PERIPHERAL_PREF_PARAMS=n
CONFIG_BT_SETTINGS_CCC_LAZY_LOADING=y
CONFIG_BT_HCI_VS_EXT=n

# Disable Bluetooth controller features not needed
CONFIG_BT_CTLR_PRIVACY=n
CONFIG_BT_CTLR_PHY_2M=n

# Reduce Bluetooth buffers
CONFIG_BT_BUF_EVT_DISCARDABLE_COUNT=1
CONFIG_BT_BUF_EVT_DISCARDABLE_SIZE=45
CONFIG_BT_BUF_ACL_RX_COUNT=2
CONFIG_BT_BUF_EVT_RX_COUNT=2

CONFIG_BT_CONN_TX_MAX=2
CONFIG_BT_L2CAP_TX_BUF_COUNT=2
CONFIG_BT_CTLR_RX_BUFFERS=1
CONFIG_BT_BUF_ACL_TX_COUNT=3
CONFIG_BT_BUF_ACL_TX_SIZE=27

Parents
  • Hi, 

    Disconnection reason 0x08 means BLE_HCI_CONNECTION_TIMEOUT.

    This happens either because the radio link was bad causing a lot of packet drop and resulting in connection timeout. Or the nRF52811 was crashed and couldn't continue the BLE link. 

    I would suggest to capture a sniffer trace so we get to know more on what happen over the air. 

    Please also check the log on the nRF52811 to see if it has any assertion. 

    If you flash a sample (for example peripheral_lbs) in our SDK to the chip do you see the problem ? 

Reply
  • Hi, 

    Disconnection reason 0x08 means BLE_HCI_CONNECTION_TIMEOUT.

    This happens either because the radio link was bad causing a lot of packet drop and resulting in connection timeout. Or the nRF52811 was crashed and couldn't continue the BLE link. 

    I would suggest to capture a sniffer trace so we get to know more on what happen over the air. 

    Please also check the log on the nRF52811 to see if it has any assertion. 

    If you flash a sample (for example peripheral_lbs) in our SDK to the chip do you see the problem ? 

Children
Related