RE: nrfconnect app displays old services and characteristics evenafter reprogramming the board.

madblue — Thu, 29 Apr 2021 12:44:47 GMT

Hi,

sorry, forgot to update it here.

It is not happening now with the zephyr application.

thanks

RE: nrfconnect app displays old services and characteristics evenafter reprogramming the board.

Vidar Berg — Thu, 29 Apr 2021 12:19:59 GMT

Hi,

I've looked through the Zephyr Host API, but I couldn't find anything that was equivalent to the Peer manager function I pointed to earlier. Looks maybe "service changed" is handled automatically in the stack (in gatt.c). Are you still experiencing problems with caching?

RE: nrfconnect app displays old services and characteristics evenafter reprogramming the board.

madblue — Mon, 26 Apr 2021 14:37:28 GMT

Hi,

My new application is written using nrfconnect sdk.

How can i add this feature to my nrfconnect sdk based application? is there any api available to replace the " pm_local_database_has_changed() " ?

RE: nrfconnect app displays old services and characteristics evenafter reprogramming the board.

madblue — Thu, 22 Apr 2021 15:06:42 GMT

Thank you Vidar.

I will try that out later and get back to you.

RE: nrfconnect app displays old services and characteristics evenafter reprogramming the board.

Vidar Berg — Thu, 22 Apr 2021 14:02:15 GMT

Hi,

Having the Service changed characteristic present should be enough to disable caching for the devices that are not bonded. For bonded devices, however, you will need to send a service changed indication to make the client do a new service. You can use the pm_local_database_has_changed() function for this.

RE: nrfconnect app displays old services and characteristics evenafter reprogramming the board.

madblue — Thu, 22 Apr 2021 13:51:49 GMT

Hi,

Thanks for the quick reply.

It shows the actual services once i give the refresh service command from nrf connect app.

NRF_SDH_BLE_SERVICE_CHANGED was already set in the sdk_config file.

how can we force the service changed field from the server end ?

#ifndef NRF_SDH_BLE_SERVICE_CHANGED
#define NRF_SDH_BLE_SERVICE_CHANGED 1
#endif

Are you testing with Android or iOS?

I have both ios and android phones.

RE: nrfconnect app displays old services and characteristics evenafter reprogramming the board.

Vidar Berg — Thu, 22 Apr 2021 13:19:58 GMT

Hi,

[quote user=""]It shows actual services and chara in the phones that were not used to debug on that device previously with my application code. i have tried erasing all the app data, pairing information and also given a network settings reset but does not work.[/quote]

This should normally clear the attribute cache and force a new service discovery on subsuquent connection. Strange that it's not working. Are you testing with Android or iOS? The android version of nRF connect has a button you can press to manually start service discovery.

You may try to enable the 'NRF_SDH_BLE_SERVICE_CHANGED' setting in sdk_config.h. This will prevent caching for un-bonded devices.

Excerpt from the core spec on attribute caching rules:

2.5.2 Attribute caching

Attribute caching is an optimization that allows the client to discover the
Attribute information such as Attribute Handles used by the server once and
use the same Attribute information across reconnections without rediscovery. If
the client does not cache the Attribute information, then it must rediscover the
Attribute information at each reconnection. With caching, time is saved and a
significant number of packets need not be exchanged between the client and
server. The Attribute information that shall be cached by a client is the Attribute
Handles of all server attributes and the GATT service characteristics values.

Attribute Handles used by the server should not change over time. This means
that once an Attribute Handle is discovered by a client the Attribute Handle for
that Attribute should not be changed.

Some circumstances may cause servers to change the Attribute Handles used
for services, perhaps due to a factory reset or a firmware upgrade procedure
being performed. The following is only required on the server if the services on
the server can be added, modified or removed. If GATT based services on the
server cannot be changed during the usable lifetime of the device, the Service
Changed characteristic shall not exist on the server and the client does not
need to ever perform service discovery after the initial service discovery for that
server.

To support caching when a server supports changes in GATT based services,
an indication is sent by the server to clients when a service is added, removed,
or modified on the server. A client may also detect a service change by reading
the Database Hash characteristic if that characteristic exists on the server. A
GATT based service is considered modified if the binding of the Attribute
Handles to the associated Attributes grouped within a service definition are
changed. Any change to the GATT service definition characteristic values other
than the Service Changed characteristic value and the Client Supported
Features characteristic value themselves shall also be considered a
modification.

For clients that have a trusted relationship (i.e. bond) with the server, the
attribute cache is valid across connections. For clients with a trusted
relationship and not in a connection when a service change occurs, the server
shall send an indication when the client reconnects to the server (see Section
7.1). For clients that do not have a trusted relationship with the server and that
do not support reading the Database Hash characteristic, the attribute cache is
valid only during the connection. Clients without a trusted relationship that do
support reading the Database Hash characteristic may validate the attribute
cache on connection setup. Clients without a trusted relationship shall receive
an indication when the service change occurs only during the current
connection.

Note: Clients without a trusted relationship that support caching must either
perform service discovery or detect service changes by reading the Database
Hash characteristic on each connection if the server supports the Service
Changed characteristic.

The server shall send an ATT_HANDLE_VALUE_IND PDU containing the
range of affected Attribute Handles that shall be considered invalid in the
client’s attribute cache. The start Attribute Handle shall be the start Attribute
Handle of the service definition containing the change and the end Attribute
Handle shall be the last Attribute Handle of the service definition containing the
change. The value in the indication is composed of two 16-bit Attribute Handles
concatenated to indicate the affected Attribute Handle range.
Note: A server may set the affected Attribute Handle range to 0x0001 to
0xFFFF to indicate to the client to rediscover the entire set of Attribute Handles
on the server.

If the Database Hash characteristic exists on the server then, each time a
service change occurs, the server shall update the Database Hash
characteristic value with the new Database Hash (see Section 7.3).
If the Database Hash characteristic value has changed since the last time it
was read, the client shall consider its attribute cache invalid and shall not make
use of the cached information until it has performed service discovery or
obtained the changed database definitions using an out-of-band mechanism

The client, upon receiving an ATT_HANDLE_VALUE_IND PDU containing the
range of affected Attribute Handles, shall consider the attribute cache invalid
over the affected Attribute Handle range. Any outstanding request transaction
shall be considered invalid if the Attribute Handle is contained within the
affected Attribute Handle range. The client must perform service discovery
before the client uses any service that has an attribute within the affected
Attribute Handle range. Alternatively, the client may read the Database Hash
characteristic and obtain the changed database definitions using an out-ofband
mechanism. If the client receives an ATT_HANDLE_VALUE_IND PDU
during service discovery and the client has read the Database Hash
characteristic prior to the service discovery, the client may read the Database
Hash characteristic again to determine if the current service discovery can be
continued or if a new service discovery is required.

Once the server has received the ATT_HANDLE_VALUE_CFM PDU, the
server can consider the client to be aware of the updated Attribute Handles.
The client shall consider the affected Attribute Handle range to be invalid in its
attribute cache and perform the discovery procedures to restore the attribute
cache. The server