Are there any way I can set CCCD (0x2902) value on BLE server (BlueNRG-MS) 7.2c?

[RStep.15]

It looks like BlueNRG-MS doesn't remember that BLE client asked it to change CCCD from 0 (default value) to 1 (subscribe to value change notifications) upon BLE server reboot. And I need to restore CCCD to 1 because BLE client doesn't do it on reconnect.

More details in this topic: https://social.msdn.microsoft.com/Forums/ru-RU/617c16ea-37d6-43c6-bab8-f925642ef1db/ble-hid-hid-over-gatt-device-status-reports-are-not-received-after-device-reconnected?forum=wdk&prof=required

btw: I am aware that this value must be set by BLE client, but what should I do if it doesn't do it?

[Pavel A.]

Are you sure that the server (device) can set a CCCD (client-side) flag on its own? Isn't this against the BLE standard?

IIRC it is the client's responsibility to set this flag if it wants to receive notifications (but I'm not expert and can be wrong).

-- Pavel A,

[RStep.15]

Pavel,

please have a look at the link in the initial post. The problem is that Windows does not set CCCD on device reconnect, it assumes that device stores CCCD value in persistent memory and uses this value on each new connection to paired Windows host.

Af far as I can see BlueNRG-MS does not always reuse stored CCCD value, in fact I have no idea how it works at all. Sometimes notifications work on device reconnect, sometimes not. This is something totally out of my control and I wish I had more ways to make sure it works as expected.

[Pavel A.]

This is exactly what I mean. If Windows (the client) does not set the client flag, this is a bug in Windows. Apple usually does the right thing. And the BLE module does not provide API for this because this makes no sense. This flag is meant to be volatile, and default state is OFF.

Again, I can be wrong; better ask on Stack Overflow or other reputable vendor-independent forum.

-- pa

[RStep.15]

Pavel,

Since Windows is a target platform for me I need some kind of workaround for its behavior. I talked to Windows Bluetooth developers and they believe that their approach is correct so I am not sure it's possible to make it any different. I just need to have my device working so any solution is okay to me.

[Pavel A.]

Yeah, I've seen your correspondence with the MS guy. Have you provided him the info he wanted? Let them sort out the issue with ST.

Unfortunately this will take time and won't help your immediate need. Does your company have a field support engineer (FAE) assigned? If not, call ST support and try to get one (or even ask Frank G. to help with this).

-- pa

[RStep.15]

I sent him what he asked, he didn't reply yet so I think it may take time. We didn't buy tons of ICs from ST so I really don't think they will assign FAE...

[RStep.15]

I read BLUETOOTH SPECIFICATION Version 5.0 | Vol 3, Part G, it clearly states that Client Characteristic Configuration descriptor value shall be persistent across connections for bonded devices (3.3.3.3 Client Characteristic Configuration, page 2238). So, in this case, Microsoft guys are absolutely right and BlueNRG-MS firmware has to either store this value internally or allow an external microcontroller to restore it upon device power cycle.

[Pavel A.]

My bad. This was in the spec even since v 4.0.

So... MS guys are right - but not absolutely. Only relatively.

Apple is right absolutely.

-- pa

[RStep.15]

I like Apple approach too because it simply works, always. However MS guys have strong arguments, here is a quote from MS engineer email:

"Just for a bit of background, the reason Windows won’t set the CCCD to enable notifications upon every connection is mainly in order to lower the latency between a successful connection and being able to process the first notifications from HID peripherals. Although an OTA write does not block incoming notifications by itself, it does add to the latency that is very important for devices such as keyboards that need to start sending keys as soon as a connection completes. Aside from that, having this OTA write on every connection for a few peripherals that rely on quickly connecting, sending notifications, and disconnecting causes all sorts of problems."

I don't know what problems it can cause but I realize that Windows has to deal with tons of different hardware and some of it may really have tons of problems, like I have...