BLE peripheral - failed connection from central - ble event 0x3a

[Nick_RA]

My app is based on ble_app_uart, with my own custom service replacing NUS. Right now it's not doing much except printing a hex string of the written value (16 bytes)

I'm trying to debug a failed connection from an Android app - basically the app is just trying to write to a couple of characteristics. The strange thing is I can write using nRF Connect no problem at all.

Anyway, to debug I'm printing the BLE event codes during on_connect on_write on_ble_event handlers  etc. Most of these I can decode except I get a event 0x3A which I can't find - apart from the general Bluetooth codes as BLE_HCI_CONTROLLER_BUSY.

Is this the correct meaning? If so, what could cause the message?

[Hung Bui]

Hi Nick, 

The BLE event 0x3A is BLE_GATTC_EVT_EXCHANGE_MTU_RSP. You can have a look here. It's the result of the ATT MTU exchange. 

But I don't think it would have anything to do with the disconnection of the connection. 
When testing with the phone, please make sure you disable and enable Bluetooth everytime you change the attribute table (change UUID for example). On many phone the ATT table will be cached and not updated if you don't have service changed indication. 

[Nick_RA]

OK thanks, that narrows it down a little bit.

Can you speculate any reason why nRF Connect can read/write OK but the app cannot? The app is written in React Native and uses device.writeCharacteristicWithResponseForService()

(The app works fine, there is another implementation of this service which uses Laird modules written in SmartBASIC which works no problem.)

This is the output from debug:

on ble event 0x10
on_connect
Connected
on ble event 0x3a
on ble event 0x12
on ble event 0x12
on ble event 0x11
Disconnected
on ble event 0x26
on ble event 0x10

[Hung Bui]

I'm not so sure what could be wrong as I have little experience with React Native and Android application development. 
But have you checked if the service discovery worked fine ? 
Make sure the UUID was correct. 

You may want to try capture a sniffer trace. Then you can compare what happens when using nRF Connect app compare to your app. 

[Nick_RA]

Sniffer doesn't work but I can do a HCI snoop on the phone which gets a LOT of packets to wade through...

I have a cpl of other questions though just to eliminate some things:

1. If I run DIS as well as my service, do I need to increase the number of services on sdkconfig.h?

2. I am not using notification, just read/write, so do I need to do anything with cccd?

From example ble_app_uart:

I don't really get this part of ble_nus.c lines 69-115

    /* Check the hosts CCCD value to inform of readiness to send data using the RX characteristic */
    .
    .
    .
            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);
        

Especially as there is no provision for event type BLE_NUS_EVT_COMM_STARTED in the data handler in main.c. Am I missing something here?

[Hung Bui]

Hi Nick, 

The code at line 69-115 will notify the application (with the event value BLE_NUS_EVT_COMM_STARTED) that the CCCD has been enabled when it's connected. So that the application can start sending notification.
Normally CCCD would be enabled with a write command, but if the peers store the value of the CCCD from last connection with the same peer it can enable right after the connection. This is why we check the CCCD at 2 locations, in on_connect() and in on_write. 

If you don't do notification you would need to remove the CCCD characteristic. 

Nick_RA said:

1. If I run DIS as well as my service, do I need to increase the number of services on sdkconfig.h?

Could you give which configuration you are looking at ? DIS is not a vendor specific, so you don't need to increase NRF_SDH_BLE_VS_UUID_COUNT. You may need to increase NRF_SDH_BLE_GATTS_ATTR_TAB_SIZE but if the softdevice doesn't complain, you are fine. 

Please let us know which issue you have when setting up the sniffer. 

[Nick_RA]

OK thanks re the config etc - I thought that was the case but just wanted to double check.

Actually I finally got it working, and I'm kicking myself. I've set the characteristics up as 16 bit UUIDs using the SIG base UUID which works fine. What I had overlooked was that the service UUID was composed in the same fashion in that it is a 16 bit service UUID embedded in the 128bit base UUID and two octets were uninitialised - I'd assumed it was a straight 128 bit number. Serves me right I guess for just looking at the number rather than checking all the bytes.

So adding the 16 bit UUID using the correct 2 octets made it magically work

BTW the sniffer only showed up AD packets, presumably as the connection is encrypted.