This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

peer manager flash cycling requirements

Hello, there is written that Peer Manager is using flash for storing bonding data or service configuration. Can you extend a documentation - and add description when and how many bytes the peer managers stores into flash? (for example I can imagine there can be implementation which stores configuration change only upon disconnect, or on every configuration change). We need to guarantee that our product would last for defined years under some model of maximal usage (respecting that flash has only 10K erase cycles).

Also could you add example how to calculate the flash lifetime? It can look something like this:

FDS_VIRTUAL_PAGE_SIZE = 1024 B
FDS_VIRTUAL_PAGES = 1

Thus we have (1024-2)*1 B to use. FDS will guarantee optimal flash load. (2B by page is used by Flash Data Storage (FDS) module (I think))

Example model of usage could be that user bonds a device 1 per day. And change configuration of 100 characteristics per day. Storing bondage information takes 16B. Storage new configuration takes 2B per characteristic (but takes 4B to be word aligned). For each file-record entry there is overhead of 12B. Therefore per day we need to write 16+12+(4+12)*100= 1628 B. FDS will ideally load whole 1022B. Thus we have 1022 B * 10000 eraseCycels / 1628 BytesWrittenPerDay = 6277 days = 17 years.

Note that this example is my guess - if I would be certain it is correct I would not ask for more documentation...

  • 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.

  • 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.

  • 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

Related