• State Verified Answer
  • Locked Locked
  • Replies 3 replies
  • Subscribers 88 subscribers
  • Views 1021 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 271613
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

How is the local database change detected when PM_EVT_LOCAL_DB_CACHE_APPLY_FAILED is emitted?

Visti Andresen

While debugging an issue where a bonded Android app didn't handle characteristics that were moved and deleted correctly,
I noticed that the peer manager can detect if the configuration has changed.
(The issue was caused by some too aggressive caching in the app)

While the peer manager correctly detected the change I stared wondering how it does so?

Surely it doesn't store the entire UUID->handle mapping per bonded peer,
as it would take up too much flash space even if it would make detecting moved characteristics trivial.

I started look though the source code and quickly ended up at:
SVCALL(SD_BLE_GATTS_SYS_ATTR_SET, uint32_t, sd_ble_gatts_sys_attr_set(uint16_t conn_handle, uint8_t const *p_sys_attr_data, uint16_t len, uint32_t flags));
which gatts_cache_manager.c uses to "determine" if the database is still valid.

Being a SD call it is hard to debug, but the comments gave a hint
"The format of the data is described in @ref BLE_GATTS_SYS_ATTRS_FORMAT"
I was however unable to locate any file containing this format information.

The reason why I'm interested in knowing how it detects the change is,
that it would allow me to reduce the chance that a service/character change would go unnoticed.

Tags: SDK14.2, s132_nrf52_5.1.0, S132, Bonding, Service Changed

Regards Visti Andresen

  • 0 in reply to Sigurd

    Three follow up questions below.

    Am I to understand the the linked post as:

    The local database ONLY contains the CCCD values (for those handles that have notifications and indications enabled)

    1) And the ONLY way it detects an invalid local database is when there is a mismatch between the handle => CCCD values mapping in the local database and the handles currently having indications or notifications enabled?

    2) In other words if I want to make sure that the peer manager detects when characteristics are moved/deleted I should make sure that the "list" of handle ids that have notifications/indications enabled are unique compared to the previous configuration?(preferably all other configurations through all time that the firmware may have had)

    ===

    As an alternative approach I could erase all bonds if I change the characteristics.
    If the central (app) somehow detects that the bond have been erased when connecting I assume it will simply discover the layout again (and bond again if it so desires).
    I'm however not 100% sure that central is informed about the missing bond, at least is seems like the central can delete its bond and the peripheral is never informed about this (leaving "dead" bonds in flash).

    3) If the peripheral deletes the bond is there a mechanism in place that allow the central to detect this, also if the connection isn't encrypted?

    Regards, and thank you for your time Visti Andresen

  • +1 in reply to Visti Andresen

    Hi,

    Hi, sorry for not getting back to you on this one.

    Visti Andresen said:
    The local database ONLY contains the CCCD values (for those handles that have notifications and indications enabled)

     There is also some metadata, i.e. CRC and length field

    I was however unable to locate any file containing this format information.

     It's documented here:
    https://infocenter.nordicsemi.com/topic/com.nordic.infocenter.s132.api.v5.0.0/group___b_l_e___g_a_t_t_s___s_y_s___a_t_t_r_s___f_o_r_m_a_t.html

    Visti Andresen said:
    2) In other words if I want to make sure that the peer manager detects when characteristics are moved/deleted I should make sure that the "list" of handle ids that have notifications/indications enabled are unique compared to the previous configuration?(preferably all other configurations through all time that the firmware may have had)

    It's the application's responsibility to notify the Peer Manager when it changes the database. The Peer Manager can then distribute the service changed indication to all bonded peers. Use the function pm_local_database_has_changed for this.

    "    Distribution of service changed indications: When a GATT database changes, the Peer Manager can distribute the service changed indication to all bonded peers. The application must notify the Peer Manager every time it changes its database." from this link

    Visti Andresen said:

    3) If the peripheral deletes the bond is there a mechanism in place that allow the central to detect this, also if the connection isn't encrypted?

     This post might be useful for how to handle that: https://devzone.nordicsemi.com/f/nordic-q-a/77007/central-to-update-bonding-info-when-peripheral-has-deleted-it

Related
Terms of service