Client without Notifications bricking device

[Adam Gerken]

Hey everyone, I have a device that's in production and everything is working great, however we have a customer that is creating their own software to interface with our sensor and they bricked a couple units because they did not turn notifications on. This causes the unit to seemingly  wait indefinitely waiting to get the thumbs up from the client that it received the packet, which never comes. We don't expect the unit to work without notifications on, but I don't want it to lock up like this... we have no hardware reset capability so the units are junk now.

I figure there has to be an event for a time out or the like that I could use to force a disconnect and start advertising again, I just can't seem to find it. I've tied BLE_GATTC_EVT_TIMEOUT, BLE_GATTS_EVT_TIMEOUT, and BLE_GAP_EVT_TIMEOUT. None of these seem to be triggered by the sensor not being able to send a packet.

Any thoughts?

Thanks,

Adam

[Edvin]

Hello,

What do you mean by "bricking device"? 

 

This causes the unit to seemingly  wait indefinitely waiting to get the thumbs up from the client that it received the packet, which never comes.

 What device is waiting? Central or peripheral? And is this "thumbs up" supposed to be delivered via a notification, perhaps?

Have you/they tried to debug the "bricked device" while this is happening? Does the log say anything?

My suspicion is that the device is trying to send a notification, but this isn't possible since it isn't enabled by the central(client). But you/they would need to debug to see why the thumbs up is not working. Remember that we don't know anything about the logic in your application.

Best regards,

Edvin

[Adam Gerken]

This is a production device that a customer is having this issue with when trying to integrate into their software ecosystem, no debug available. Like I said, there's no hardware reset, and the device disappears.

"My suspicion is that the device is trying to send a notification, but this isn't possible since it isn't enabled by the central(client)."

Yes, exactly what's happening. I need to detect when this happens, and instead of sitting there waiting forever, I need to disconnect and advertise. I just can't find the notification that says the client hasn't responded or whatever to trigger the disconnect and advertise.

[Edvin]

Oh, I see. Well. There is no event for something that never occurs in this case, unfortunately. Since it isn't mandatory to enable notifications, there will be no timeout from the SoftDevice.

I suggest that you try to add an app_timer to the device that you start in the connected event. If the connected device enables notifications on this characteristic, stop the timer, but if the timer times out, you would disconnect from the connected device, and it should start advertising again.

Does that seem like a viable solution?

BR,

Edvin

[Adam Gerken]

Seems like a reasonable idea. How would I see if the connected device enables notifications? I could also just check when the client requests that I send data (part of our application) and just deny the request if they don't have notifications enabled.

[Edvin]

Looking at the ble_app_uart example, the BLE_GATTS_EVT_WRITE event in ble_nus.c is triggered whenever someone write something to a characteristic, including the CCCD (for enabling notifications). In SDK16, it looks like this:

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))
    {
    ...

The last if-check in this snippet checks whether this event is caused by a notification change. If the value is 0x0001 then notifications are enabled.

You can do this with a central that enables notifications to see what it looks like.