nRF52 strange BLE connection behavior

[AndrazV]

I'm getting strange behavior when connecting to nRF52840DK. 

Log from nRF:

<debug> nrf_sdh_ble: BLE event: 0x10.
<debug> nrf_ble_gatt: Updating data length to 26 on connection 0x0.
<error> nrf_ble_gatt: sd_ble_gap_data_length_update() (request) on connection 0x0 returned NRF_ERROR_INVALID_PARAM.
<error> nrf_ble_gatt: sd_ble_gattc_exchange_mtu_request() returned NRF_ERROR_INVALID_PARAM.
<info> app: BLE event received. Event type = 16

Log from android nRF Connect:

D	11:24:19.146	gatt.close()
D	11:24:19.157	wait(200)
V	11:24:19.369	Connecting to E5:2B:3E:67:23:CD...
D	11:24:19.369	gatt = device.connectGatt(autoConnect = false, TRANSPORT_LE, preferred PHY = LE 1M)
D	11:24:19.979	[Server callback] Connection state changed with status: 0 and new state: DISCONNECTED (0)
I	11:24:19.979	[Server] Device disconnected
D	11:24:20.714	[Callback] Connection state changed with status: 133 and new state: DISCONNECTED (0)
E	11:24:20.714	Error 133 (0x85): GATT ERROR
I	11:24:20.714	Disconnected

The same code works on our custom board (nrf52832). We use custom service (I have followed your custom ble service example) but this happens regardless of whether it is initialized or not. SDK configs are the same apart from logging and clock configurations.

It seems to me that I must have modified something while adding the custom service that is causing this, but I can't find what.

I use nRF5_SDK_17.0.2_d674dde, s140_nrf52_7.2.0_softdevice for DK and s132_nrf52_7.2.0_softdevice for custom board.

We need it to work on both, the DK and the custom board, so app and firmware development can continue independently (We don't have nRF52832DK).

[Amanda Hsieh]

Hi, 

As described in the API documentation for sd_ble_gattc_exchange_mtu_request(), NRF_ERROR_INVALID_PARAM is thrown when "Invalid Client RX MTU size supplied". Further, the valid Client RX MTU sizes are:

• The minimum value is BLE_GATT_ATT_MTU_DEFAULT.
• The maximum value is ble_gatt_conn_cfg_t::att_mtu in the connection configuration used for this connection.

Do you have the NRF_SDH_BLE_GATT_MAX_MTU_SIZE symbol in sdk_config.h? What is the size?

-Amanda H.

[AndrazV]

Hi,

NRF_SDH_BLE_GATT_MAX_MTU_SIZE is set to 23 (same as in your custom service tutorial).

It looks like having J-Link RTT Viewer connected to the DK is causing this error. When RTT viewer is not connected to the DK everything works as expected.

My current RTT configuration is:

SEGGER_RTT_CONFIG_BUFFER_SIZE_UP 512
SEGGER_RTT_CONFIG_MAX_NUM_UP_BUFFERS 2
SEGGER_RTT_CONFIG_BUFFER_SIZE_DOWN 16
SEGGER_RTT_CONFIG_MAX_NUM_DOWN_BUFFERS 2
SEGGER_RTT_CONFIG_DEFAULT_MODE 0
NRF_LOG_BACKEND_RTT_TEMP_BUFFER_SIZE 64
NRF_LOG_BACKEND_RTT_TX_RETRY_DELAY_MS 1
NRF_LOG_BACKEND_RTT_TX_RETRY_CNT 3

I'm using J-Link RTT Viewer V6.44e. Is there any known bug in this version of RTT or nRF SDK?

Or is it just my configuration that is wrong?

[Amanda Hsieh]

Hi Andraz, 

The config looks fine. Which example are you using as based?

-Amanda H.

[AndrazV]

Hi Amanda,

We stopped using DK and, are now using an old revision of HW for app development.

I started to get the same error on our HW, but not always. When it connects successfully I get HardFault on disconnect after advertising is restarted.

I'm using a template example, but I have modified it so that BLE functions (like ble_stack_init, gatt_init, etc.) are in a separate file.

Now, I have moved those files back to the main.c, and problems got away. What is the reason for that? Are those functions placed in a region that softdevice shouldn't access if put in a separate file?

[Amanda Hsieh]

It needs to check the debug log and the hardfault. 

You can import HardFault handling library (include hardfault_implementation.c and hardfault_handler_gcc.c from \components\libraries\hardfault in your project) and enable HARDFAULT_HANDLER_ENABLED in the sdk_config.h. 

// <q> HARDFAULT_HANDLER_ENABLED - hardfault_default - HardFault default handler for debugging and release

#ifndef HARDFAULT_HANDLER_ENABLED
#define HARDFAULT_HANDLER_ENABLED 1
#endif

I would suggest you create a new support case for the HardFault if you want to debug with it. This is away from the original scope.

-Amanda H.