Where is the function which sets the cccd?

[Mitch996]

Hello, I'm using an android device to set cccd, it worked when I was running the project on nrf514xx @s110, it no longer does on nrf52840 S140, so now I wanna make sure the program actually dont skip the part that sets the cccd.

So where in the library API can I find it? Which switch case? Which API function? I imagine it is a part of a gatt call back somewhere, but I can't quite tell where.

I hope it's not deeply hidden in the SD and it's impossible to locate.

Also, the other question I asked here can provide some more background:

devzone.nordicsemi.com/.../

[endnode]

Hi Mitch, how you describe it this seems to be more Android problem. What radio sniffer trace says? Is android phone really writing proper 16-bit value to CCCD handle? Is it using Write Request not Write Command (which seems to be forbidden by BT SIG spec for writing to CCCD and so Nordic enforces it in their latest soft devices (see this Q&A thread for more))?

Otherwise when it comes to S140 API you should wait for BLE_GATTS_EVT_WRITE and filter it by target handle and value and act accordingly.

[Mitch996]

Hello endnode, thank you so much for you reply! :)

What radio sniffer trace says? Is android phone really writing proper 16-bit value to CCCD handle?

I haven't sniffed it yet, I'm lazy, but it worked perfectly on nrf51422 S110, so I believe there is sufficient reason to believe that yes, it does, unless of course the 16-bit value also changed in the latest specs.

Is it using Write Request not Write Command

That, to be honest, I'm completely not sure. I haven't even heard of that switch-case before. Can you tell me what are "BLE_GATT_OP_WRITE_REQ" and "BLE_GATT_OP_WRITE_CMD"? Are they branches inside a event handler callback of some sort? And I must enter the right branch to call the right function in order enable CCCD? That would be really odd! Because I remembered quite clearly that in S110, you don't have to call a function to enable cccd, the SD handles everything?

[Mitch996]

I'm out of characters, so last but not least:

Otherwise when it comes to S140 API you should wait for BLE_GATTS_EVT_WRITE

You mean it works like this:

Android App fires a cccd write -> triggers my BLE_GATTS_EVT_WRITE branch -> me filter the incoming data according to handle and value etc. -> enters my designated, hand written, self-made cccd enable branch?

That would be again, quite weird, because I don't remember ever written such a branch that specifically enables cccd, I always though it gets handled by SD? Also, wouldn't that defeats the very purpose of getting a request from android device/client in order to enable notification? I mean what stops me from calling such a function arbitrarily as I please, with or without the android request?

So suppose I need to call a function to enable cccd, AFTER I received the android request, what function should I call? static void notif_enable(client_t * p_client)?

[endnode]

Yes, this is how it works and always worked. You cannot "enable CCCD" from GATT Server side any time you want, it MUST be enabled from GATT Client. It is written in BT SIG specification and hasn't changed since v4.0:) So if you would try to send HVX on S110 (whatever legacy version) you would anyway get error code back from SD if CCCDs are not allowed yet. Now if you have looked for this Write to CCCD handle and enabling Notifications in your app or you just played Russian roulette by fired HVX and got lucky I don't know. One important point: if you use BT SIG Security Manager (layer) and bonding (mechanism) then GATT Server is obliged to keep CCCD state over disconnection so theoretically if your phone bonded and enabled CCCD once it was never needed to keep track of CCCD, it will be always the same (Notifications enabled).

[endnode]

One more note to this new change in SD behavior: previously any of GATT Write methods work (yes, there are more types of various (G)ATT Methods defined in BT SIG specification, read that or some training, it's useful;) to change value of 16-bit CCCD handle. If it wasn't protected for unauthenticated Writes etc. And you always got event callback to your application's SD event handler (like many others GATT events when they happen in SD). However now SD ignores Write CMD to CCCD and doesn't (logically) notify application, only Write Request will cause that. This can again easily explain what you see (and that's why laziness of not getting RF trace prevents you to solve it for couple of days;).