Problem communication between BLE_APP_UART_C and BLE_APP_UART (TX notifications are not always enabled)

[Andrew_Engineer]

Hello Nordic Guys,

 

 

 

We are working on the system based on BLE_APP_UART_C (central) and BLE_APP_UART (peripheral).

“Central” is always “ON” and scanning for the peripherals.

“Peripheral” wakes up every 5 minutes, connects to the “Central”, sends data, and going back to sleep.

 

System works perfectly when “peripheral” were based on SDK 11 S132 Version 2, now we are migrating to SDK14.0 S132 V5, and experiencing some challenges. (In both cases “Central was always build on SDK14 SD 132 V5)

 

What we are noticing is bellow:

 

1. “Central” is connected to the “peripheral”
2. “Central” is enabling tx notifications by calling function: ble_nus_c_tx_notif_enable(..)

 

On the “peripheral” side we seeing follow behavior:

 

1. “Peripheral” is connected to the “Central”           GAP_EVT_CONNECTED
2. Exchange MTU response event ie “Central” and “Peripheral” is trying to negotiate data package size                                       BLE_GATTC_EVT_EXCHANGE_MTU_RSP
3. BLE_GATTS_EVT_WRITE with event ID 80 and length 20, we are assuming this is a point where “Central” is enabling Notifications on “Peripheral”.

 

What we are experiencing: it seems like Notifications is not always enabling on the “Peripheral” side ie if we try to send message from the “Central” to the ”Peripheral” it is going to be delivered.

 

In “good” case scenario after receiving BLE_GATTS_EVT_WRITE we are getting BLE_NUS_EVT_COMM_STARTED, but in “bad” case scenario we are not getting anything and after roughly 10-12 seconds we are getting: BLE_GAP_EVT_CONN_PARAM_UPDATE. But we still not able to communicate between “peripheral” and central. Once “peripheral” is disconnected from the “Central” on the next connection attempt system could communicate, but behavior is random.

 

Question: if there is way on the “Peripheral” side to make sure Tx notifications had been enabled?

 

What would be the word of advice how we can address this issue?

 

 

Thank you,

 

 

Andrew.

[Kenneth]

Hi,

On the central side there is BLE_NUS_C_EVT_DISCOVERY_COMPLETE event when the database (GATT server) on the peer side have been read. If the correct UUID is found during discovery, then the application will call ble_nus_c_tx_notif_enable() to write to the specific handle on the peer to enable notification. This is done by calling sd_ble_gattc_write() to enable notification. So the first thing to check is if this occurs with no errors on the central side.

On the peripheral side there is a BLE_GATTS_EVT_WRITE event when the peer write to a characteristic. Typically this event will be forwarded to each of the callbacks for the BLE modules that have setup the database. Each callback then check if the write was to a local handle in on_write(), and take some sort of action if the write was to a characteristics handle the specific BLE module setup during init. This means that the BLE module should buffer the handle it receives when init the database, and compare with the BLE_GATTS_EVT_WRITE handle. 

So you should check if on_write() is called as expected, that it is the right CCCD handle in p_nus->tx_handles.cccd_handle and that BLE_NUS_EVT_COMM_STARTED is set as expected as shown in on_write() below.

/**@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)
{
    ble_gatts_evt_write_t const * p_evt_write = &p_ble_evt->evt.gatts_evt.params.write;
    ble_nus_evt_t evt;
    evt.p_nus = p_nus;
    if (   (p_evt_write->handle == p_nus->tx_handles.cccd_handle)
        && (p_evt_write->len == 2))
    {
        if (ble_srv_is_notification_enabled(p_evt_write->data))
        {
            p_nus->is_notification_enabled = true;
            evt.type = BLE_NUS_EVT_COMM_STARTED;
        }
        else
        {
            p_nus->is_notification_enabled = false;
            evt.type = BLE_NUS_EVT_COMM_STOPPED;
        }
        p_nus->data_handler(&evt);
    }
    else if (   (p_evt_write->handle == p_nus->rx_handles.value_handle)
             && (p_nus->data_handler != NULL))
    {
        evt.params.rx_data.p_data = p_evt_write->data;
        evt.params.rx_data.length = p_evt_write->len;
        evt.type = BLE_NUS_EVT_RX_DATA;
        p_nus->data_handler(&evt);
    }
    else
    {
        // Do Nothing. This event is not relevant for this service.
    }
}

Best regards,
Kenneth

[Andrew_Engineer]

Hi Kenneth,

Thank you for detailed explanations. I have follow your instructions and here my results so far:

On the "Central" Side there are two functions called back to back, from the BLE_NUS_C_EVT_DISCOVERY_COMPLETE event :

err_code = ble_nus_c_handles_assign(...)

err_code = ble_nus_c_tx_notif_enable(...)

both of them returns NRF_SUCCESS.

I am assuming (for now) Central is "OK"

note: below I am using follow definition: good and bad scenario.

Good scenario means: TX notifications was successfully enabled on the "peripheral side", and "Peripheral" were able to communicate with "Central"

Bad scenario TX notifications was NOT enabled on the "peripheral"side, therefore communication between "Central" and "peripheral" is impossible 

on the "Peripheral" side I added debug printf inside on_write(...) function. I find out that: I am fail first 'if'-statement;

if ( (p_evt_write->handle == p_nus->tx_handles.cccd_handle)
&& (p_evt_write->len == 2))

in "good" and "bad" scenarios length is always equals '2'   (All numbers here and bellow are decimal)

in "good" and "bad" scenarios  p_nus->tx_handles.cccd_handle is always equals '16',

in good case p_evt_write->handle is equals '16', but in bad case p_evt_write->handle is equals 15.

Any word of advise how to address this?

Regards,

Andrew

[Kenneth]

This was strange.. Can you check if the handle written from the central is the same both when it fails and works?

[Andrew_Engineer]

Hi Kenneth,

Thank you for your reply.

How can I do that? if there is way to print the handle what is getting written on the central?

Thank you,

Andrew

[Kenneth]

On the central you should be able to output the handle by adding NRF_LOG_INFO() like this:

/**@brief Function for creating a message for writing to the CCCD. */
static uint32_t cccd_configure(uint16_t conn_handle, uint16_t cccd_handle, bool enable)
{
    uint8_t buf[BLE_CCCD_VALUE_LEN];

    buf[0] = enable ? BLE_GATT_HVX_NOTIFICATION : 0;
    buf[1] = 0;

    ble_gattc_write_params_t const write_params =
    {
        .write_op = BLE_GATT_OP_WRITE_REQ,
        .flags    = BLE_GATT_EXEC_WRITE_FLAG_PREPARED_WRITE,
        .handle   = cccd_handle,
        .offset   = 0,
        .len      = sizeof(buf),
        .p_value  = buf
    };

    NRF_LOG_INFO("Enable cccd_handle: %x", write_params.handle);
    return sd_ble_gattc_write(conn_handle, &write_params);
}

So then you will be able to identify if the wrong handle is used from the central side in the first place.

Btw, you should also update to S132v5.1 if you haven't already, this is done by programming the S132v5.1 softdevice, replace the softdevice header files in your project, and re-compile the application.