Skip navigation
Home > All Places > WICED Smart Bluetooth > WICED Smart Bluetooth Forums > Blog > 2016 > June

The beginning of every GATT database (GATTDB) within the SDK begins the comment:


      // Service change characteristic is optional and is not present


What is the service change characteristic? Why would I want it? And how would I implement it?



     When a GATT client and server connect for the very first time, the client knows nothing about the server. In order to achieve a useful relationship, the client performs a GATT discovery on the server. There are a few variations in how the client can choose to go about this--search by handle, by type, etc.--we won't delve into the specifics of discovery.

     With low power in mind, these GATT discoveries are costly. Given that the client has the resources, it is far more efficient to jot down the details of the server's GATTDB and store that locally--this is called an Attribute Cache. In order to save power, upon future reconnections, the client will not perform a GATT discovery, but rather reach into its local memory to save power on both the client and server devices.

     However, a problem arises when we change the GATTDB between connections. The client will think the servers GATTDB is of the old form and begin operating on that basis. Now, this will only happen in the field under the premise that your firmware alters the GATTDB between connections.

     How do we fix this? One way is to utilize the Service Changed Characteristic. This characteristic is essentially a way for the server to indicate to the client that a change has been made to its GATTDB. The client should then update its Attribute Cache with the newest values.




This is how you would implement it in your GATTDB:



     const UINT8 gatt_database[]=


          // Handle 0x01: GATT service



          // Indicate that entire GATTDB has been altered

          // (handles: 0x0000 - 0xffff)

          CHARACTERISTIC_UUID16(0x0002, 0x0003,



               LEGATTDB_PERM_NONE, 4),

               0x00, 0x00, 0xff, 0xff,





               0x00, 0x00,




     This characteristic is implemented under the GATT Service that is mandatory to all GATTDB's. The Service Change Characteristic has a spec defined UUID. It needs only the ability to indicate and should have no required permissions. Lastly, it needs a value length of 4 bytes. These 4 bytes are used to designate the range of handles which have been changed. The first 2 bytes are the start handle, the last 2 bytes are the stop handle. As can be seen in the code above, we have specified this range to be all handles 0x0000 - 0xffff--tlling the client to completely rediscover the GATTDB.

     Since we need to use indications, this characteristic now needs a Client Configuration Descriptor--as all server initiated communications need. This descriptor is, essentially, two client-writable bytes that allow the client to give the server permission to transmit asynchronous communications--one byte is for notifications and the other is for indications. The service changed characteristic requires the use of indications (a notification with an application level ACK).



     The actual use of the Service Changed Characteristic requires the implementation of indications, GATT discovery by the client, and a change in the GATTDB by the server. These will not be covered here, but there exist individual resources for each:


     For implementation of indications see:



     For example firmware of a GATT change see:

          Re: How to change the GATT database after init (bleapp_set_cfg) ?

     For implementation of GATT discovery see:



This is a troubleshoot guide that deals with issues on BLE devices 20737(TAG4) and WICED Sense using WICED Smart hello_client.


<1. Problems pairing with mobile device in hello_client>


In order to pair with mobile devices with the hello_client app, you will need to add the following code after blecen_Create();



On your mobile device, enable bluetooth and select hello_client in the device selection.


Note that if the device has already been paired with hello_client before and your TAG board has been re-downloaded, you will have to erase the device in order to pair again.


     - In iOS, go to Settings -> Bluetooth -> My Devices -> select information on Hello Client device, and it will give you the option to "Forget This Device."


     - Similarly in Android, go to Settings -> Bluetooth -> Paired Devices -> Select Settings on Hello Client, and you can choose to "Forget."


You will now be able to pair with your mobile device, and you should see the following screen(using LightBlue on iOS here) on your device and traces on your WICED Smart IDE.


<iOS LightBlue Pairing>

IMG_0043.jpg  IMG_0044.jpg  IMG_0045.jpg


<Trace Result Screen>

13:06:32 - Store Bonded Info 0

13:06:32 - NVRAM write status = 120 , bond info block.

13:06:32 - GetBondedInfoIdx returns 0 meaning no bonded info

13:06:33 - encryption changed: 00




13:06:33 - Store Bonded Info 0

13:06:33 - NVRAM write status = 120 , bond info block.

13:06:33 - lesmpkeys_init.

13:06:33 - VSRead returns 0038 bytes

13:06:33 -

13:06:33 -

13:06:33 - Get Keys

13:06:33 - 070000000100000045b5fd0309b9691e

13:06:33 - 080860f0e44060f2582d41bf48b96a0c

13:06:33 - 50b96d0e5d2567f04dd541911efc4028

13:06:33 - 71f432f559d54196

13:06:33 -

13:06:33 - loadIRK:

13:06:33 -

13:06:33 - Got 5 irks.

13:06:33 - addr Type: 0

13:06:33 - addr :

13:06:33 - 303e14dd815b

13:06:33 - irk :

13:06:33 - d37f6eb437c08d82e7b5b9b59c68ac4b

13:06:33 - addr Type: 0

13:06:33 - addr :

13:06:33 - 303e14dd815b

13:06:33 - irk :

13:06:33 - d37f6eb437c08d82e7b5b9b59c68ac4b

13:06:33 - addr Type: 0

13:06:33 - addr :

13:06:33 - 303e14dd815b

13:06:33 - irk :

13:06:33 - d37f6eb437c08d82e7b5b9b59c68ac4b

13:06:33 - addr Type: 0

13:06:33 - addr :

13:06:33 - 303e14dd815b

13:06:33 - irk :

13:06:33 - d37f6eb437c08d82e7b5b9b59c68ac4b

13:06:33 - addr Type: 0

13:06:33 - addr :

13:06:33 - 303e14dd815b

13:06:33 - irk :

13:06:33 - d37f6eb437c08d82e7b5b9b59c68ac4b



<2. Can connect with some devices but having problems with multiple hosts>

You will need to include the smp_multi_key.a patch for pairing with multiple hosts. Otherwise multiple keys would get messed up in the storage. This patch also allows you to loop over the max number of devices, which is set to 5 by default. Using this patch the 6th device connected would take the key storage space of the first device, the 7th device the 2nd, and so on so forth. On the second loop the 11th device would be stored in the 6th device key storage entry.


To do this, open the in WICED-Smart-SDK/Apps/hello_client/ and add the following line.

APP_PATCHES_AND_LIBS += smp_multi_key_storage.a


One thing to be careful of is once the key storage is taken over for an older device, you will have to "forget" hello_client on your mobile device, otherwise it will not be able to bond. Once you forget hello_client from your device, you can pair with hello_client again and the key will be stored in a new spot, recognized as a new device.


Please download the new patch available (attached) and rename it to smp_multi_key_storage.a and replace the old version in WICED-Smart-SDK\Wiced-Smart\tier2\brcm\libraries\lib\20736\ or \20737. With the older version of the patch that is included in the SDK, it has a bug that memory gets corrupted and there is data loss of bonded devices after two loops of the bonding table (10 entries with the max number of devices as 5)


The new patch also has an added API that lets you change the maximum number of devices in the bonding table.

// To setup the max number of bonded devices .

void lesmpkeys_set_maxNumOfBondedDevice(UINT8 num);




<3. Running into memory issues on multiple devices>


This stems from insufficient memory allocated to the bonding table if you are using part of the NVRAM area for custom storage. You can solve this in the following two ways.


  1. Change the max number of devices to a lower number (see above) and see if the next device successfully loops through the bonding table and gets stored correctly.
  2. If you do not want to change the max number of devices, you need to allocate more space for the bonding table. Change the Platforms/BCM92073*TAG_Q32/2073*_EEPROM.btp file as needed. This is an example for allowing enough space for 5 keys when storing custom parameters in NVRAM area.
    • DLConfigVSLength to 2048
    • ConfigDSLocation to 2432

This should give the key storage section enough space to accommodate 5 keys.



<4. Issues with OTA after changing memory map as in 3. b>


If you decide to take the 3. b route, you will have to change parameters for OTA, otherwise the memory map will not match when you try a firmware upgrade.


The default layout for EEPROM and Serial flash is in WICED-Smart-SDK\Apps\ota_firmware_upgrade\ws_upgrade.c. When you move dynamic section (DS) in the .btp file, you have to update ws_upgrade.c, and change the corresponding values in nv_loc_len[].



Filter Blog

By date:
By tag: