Notify client of updated Gatt database

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
MikeAustin
Level 4
Level 4
25 replies posted 25 sign-ins 10 replies posted

I'm currently playing around with OTA functionality on one of our products.  I'm doing a bit of my testing using LightBlue, and I'm having issues with LightBlue not updating the services it can "see" when my peripheral changes from Bootloadable to Bootloader, or vice versa.

The only way I can get LightBlue to show the correct services is to go into the Bluetooth settings on my smartphone and "forget" the connection with my peripheral.  I then have to go through a new pairing operation, and everything is ok again.

I'm not 100% sure what's going on, but its like LightBlue either isn't receiving any notification to say the GATT database has changed, and to hence discover the applicable services, or I'm not telling LightBlue that it needs to do this.

I followed the Fixed Stack OTA examples, and there doesn't appear to be anywhere in those code examples where they are explicitly telling the client that the database has changed.

Can anyone help me out?

Cheers,

Mike

0 Likes
1 Solution

Hello Mike,

The reason why you are facing this issue is the Client (in your case mobile) should be forced re-discover the server database when the new services are added or removed to the server.

On the server side it is required to send the notification or indication manually to the client and the client has to manually re-discover the database again. There is no need for pairing again. Only re-discovery process is sufficient.

As you mentioned the Generic Attribute Service (UUID 0x1801) and the Service Changed characteristic (UUID 0x2A05) shall exist in the GATT database for this purpose only. The server can manually trigger the notification or indication in its application with Service Changed characteristic.

In Fixed stack code example in bootloader project the firmware just enables the hidden services using the function call WriteAttrServChanged() in the beginning of the main loop. So the Client connects to the Bootloader app and then automatically discovers after connection.

For your present scenario, when the application switches from Bootloader to Bootloadable (or vice versa) the device goes to reset. So I would like to say that when the application to Bootloader the connection will be disconnected and the lightblue is expected to connect again.

Hope this explanation helps.

Thanks

Ganesh

View solution in original post

0 Likes
4 Replies
MikeAustin
Level 4
Level 4
25 replies posted 25 sign-ins 10 replies posted

So I've done a bit more digging on this, and it seems its an issue associated with the Client caching the Attribute Handles.  This is made worse when you pair and bond (as you need to do with an OTA connection).

From what I've read, the Bluetooth specification requires that, if the GATT based services can change in the lifetime of the device, then the Generic Attribute Service (UUID 0x1801) and the Service Changed characteristic (UUID 0x2A05) shall exist in the GATT database.  Strangely, I have both of these enabled in my GATT database, and yet its still not telling the Client to rediscover the Services when it goes from the Bootloadable code to the Bootloader code, or vice-versa.

How does this get accomplished in the real world?  Is it that devices don't disable Services between Bootloader and Bootloadable modes?  Or is there someway to force a "Rediscover Services" on the Client side from the Server side even when the two are paired and bonded?

Cheers,

Mike

0 Likes

Its awfully quiet in here!  Would be great if someone with more experience in this stuff than I have could chime in with a bit of assistance.

{cue sound of crickets}

Cheers,

Mike

0 Likes

Hello Mike,

The reason why you are facing this issue is the Client (in your case mobile) should be forced re-discover the server database when the new services are added or removed to the server.

On the server side it is required to send the notification or indication manually to the client and the client has to manually re-discover the database again. There is no need for pairing again. Only re-discovery process is sufficient.

As you mentioned the Generic Attribute Service (UUID 0x1801) and the Service Changed characteristic (UUID 0x2A05) shall exist in the GATT database for this purpose only. The server can manually trigger the notification or indication in its application with Service Changed characteristic.

In Fixed stack code example in bootloader project the firmware just enables the hidden services using the function call WriteAttrServChanged() in the beginning of the main loop. So the Client connects to the Bootloader app and then automatically discovers after connection.

For your present scenario, when the application switches from Bootloader to Bootloadable (or vice versa) the device goes to reset. So I would like to say that when the application to Bootloader the connection will be disconnected and the lightblue is expected to connect again.

Hope this explanation helps.

Thanks

Ganesh

0 Likes

Hi Ganesh,

Thanks for your explanation.  I now understand what is going on, but what I want to be able to do is tell the Client that I have added and removed various services and so it should go and rediscover everything that is being advertised and forget everything that isn't.

The WriteAttrServChanged() function appears to be restricting the list of services that the Client needs to rediscover to just the Bootloader service by setting value as follows:

/* Force client to rediscover services in range of bootloader service */
value = ((uint32)(((uint32) cyBle_btss.btServiceHandle) << 16u)) |
((uint32) (cyBle_btss.btServiceInfo[0u].btServiceCharDescriptors[0u]));

I don't really understand what its doing here.  Ideally, I want to set "value" to something that would tell the Client to rediscover all available services, but I'm not sure what value I need to set "value" to.

Looking at the example above, it appears (but I'm not sure) that the starting attribute handle is the top 16 bits and the ending attribute handle is the bottom 16 bits.  Is that how its constructed?

Cheers,

Mike

 

0 Likes