peer manager flash cycling requirements

RE: peer manager flash cycling requirements

Petter Myhre — Wed, 30 Nov 2016 15:58:04 GMT

The Peer Manager can store the following (1 word = 4 bytes):

Bond information (20 words)
Peer rank (1 word)
Pending service changed (1 word)
Local GATT database (4 words for 1 CCCD, 5 words for 2 CCCDs)
Remote GATT database (?)
Application data (?)

These are stored in separate records, each with a header of 3 words.

Each virtual page has a page tag of 2 words.

The page size is 1024 words for the nRF52.

So if you have reserved 1 virtual page for FDS, you can store records in 1024-2 words = 1022 words.

So if the user bonds once a day, has 1 CCCD, and changes this CCCD 100 times a day, you would write 23 + 4*100 = 423 words a day.

Then the flash would wear out in:

1022 * 10000 / 423 = 24160 days = 66 years

RE: peer manager flash cycling requirements

vit bernatik — Tue, 29 Nov 2016 13:06:45 GMT

I'm using nRF52. Yes I think I meant CCCD. But this question is more general and answer shall provide list of things stored by peer manager and model how to compute guaranteed flash lifetime given custom usage model.

RE: peer manager flash cycling requirements

Petter Myhre — Mon, 28 Nov 2016 21:19:22 GMT

I guess you know, but if not; nRF51 has a page size of 1024B, and the nRF52 has a page size of 4096B. Which of them are you using? What do you mean by change configuration of characteristic? Changing the CCCD? How did you get that the bonding information is 16B? I think it is much more, but I need to look into exactly how much.