New FDS record on each connection

RE: New FDS record on each connection

Vidar Berg — Wed, 08 Apr 2020 06:54:03 GMT

The server is expected to remember the CCCD value across connections when bonded, so you will have to update the value in flash if the client changes the setting. It's really the client that should stop writing to the CCCD on every re-connect. But it would be good if the server had a check for whether the client is actually writing a new CCCD setting before deciding to update the information in NV memory.

[quote user="vko_nn"]I do not understand why flags of the client notifications need to be stored in flash memory.[/quote]

It's a specification requirement. A bonded client should not have to re-enable notifications/indications on every connection

RE: New FDS record on each connection

Vladislav Kolodiev — Tue, 07 Apr 2020 13:56:46 GMT

May be before updating FDS it is necessary to check whether flags are changed or not?

As a short-term solution, I can remove the call "update_pending_flags_check ()" in the file "gatt_cache_manager.c" on line 707 (SDK 15.3). I do not understand why flags of the client notifications need to be stored in flash memory.

RE: New FDS record on each connection

Vidar Berg — Tue, 07 Apr 2020 11:01:12 GMT

I see. The ble_app_hrs_c implementation enables notifications on every connection even if it was enabled in a previous session. Also, the Server implementation does not actually check if the new configuration is different from the setting already stored in flash. In other words, calls to ble_hrs_c_hrm_notif_enable() /ble_bas_c_bl_notif_enable() will always trigger an FDS update on the server side. I agree that this is an unnecessary use of flash.

RE: New FDS record on each connection

Vladislav Kolodiev — Tue, 07 Apr 2020 08:06:55 GMT

I checked an example SDK with the link between "ble_app_hrs_c" and "ble_app_hrs". The problem occurs if the devices are connected with bonding. I don’t understand: why update the record without new information? Each new record is equal to the previous record. It will destroy flash memory unnecessarily.

RE: New FDS record on each connection

Vidar Berg — Tue, 07 Apr 2020 07:15:36 GMT

Hi,

You will get this event if the GATT client changes notification/indication settings on your server. Have you tested this with more than one client to check if the behavior is different? E.g., using the nRF connect app on Android or iOS.

RE: New FDS record on each connection

Vladislav Kolodiev — Mon, 06 Apr 2020 15:46:57 GMT

Hi Vidar, PM_PEER_RANKS_ENABLED does not affect this issue. The peer manager receives the PM_EVT_PEER_DATA_UPDATE_SUCCEEDED event with data_id: PM_PEER_DATA_ID_GATT_LOCAL.

I am confused that the data for storage has not changed. In a new record, only the record identifier is changed.

I add logs to FDS
<info> app: GATT ATT MTU on connection 0x0 changed to 23.
<info> app: fds_record_update() file_id=0xC000 record_key=0xC008 length_words=7
<info> app: 03 00 00 00 14 00 0D 00|........
<info> app: 02 00 00 00 11 00 02 00|........
<info> app: 01 00 17 00 02 00 00 00|........
<info> app: EA 66 00 00 |.f..

RE: New FDS record on each connection

Vidar Berg — Mon, 06 Apr 2020 10:16:09 GMT

Hi,

Maybe the 'PM_PEER_RANKS_ENABLED' setting option is enabled? This will update rank information in flash on every new connections.

Log message when Rank information is updated in FDS:

"<info> peer_manager_handler: Peer data updated in flash: peer_id: 0, data_id: Peer rank, action: Update, no change" indicating that the fds update was

Best regards,

Vidar