I checked the operation of the application "ble_app_hrs" and I see that the FDS makes a new record in flash memory with every new connection. What is the need and can it be prohibited?
Best regards,
Vladislav.
I checked the operation of the application "ble_app_hrs" and I see that the FDS makes a new record in flash memory with every new connection. What is the need and can it be prohibited?
Best regards,
Vladislav.
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
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..
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..
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.
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.
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.
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.
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.
Vladislav Kolodiev said:I do not understand why flags of the client notifications need to be stored in flash memory.
It's a specification requirement. A bonded client should not have to re-enable notifications/indications on every connection