Error 0x3401 on sending advertising packets

[KasemC]

Hello,

I am currently working on project that uses BLE peripheral and BLE central for automatic sensor calibration on custom board. There is an initial connection where both central and peripheral connect and successfully communicate data on notification characteristic from BLE peripheral to BLE central. Then they disconnect and peripheral stops advertising for some time. Peripheral reinitialises the advertising packet data.

I start advertising on the peripheral again and I initiate a second connection between the BLE central and BLE peripheral. However, this time the peripheral when sending data on the notification characterisitic displays an error of 0x3401 which corresponds to NRF_ERROR_STK_BASE_NUM, NRF_GATTS_ERR_BASE, BLE_ERROR_NOT_ENABLED. BLE central can still send data successfully on the write characteristic. So it's not a connection problem.

Why would this error occur upon connecting on second time?

[endnode]

Should be pretty easy with the proper documentation:

• If you are using S130 V2 as per your tag and you get 0x3401 return code when calling sd_ble_gatts_hvx function (or actually any other) then it means BLE_ERROR_GATTS_SYS_ATTR_MISSING.
• According to further text in Nordic documentation it seems that you haven't issued sd_ble_gatts_sys_attr_set function which seems to be mandatory for every connection link where you run GATT Server and it is with previously bonded device.
• However it might also be caused by not enable Notifications on this particular GATT Server-Client connection (have in mind that these Server-Client things are completely independent so enabling Notify methods through writing to CCCD on one connection handle has no effect on any other). Are you sure that you are treating paired/bonded devices and GATT Server-Client contexts properly?

[KasemC]

Thanks endnode!

I have debugged the problem to find that the problem was caused by not enabling the Notifications using the BLE central upon the second connection. This originated from the fact, that during service discovery, the discovered service type doesnt match the pressure service uuid type, thus failing to issue a Discovery Complete event where the notification is enabled.