How to calculate nRF9160 NVM / flash wear lifetime?

In the nRF9160 command reference guide it states: "CAUTION: CFUN=0 causes writing to NVM. When using CFUN=0, take NVM
wear into account."

And I've found this post:

 NRF9160 Flash Endurance 

A few questions:

1. Is there anyway to know how many write cycles have been used?

2. If no user parameters were changed with AT commands can we assume AT+CFUN=0 won't use a write cycle?

3. Upon modem registration, is carrier or network information stored in NVM?  At my office, upon very first power up, registration seems to take around 30 seconds. After subsequent power cycles, registration seems to happen pretty quickly. Typically around 4 seconds. Will this impact NVM lifetime?

Parents
  • Hi, and sorry for the late reply.

    1. Is there anyway to know how many write cycles have been used?

    No. Unfortunately, there isn't a way to know how many write cycles has happened.

    2. If no user parameters were changed with AT commands can we assume AT+CFUN=0 won't use a write cycle?

    No. The modem will also store network parameters, GNSS parameters, etc. So it might store new data even though no user parameters has been changed.

    On the other hand, depending on how much flash is used (for different parameters, certificates, etc.), the modem might not need to delete a flash page to store the new data, and therefore it might not use a write cycle.

    3. Upon modem registration, is carrier or network information stored in NVM?  At my office, upon very first power up, registration seems to take around 30 seconds. After subsequent power cycles, registration seems to happen pretty quickly. Typically around 4 seconds. Will this impact NVM lifetime?

    Data is stored in flash periodically, though the period is quite long, at approximately 48 hours. Other than that, if you just connect, and then do a power cycle, I don't think any data will be stored.

    But if you do an AT+CFUN=0, it will store the network parameters, and use them when the device reboots, which will significantly speed up the connection.


    How are you planning to use the modem?

    How often are you planning to send data, and do you plan to cut power to the device, or turn off the modem when not sending?

    Usually, it is better to keep the modem on, and in PSM, than to turn it off, as doing a full re-initialization of the modem and SIM card can consume a lot of power.

    However, if you expect the device to loose power, it is best to turn off the modem with AT+CFUN=0, as that will help speed up the LTE connection setup when power is restored.

    If you don't expect the device to loose power but still want to turn off the modem, and want to ensure maximum longevity, using AT+CFUN=4 will be better, as that will minimize the flash wear.

    But again, the modem will only update the flash if there is a change (to either user parameters or network parameters), and if there are free flash pages, those will be used before it deletes an old one, so one erase cycle per AT+CFUN=0 is the worst case scenario, and not the default.

    Best regards,

    Didrik

  • In the case where PSM is not used, GNSS is not used, and AT+CFUN=0 is used on each shutdown... because it's important to store the network parameters to significantly speed up the next connection. How to calculate flash lifetime? e.g. in the following scenarios: Powering up, sending data, powering down. Periods of 5 min, 15 min, 1 hour and 1 day.

  • Hello again, and sorry for the long wait.

    I just wanted to inform you that we are mostly finished prducing some numbers for more normal scenarios. We are just doing some final verification, and should have them ready for you early next year.

    Have a merry Christmas and a happy new year.

  • As an aside, the specification on the nRF9160 differs from the nRF52 series, although one might expect the same MMC and Flash memory was being used.

    "flash is divided into multiple pages. The same address in flash can only be written nWRITE number of times before a page erase must be performed."

    For the nRF9160 nWRITE is defined as 2 writes for a single memory address, but on the nRF52 nWRITE is defined as 81 writes for a single flash block before a page erase must be performed. Given that there is usually a limited number of writes to a flash block before a page erase is required in most flash memory implementations, what is that number for the nRF9160?

  • Hi, and sorry for the long wait.

    The modem team originally tried to come up with a model that could give an estimate on how often an erase would happen based on various parameters. However, there are too many parameters for this to be feasible. Instead, we will try to add some extra logging in future modem firmware versions (2.0.x, running on the nRF9161).

    That way, it will be possible for customers to do their own calculations.

    However, they did list some of the parameters that affect flash writes and some scenarios for mfw 1.3.x:

    • Application use cases

      • LTE only, GNSS only or combination use of LTE + GNSS

      • Sleep periods

    • Semi-dynamic configurations. Periodic use/re-configuration of

      • AT%XMODEMTRACE

      • AT%XCOUNTRYDATA

      • AT+CFUN=0

      • GNSS start/stop + re-start and GNSS parameter re-configurations

    • Type of UICC used. If UICC doesn’t have all the necessary files supported, it affects nRF91 NVM usage. Maybe assumed to be rare though.

    • Is TLS session cache used or not

    • Is SIM lock (%USIMLOCK) set or not

    • Amount of used PSKs and certificates.

    This makes the estimation of normal use case pretty complex. But I have few examples calculated based on paper work.

    LTE use case (simple)

    • LTE operations are active, with protocol activity occurring at least once within 48-hour periods. No +CFUN=0 command has been given.

    • GNSS is never activated in the application.

    • Approximately 8 kB of PSKs and certificates.

    • UICC has all the necessary files supported.

    • TLS session cache (socket option) not used.

    • No SIM lock set.

    → Erase period every 432 hours (18 days)

    LTE + GNSS use case (simple)

    • LTE operations are active, with protocol activity occurring at least once within 48-hour periods. No +CFUN=0 command has been given.

    • GNSS tracking is activated, with acquisition activity occurring at least once within 12-hour periods. No GNSS stop + re-start, no parameter re-configurations.

    • Approximately 8 kB of PSKs and certificates.

    • UICC has all the necessary files supported.

    • TLS session cache (socket option) not used.

    • No SIM lock set.

    → Erase period every 84 hours (3.5 days)

    LTE + GNSS use case (complex)

    • LTE operations are active, with protocol activity occurring at least once within 48-hour periods. No +CFUN=0 command has been given.

    • GNSS tracking is activated, with GNSS stop + re-start, and/or parameter re-configurations and acquisition activity occurring at least once within 12-hour periods.

    • Approximately 3 x 8 kB of PSKs and certificates.

    • UICC has all the necessary files supported.

    • TLS session cache (socket option) used.

    • SIM lock set.

    → Erase period every 24 hours (1 days)

    , I am working on getting an answer for you.

Reply
  • Hi, and sorry for the long wait.

    The modem team originally tried to come up with a model that could give an estimate on how often an erase would happen based on various parameters. However, there are too many parameters for this to be feasible. Instead, we will try to add some extra logging in future modem firmware versions (2.0.x, running on the nRF9161).

    That way, it will be possible for customers to do their own calculations.

    However, they did list some of the parameters that affect flash writes and some scenarios for mfw 1.3.x:

    • Application use cases

      • LTE only, GNSS only or combination use of LTE + GNSS

      • Sleep periods

    • Semi-dynamic configurations. Periodic use/re-configuration of

      • AT%XMODEMTRACE

      • AT%XCOUNTRYDATA

      • AT+CFUN=0

      • GNSS start/stop + re-start and GNSS parameter re-configurations

    • Type of UICC used. If UICC doesn’t have all the necessary files supported, it affects nRF91 NVM usage. Maybe assumed to be rare though.

    • Is TLS session cache used or not

    • Is SIM lock (%USIMLOCK) set or not

    • Amount of used PSKs and certificates.

    This makes the estimation of normal use case pretty complex. But I have few examples calculated based on paper work.

    LTE use case (simple)

    • LTE operations are active, with protocol activity occurring at least once within 48-hour periods. No +CFUN=0 command has been given.

    • GNSS is never activated in the application.

    • Approximately 8 kB of PSKs and certificates.

    • UICC has all the necessary files supported.

    • TLS session cache (socket option) not used.

    • No SIM lock set.

    → Erase period every 432 hours (18 days)

    LTE + GNSS use case (simple)

    • LTE operations are active, with protocol activity occurring at least once within 48-hour periods. No +CFUN=0 command has been given.

    • GNSS tracking is activated, with acquisition activity occurring at least once within 12-hour periods. No GNSS stop + re-start, no parameter re-configurations.

    • Approximately 8 kB of PSKs and certificates.

    • UICC has all the necessary files supported.

    • TLS session cache (socket option) not used.

    • No SIM lock set.

    → Erase period every 84 hours (3.5 days)

    LTE + GNSS use case (complex)

    • LTE operations are active, with protocol activity occurring at least once within 48-hour periods. No +CFUN=0 command has been given.

    • GNSS tracking is activated, with GNSS stop + re-start, and/or parameter re-configurations and acquisition activity occurring at least once within 12-hour periods.

    • Approximately 3 x 8 kB of PSKs and certificates.

    • UICC has all the necessary files supported.

    • TLS session cache (socket option) used.

    • SIM lock set.

    → Erase period every 24 hours (1 days)

    , I am working on getting an answer for you.

Children
No Data
Related