Unable to read long characteristics when MTU is 23 bytes using nRF Connect Android APP

[RRWC]

Information about my setup:

I'm working on a product using nRF52832 with SDK 17.0.2 and Softdevice s132 7.2.0. It is a custom board.

The default configuration (peripheral side - nRF52832) negotiate BLE connection parameters as follows:

• MTU: 230 Bytes
• Data Lenght: 234 Bytes (NRF_SDH_BLE_GAP_DATA_LENGTH)
• NRF_SDH_BLE_GAP_EVENT_LENGTH: 10 (1.25 ms units)
• PHY: 2 MB
• MIN_CONN_INTERVAL: 150 ms
• MAX_CONN_INTERVAL: 180 ms
• SLAVE_LATENCY: 5
• CONN_SUP_TIMEOUT: 4000 ms

The device (nRF52832) have a custom service with multiple characteristics. Some of these characteristics can have up to 512 bytes of data available to read. The Nordic nRF Connect Android APP is used for test purposes and the reading of characteristics is performed using the "down arrow" read button available in the APP next to all characteristics configured as "read enabled". A few recent smartphone models from different brands were used in tests, all with the same results.

Normal Behavior:

When the device connects to a smartphone, the parameter negotiation ends smoothly within the specified parameters. All readable characteristics in the custom service can be read with no problems. 

Problem situation:

Multiple tests are performed to confirm proper device operation in various use cases. One of the tests requires renegotiating some of the above parameters after the connection is stablished.

The problem starts when the MTU is changed to 23 (regardless of other parameters). The negotiation of the MTU itself finishes successfully. After that, only characteristics with few bytes of data can be read. If you try to read longer characteristics a GATT 133 error is reported in the nRF Connect side and the data is not received. The nRF52832 appears to believe the data has been sent and updates the data for new readings.

The connection is not lost after GATT 133 error, it remains stable and other characteristics can be read. If the characteristics are larger than a certain amount of bytes a new GATT 133 error is reported, otherwise the data is correctly received by nRF Connect.

Is there some configuration or something that could be preventing more than a few bytes of data from being read from a characteristic when the smartphone negotiates a 23 bytes MTU?

Is there any way (or any reading mode of BLE characteristics) to automatically confirm that data has been received by the smartphone on the nRF52832? Some of the data must be erased from the device after the smartphone reads it, it would be nice to have confirmation of data delivery in the lower layers of the BLE/SDK to avoid this kind of management in my code.

Thank you in advance for your help.

[Hung Bui]

Hi RRWC, 

Could you try to capture a sniffer trace ? Which phones did you use to test ? Could you use NRF Connect app to test ? 
Error 133 is a generic error , so it doesn't tell much. 

Please note that the MTU can only be updated once. If by default it's 23 and changed to anything else, you can't change it back to 23. 
I did a quick test here and it seems that it worked fine with the ATT_MTU of 23. (NRF_SDH_BLE_GATT_MAX_MTU_SIZE)

You can see that the read blob was successful and the length was 23 bytes on each packet. 

I attached here my quick example with a characteristic with 100 bytes length initial value. Please replace the ble_nus.c of the ble_app_uart example. If you do a read from the phone on the TX characteristic it should give you 100 bytes array. 

Fullscreen 0602.ble_nus.c Download

/**
 * Copyright (c) 2012 - 2021, Nordic Semiconductor ASA
 *
 * All rights reserved.
 *
 * Redistribution and use in source and binary forms, with or without modification,
 * are permitted provided that the following conditions are met:
 *
 * 1. Redistributions of source code must retain the above copyright notice, this
 *    list of conditions and the following disclaimer.
 *
 * 2. Redistributions in binary form, except as embedded into a Nordic
 *    Semiconductor ASA integrated circuit in a product or a software update for
 *    such product, must reproduce the above copyright notice, this list of
 *    conditions and the following disclaimer in the documentation and/or other
 *    materials provided with the distribution.
 *
 * 3. Neither the name of Nordic Semiconductor ASA nor the names of its
 *    contributors may be used to endorse or promote products derived from this
 *    software without specific prior written permission.
 *
 * 4. This software, with or without modification, must only be used with a
 *    Nordic Semiconductor ASA integrated circuit.
 *
 * 5. Any software provided in binary form under this license must not be reverse
 *    engineered, decompiled, modified and/or disassembled.
 *
 * THIS SOFTWARE IS PROVIDED BY NORDIC SEMICONDUCTOR ASA "AS IS" AND ANY EXPRESS
 * OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
 * OF MERCHANTABILITY, NONINFRINGEMENT, AND FITNESS FOR A PARTICULAR PURPOSE ARE
 * DISCLAIMED. IN NO EVENT SHALL NORDIC SEMICONDUCTOR ASA OR CONTRIBUTORS BE
 * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
 * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE
 * GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
 * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
 * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
 * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 *
 */
#include "sdk_common.h"
#if NRF_MODULE_ENABLED(BLE_NUS)
#include "ble.h"
#include "ble_nus.h"
#include "ble_srv_common.h"

#define NRF_LOG_MODULE_NAME ble_nus
#if BLE_NUS_CONFIG_LOG_ENABLED
#define NRF_LOG_LEVEL       BLE_NUS_CONFIG_LOG_LEVEL
#define NRF_LOG_INFO_COLOR  BLE_NUS_CONFIG_INFO_COLOR
#define NRF_LOG_DEBUG_COLOR BLE_NUS_CONFIG_DEBUG_COLOR
#else // BLE_NUS_CONFIG_LOG_ENABLED
#define NRF_LOG_LEVEL       0
#endif // BLE_NUS_CONFIG_LOG_ENABLED
#include "nrf_log.h"
NRF_LOG_MODULE_REGISTER();


#define BLE_UUID_NUS_TX_CHARACTERISTIC 0x0003               /**< The UUID of the TX Characteristic. */
#define BLE_UUID_NUS_RX_CHARACTERISTIC 0x0002               /**< The UUID of the RX Characteristic. */

#define BLE_NUS_MAX_RX_CHAR_LEN        BLE_NUS_MAX_DATA_LEN /**< Maximum length of the RX Characteristic (in bytes). */
#define BLE_NUS_MAX_TX_CHAR_LEN        BLE_NUS_MAX_DATA_LEN /**< Maximum length of the TX Characteristic (in bytes). */

#define NUS_BASE_UUID                  {{0x9E, 0xCA, 0xDC, 0x24, 0x0E, 0xE5, 0xA9, 0xE0, 0x93, 0xF3, 0xA3, 0xB5, 0x00, 0x00, 0x40, 0x6E}} /**< Used vendor specific UUID. */


/**@brief Function for handling the @ref BLE_GAP_EVT_CONNECTED event from the SoftDevice.
 *
 * @param[in] p_nus     Nordic UART Service structure.
 * @param[in] p_ble_evt Pointer to the event received from BLE stack.
 */
static void on_connect(ble_nus_t * p_nus, ble_evt_t const * p_ble_evt)
{
    ret_code_t                 err_code;
    ble_nus_evt_t              evt;
    ble_gatts_value_t          gatts_val;
    uint8_t                    cccd_value[2];
    ble_nus_client_context_t * p_client = NULL;

    err_code = blcm_link_ctx_get(p_nus->p_link_ctx_storage,
                                 p_ble_evt->evt.gap_evt.conn_handle,
                                 (void *) &p_client);
    if (err_code != NRF_SUCCESS)
    {
        NRF_LOG_ERROR("Link context for 0x%02X connection handle could not be fetched.",
                      p_ble_evt->evt.gap_evt.conn_handle);
    }

    /* Check the hosts CCCD value to inform of readiness to send data using the RX characteristic */
    memset(&gatts_val, 0, sizeof(ble_gatts_value_t));
    gatts_val.p_value = cccd_value;
    gatts_val.len     = sizeof(cccd_value);
    gatts_val.offset  = 0;

    err_code = sd_ble_gatts_value_get(p_ble_evt->evt.gap_evt.conn_handle,
                                      p_nus->tx_handles.cccd_handle,
                                      &gatts_val);

    if ((err_code == NRF_SUCCESS)     &&
        (p_nus->data_handler != NULL) &&
        ble_srv_is_notification_enabled(gatts_val.p_value))
    {
        if (p_client != NULL)
        {
            p_client->is_notification_enabled = true;
        }

        memset(&evt, 0, sizeof(ble_nus_evt_t));
        evt.type        = BLE_NUS_EVT_COMM_STARTED;
        evt.p_nus       = p_nus;
        evt.conn_handle = p_ble_evt->evt.gap_evt.conn_handle;
        evt.p_link_ctx  = p_client;

        p_nus->data_handler(&evt);
    }
}


/**@brief Function for handling the @ref BLE_GATTS_EVT_WRITE event from the SoftDevice.
 *
 * @param[in] p_nus     Nordic UART Service structure.
 * @param[in] p_ble_evt Pointer to the event received from BLE stack.
 */
static void on_write(ble_nus_t * p_nus, ble_evt_t const * p_ble_evt)
{
    ret_code_t                    err_code;
    ble_nus_evt_t                 evt;
    ble_nus_client_context_t    * p_client;
    ble_gatts_evt_write_t const * p_evt_write = &p_ble_evt->evt.gatts_evt.params.write;

    err_code = blcm_link_ctx_get(p_nus->p_link_ctx_storage,
                                 p_ble_evt->evt.gatts_evt.conn_handle,
                                 (void *) &p_client);
    if (err_code != NRF_SUCCESS)
    {
        NRF_LOG_ERROR("Link context for 0x%02X connection handle could not be fetched.",
                      p_ble_evt->evt.gatts_evt.conn_handle);
    }

    memset(&evt, 0, sizeof(ble_nus_evt_t));
    evt.p_nus       = p_nus;
    evt.conn_handle = p_ble_evt->evt.gatts_evt.conn_handle;
    evt.p_link_ctx  = p_client;

    if ((p_evt_write->handle == p_nus->tx_handles.cccd_handle) &&
        (p_evt_write->len == 2))
    {
        if (p_client != NULL)
        {
            if (ble_srv_is_notification_enabled(p_evt_write->data))
            {
                p_client->is_notification_enabled = true;
                evt.type                          = BLE_NUS_EVT_COMM_STARTED;
            }
            else
            {
                p_client->is_notification_enabled = false;
                evt.type                          = BLE_NUS_EVT_COMM_STOPPED;
            }

            if (p_nus->data_handler != NULL)
            {
                p_nus->data_handler(&evt);
            }

        }
    }
    else if ((p_evt_write->handle == p_nus->rx_handles.value_handle) &&
             (p_nus->data_handler != NULL))
    {
        evt.type                  = BLE_NUS_EVT_RX_DATA;
        evt.params.rx_data.p_data = p_evt_write->data;
        evt.params.rx_data.length = p_evt_write->len;

        p_nus->data_handler(&evt);
    }
    else
    {
        // Do Nothing. This event is not relevant for this service.
    }
}


/**@brief Function for handling the @ref BLE_GATTS_EVT_HVN_TX_COMPLETE event from the SoftDevice.
 *
 * @param[in] p_nus     Nordic UART Service structure.
 * @param[in] p_ble_evt Pointer to the event received from BLE stack.
 */
static void on_hvx_tx_complete(ble_nus_t * p_nus, ble_evt_t const * p_ble_evt)
{
    ret_code_t                 err_code;
    ble_nus_evt_t              evt;
    ble_nus_client_context_t * p_client;

    err_code = blcm_link_ctx_get(p_nus->p_link_ctx_storage,
                                 p_ble_evt->evt.gatts_evt.conn_handle,
                                 (void *) &p_client);
    if (err_code != NRF_SUCCESS)
    {
        NRF_LOG_ERROR("Link context for 0x%02X connection handle could not be fetched.",
                      p_ble_evt->evt.gatts_evt.conn_handle);
        return;
    }

    if ((p_client->is_notification_enabled) && (p_nus->data_handler != NULL))
    {
        memset(&evt, 0, sizeof(ble_nus_evt_t));
        evt.type        = BLE_NUS_EVT_TX_RDY;
        evt.p_nus       = p_nus;
        evt.conn_handle = p_ble_evt->evt.gatts_evt.conn_handle;
        evt.p_link_ctx  = p_client;

        p_nus->data_handler(&evt);
    }
}


void ble_nus_on_ble_evt(ble_evt_t const * p_ble_evt, void * p_context)
{
    if ((p_context == NULL) || (p_ble_evt == NULL))
    {
        return;
    }

    ble_nus_t * p_nus = (ble_nus_t *)p_context;

    switch (p_ble_evt->header.evt_id)
    {
        case BLE_GAP_EVT_CONNECTED:
            on_connect(p_nus, p_ble_evt);
            break;

        case BLE_GATTS_EVT_WRITE:
            on_write(p_nus, p_ble_evt);
            break;

        case BLE_GATTS_EVT_HVN_TX_COMPLETE:
            on_hvx_tx_complete(p_nus, p_ble_evt);
            break;

        default:
            // No implementation needed.
            break;
    }
}


uint32_t ble_nus_init(ble_nus_t * p_nus, ble_nus_init_t const * p_nus_init)
{
    ret_code_t            err_code;
    ble_uuid_t            ble_uuid;
    ble_uuid128_t         nus_base_uuid = NUS_BASE_UUID;
    ble_add_char_params_t add_char_params;
    static uint8_t test[100];
    VERIFY_PARAM_NOT_NULL(p_nus);
    VERIFY_PARAM_NOT_NULL(p_nus_init);
    for (uint8_t i=0;i<100;i++) {
      if (i%10==0) test[i]=52; else test[i]=50;
    }
    
    // Initialize the service structure.
    p_nus->data_handler = p_nus_init->data_handler;

    /**@snippet [Adding proprietary Service to the SoftDevice] */
    // Add a custom base UUID.
    err_code = sd_ble_uuid_vs_add(&nus_base_uuid, &p_nus->uuid_type);
    VERIFY_SUCCESS(err_code);

    ble_uuid.type = p_nus->uuid_type;
    ble_uuid.uuid = BLE_UUID_NUS_SERVICE;

    // Add the service.
    err_code = sd_ble_gatts_service_add(BLE_GATTS_SRVC_TYPE_PRIMARY,
                                        &ble_uuid,
                                        &p_nus->service_handle);
    /**@snippet [Adding proprietary Service to the SoftDevice] */
    VERIFY_SUCCESS(err_code);

    // Add the RX Characteristic.
    memset(&add_char_params, 0, sizeof(add_char_params));
    add_char_params.uuid                     = BLE_UUID_NUS_RX_CHARACTERISTIC;
    add_char_params.uuid_type                = p_nus->uuid_type;
    add_char_params.max_len                  = 200;//BLE_NUS_MAX_RX_CHAR_LEN;
    add_char_params.init_len                 = 100;//sizeof(uint8_t);

    add_char_params.char_props.write         = 1;
    add_char_params.char_props.write_wo_resp = 1;

    add_char_params.read_access  = SEC_OPEN;
    add_char_params.write_access = SEC_OPEN;

    err_code = characteristic_add(p_nus->service_handle, &add_char_params, &p_nus->rx_handles);
    if (err_code != NRF_SUCCESS)
    {
        return err_code;
    }

    // Add the TX Characteristic.
    /**@snippet [Adding proprietary characteristic to the SoftDevice] */
    memset(&add_char_params, 0, sizeof(add_char_params));
    add_char_params.uuid              = BLE_UUID_NUS_TX_CHARACTERISTIC;
    add_char_params.uuid_type         = p_nus->uuid_type;
    add_char_params.max_len           = 200;//BLE_NUS_MAX_TX_CHAR_LEN;
    add_char_params.init_len          = 100;//sizeof(uint8_t);
    add_char_params.is_var_len        = true;
    add_char_params.char_props.notify = 1;
    add_char_params.char_props.read= 1;
        add_char_params.p_init_value = test;
    add_char_params.is_value_user= 1; 

    add_char_params.is_var_len               = true;

    add_char_params.read_access       = SEC_OPEN;
    add_char_params.write_access      = SEC_OPEN;
    add_char_params.cccd_write_access = SEC_OPEN;

    return characteristic_add(p_nus->service_handle, &add_char_params, &p_nus->tx_handles);
    /**@snippet [Adding proprietary characteristic to the SoftDevice] */
}


uint32_t ble_nus_data_send(ble_nus_t * p_nus,
                           uint8_t   * p_data,
                           uint16_t  * p_length,
                           uint16_t    conn_handle)
{
    ret_code_t                 err_code;
    ble_gatts_hvx_params_t     hvx_params;
    ble_nus_client_context_t * p_client;

    VERIFY_PARAM_NOT_NULL(p_nus);

    err_code = blcm_link_ctx_get(p_nus->p_link_ctx_storage, conn_handle, (void *) &p_client);
    VERIFY_SUCCESS(err_code);

    if ((conn_handle == BLE_CONN_HANDLE_INVALID) || (p_client == NULL))
    {
        return NRF_ERROR_NOT_FOUND;
    }

    if (!p_client->is_notification_enabled)
    {
        return NRF_ERROR_INVALID_STATE;
    }

    if (*p_length > BLE_NUS_MAX_DATA_LEN)
    {
        return NRF_ERROR_INVALID_PARAM;
    }

    memset(&hvx_params, 0, sizeof(hvx_params));

    hvx_params.handle = p_nus->tx_handles.value_handle;
    hvx_params.p_data = p_data;
    hvx_params.p_len  = p_length;
    hvx_params.type   = BLE_GATT_HVX_NOTIFICATION;

    return sd_ble_gatts_hvx(conn_handle, &hvx_params);
}


#endif // NRF_MODULE_ENABLED(BLE_NUS)

Regarding your question about how the application aware that the peer has read the characteristic. You can implement read with authorization. Please see here. You'll need to use is_defered_read when declare the characteristic. 

[RRWC]

Hello Hung Bui, thank you for your reply.

I am in fact using NRF Connect app to test. All tests reported above where performed using the NRF Connect. This makes it easier to identify if the problem is on the nRF52832 side or on our end user APP.

I performed a sniffer trace as requested. I'll walk through the normal behavior and the problem case described earlier using screenshots from the sniffer trace and from nRF Connect.

Normal Behavior

After the connection everything runs smoothly. The screenshots bellow show normal operation with parameters automatically negotiated between nRF52832 and a Samsung Galaxy S21 (same results with a Samsung Galaxy M51 and an Asus Zenfone Max pro M1)

Connection establishment and parameter negotiation

Below are screenshots of all parameters that have been automatically negotiated right after the connection was established.

[Slave] Connection parameter update request. Parameters accordingly to the desired parameters informed in the first post.

[Slave] Request data length change to 234 bytes

[Master] Reply data length update request

[Slave] Request MTU change to 230 bytes

[Master] Reply MTU update request

[Master] Data length update request. Not sure why the master decides to renegotiate data length, but I believe this is not related to the problem as everything continues to work normally after this.

[Slave] Request PHY change to 2 MB

[Master] 2 MB PHY accepted

[Slave] Reply data length update requested by the master

[Master] Reply parameter update request

[Slave] Parameter negotiation request. Not sure why it happens again here, but the parameters are set as desired.

[Master] Reply parameter negotiation

[Master] Connection parameters accepted

Data transmission with MTU 230 bytes

Shortly after the above negotiations ended I read some characteristics.

[Master] Read 7 byte characteristic

[Slave] Send 7 byte characteristic data:

[Master] Read 512 byte characteristic

[Slave] Send successfully 512 byte characteristic

nRF Connect side:

In these nRF Connect logs you can see almost all the steps shown from the sniffer side so far. Everything works.

Changing MTU to 23 bytes

Now a command is issued from nRF connect to change the MTU to 23 bytes. This is done using the "..." menu in the upper right corner. With this command, the master will request an MTU of 23 bytes.

Note that previously the slave was responsible for requesting the MTU change to 230 bytes. You said the MTU can only be changed once per connection, but I believe each side can request the change once per connection (at least it seems that way considering the behavior, I really don't remember exactly what the BLE spec says about it right now) . In fact, after requesting a new MTU using nRF Connect you will not be able to request it again on the same connection.

[Slave] Reply MTU request from master

[Master] New data Length request. This is not a command directly issued via nRF Connect. Probably the Android BLE stack decided that 27 bytes make smore sense with a 23 byte MTU.

[Slaves] Reply data length request

Reading characteristics with 23 bytes MTU and problem

After the above negotiation, characteristics a few bytes long can be read normally, but longer characteristics cannot.

[Master] Read 7 byte characteristic

[Slave] Successfully send 7 bytes characteristic data

[Master] Try 512 bytes characteristic read

[Slave] 512 bytes characteristic data is partially send. Data never displayed in master.

[Slave] Last data packet error detail

The connection remains active and it is even possible to read the data of the characteristics, although if there is too much data the error will be repeated.

Error in nRF Connect side

Below you can see the steps that led to the error in the nRF Connect log. After the first error, new readings are performed, with success in the case of short features and with error in the case of long features.

As far as I know the BLE stack should automatically split the data and send it even using the 23 byte MTU and 27 byte data length. However, for some reason, only characteristics containing only few bytes of data are being transferred. Can you help me understand if there is something not configured correctly or where is the problem?

Regarding the read with authorization question, currently the device is notified when the reading starts. However, using the above example, I have no information about the failure to deliver the data. Is there an proper callback to confirm that all data registered in the characteristic were successfully delivered?

Thank you in advance,

Ricardo