NVRAM Write Cycle Limits?

[legic_1490776]

Is there a limit on the number of times we can use bleprofile_NVRAM_Write() to the same address?

That is, if it's writing to an eeprom, is there some limit on the order of 100K or 1M writes before it wears out?

[ShawnA_01 · Accepted solution]

I checked the module die schematic for the 20732S module. The datasheet for the EEPROM claims it supports more than 4 Million write events.

[legic_1490776]

thanks, shawn!

Do you know whether the software layer that implements the 'nvram' functions is just a simple write or whether it does anything more complicated like wear leveling?

[asridharan]

The FW does not do any sophisticated wear leveling. Though with serial flashes, because of the way they work, new and modified items are always appended to the end of the 'used' area of the sector allocated for NV storage and the old item will be invalidated. An NV sector will be erased/consolidated (by double buffering) only when an item has to be stored but contiguous storage space cannot be found (but there are enough invalidated/unused but scattered blocks that can be defragmented) to fit the new item.

[legic_1490776]

Are NVRAM 'locations' mapped onto sectors?  Based on your description, it sounds as if my repeated writes to a single NVRAM location are likely to not map to write/erase cycles if the write is small compared with a sector?

How big are the sectors?

[ShawnA_01]

Be careful ldgirod - the 20736S module uses an EEPROM.  The comment from Arvind on 7/31 shifted the conversation to SFLASH which is a different beast, and which you are not using.

[legic_1490776]

True. So then, for the eeprom implementation, does each NVRAM write

correspond to an erase and write to the eeprom?

On Jul 31, 2014 11:42 AM, "shawn antol" <admin@community.broadcom.com>

[asridharan]

No. EEPROMs don't need to be erased before writing to it. If you add a new item, it will  be appended to the end to of the used sections. If you modify an item and it will still fit in the original physical location allocated for it (see other discussions - items + headers are rounded up to 32 byte pages), then it will be overwritten, else the item will be appended to the end and the old item will be invalidated (by marking it as such in the ToC). If you delete an item, it will be invalidated leaving a hole (which will be reclaimed when defragmentation is needed).

[MichaelF_56]

Most small density flash use a larger NOR based cell architecture that is optimized for random reads as opposed to a NAND architecture that is optimized for writes and is typically used in high density storage apps.  The NOR architecture typically does not require error correction, bad block management or wear leveling, and where is does, the manufacture will build this functionality into the part and abstract the complexity from the user (newer Spansion GL flash is an example).

While there are managed NAND options available today which provide onboard management (Micron ClearNAND, e-MMC, etc.), raw NAND will still require external management from a dedicated NAND controller of some type.