Stored CCCD data in flash by peer manager - 44 bytes per write!!!

[swlnk]

I'm investigating the flash usage by the peer manager to store bond related data. While I haven't had a chance to fully investigate how the FDS and fstorage modules work, I did notice two things that surprised me with regards to this:

1. Every time a CCCD is written from a bonded peer device, 44 bytes of flash are being used to store the updated CCCD value. This seems like a lot of flash usage, especially considering that the CCCD value itself is only 2-bytes. I understand that there is some overhead beyond just the two bytes written to the CCCD (e.g. indexes, headers, handle value, etc...) but 44-bytes seems like a huge amount of flash to use. Is there any way to reduce this?

2. I also noticed that if a CCCD gets written to more than once with the same value, the peer manager still writes 44-bytes of flash for these additional writes, even though nothing has actually changed. For example, say that I write a value of 0x0001 to a CCCD to enable notification of the characteristic value. Then later I disconnect from the peer device and then reconnect and re-encrypt the link (and restore the CCCD to it's previous value of 0x0001). If the peer device were to once again write a value of 0x0001 to the CCCD (which doesn't actually change anything), the peer manager still writes 44-bytes of data to the flash. This also seems wasteful of flash. Is there any way to check the previously stored value and only perform the flash write when a value actually changes?

I understand that there is a garbage collection system in FDS that will take effect when pages fill and clean up any old/unused data in flash (please correct me if I'm wrong here), but it still seems like the above two issues create additional flash writes / page erases that are unnecessary and also add complication to the system.

Thanks!

[haakonsh]

Hey Sandeep,

Every time bond data is changed for any device its bond record stored in flash must be updated. I believe we do not want to erase an entire page just to "overwrite" two bytes of a record, therefore I believe we chose to write the entire record into the first available space in the current page. Another option would be to let the contents of a record be stored in non-contiguous memory, but then the data management and increased overhead will make this solution impractical. 

I agree that it is unfortunate that the record is written when a CCCD has been written to without a change in state. I'd think it would be fairly easy to check for a state change before writing a record, but I'm not an SDK developer and I do not know the feasibility of such a change. I will talk to the devs though. 

Cheers,

Håkon.

[swlnk]

Hi Håkon- Thanks for your response. After studying the FDS system a bit more I understand the reason for the large amounts of data being written.

I still would like to know if there's a way to prevent NV writes from occurring when there is a CCCD write without any change to a state. Were you able to get any information from your SDK developers? I may try to go into the peer manager myself to see if I can add this logic, but I'd be more comfortable if someone from Nordic were able to implement this or provide guidance.

Thanks!

[haakonsh]

Hey Sandeep, sorry for the slow response.

I'm afraid the developers are not going to pick up this issue anytime soon. It will be added to their backlog and they will get to it eventually, but probably not within a time frame that suits your development schedule. 

Cheers,

Håkon.

[swlnk]

OK no problem. Thanks for getting back to me.