ble bonding infos decoding

[astella]

To the kind attention of Nordic support team,

after doing some ble bonding between an nRF52 device and an host computer, I can see this situation in device flash. So, these bonding infos are written

sequentially. How many are available? What happens when there is no any more room? Driver is then starting using entries marked as "not used" again?

Most important, I'd like very much to have a C language structure to properly decode bonding infos.

Can you please help me in finding out the right documentation, or provide one such structure example if possible?

Thank you for your kind attention

[Dmitry]

Hi,

Bonding info along with GATT cache data is written by peer manager to FDS storage space as a set of records - if you're curious, the format of FDS record itself can be found in components/libraries/fds/fds.h. The highlited block of data is not a single record but a sequence of different ones - see components/ble/peer_manager/peer_manager_types.h.

astella said:

How many are available

As many as you have space in FDS.

astella said:

What happens when there is no any more room?

Peer manager will initiate a garbage collection procedure - the whole flash space will be compacted by throwing away old records marked for deletion. If there's really no space (FDS is full), it's not surprizing that bonding info will not be saved.

astella said:

Can you please help me in finding out the right documentation, or provide one such structure example if possible?

For example, you can find the format of bonding data (pm_peer_data_bonding_t structure) in components/ble/peer_manager/peer_manager_types.h. I don't think it's a good idea to work with these records directly, it's much better to use peer manager API.

[astella]

Thank you sir, very nice reply